CadairThey are bridged together so take your pick
CadairI have not tried to run my own irc bridge yet. I just use the matrix.org one. It's got much better recently.
dani'm definitely interested in having that discussion. we've hit upon a few potential features recently that would really only be possible if we were able to access the core doctest plugin. it also seems like our plugin has features that would be useful to a broader community
danthe main concern is that i don't think that the astropy community can afford to be the primary maintainer of the pytest doctest plugin
mod2pito a solution, but this is not always convenient.
kerel on Freenodelbracher: I can recommend the method twoline2rv from sgp4 to read the TLE and then skyfield, poliastro or sgp4 to propagate around the orbit. To determine the perigee you could then use the optimization functions from SciPy. I don't think there is a method which directly returns the next perigee.
kerel on Freenodelbracher: Here is an example for propagation with sgp4: https://gitlab.com/kerel-fs/jupyter-notebooks/blob/master/beresheet/Beresheet.ipynb
kerel on FreenodeIf you implement a method for next perigee I would be interested as well (might use it to follow Beresheet :D).
kerel on Freenode(only cell In is relevant here)
mithrison on Freenodewhat’s exactly this framework for?
SuperMcFreaky on FreenodeIs there a way to convert a PrimaryHDU object to an ImageHDU object?
SuperMcFreaky on FreenodeI can do i = fits.ImageHDU(primary.data, header=primary.header)
SuperMcFreaky on Freenodeand that works, but it copies the data into memory, which can be a real problem in my case
SuperMcFreaky on Freenodefor debugging purposes it is sometimes useful to write this aggregate object as a single FITS file
SuperMcFreaky on Freenodeand an HDUList with all PrimaryHDUs produces a non-compliant FITS file
SuperMcFreaky on Freenodeit won't even write unless I set output_verify='ignore|warn" in the call to .writeto()
astrofrog (@slack_astropy_U07529085:openastronomy.org)interesting, I would have thought an HDUList of PrimaryHDU would do the right thing
astrofrog (@slack_astropy_U07529085:openastronomy.org)it might be worth opening an issue in the GitHub repo to ask whether astropy could be smarter about auto-converting to ImageHDU when writing, we definitely shouldn't be writing files that don't comply with the standard
astrofrog (@slack_astropy_U07529085:openastronomy.org)I'm not sure how to avoid the copy, if you join the astropy Slack team there is a #fits channel where you could ask
SuperMcFreaky on Freenodewell, it won't do that unless I tell it that I'm OK with a non-standard file
SuperMcFreaky on FreenodeI feel like the capability should/could be there because io.fits already is really good about using memmap, etc.
SuperMcFreaky on Freenodefor example, if I open 1000 files with large ImageHDUs and put them together in a new HDUList and write that to disk then they data never enters memory
SuperMcFreaky on Freenodewhich is exactly what I want, except for PrimaryHDUs
saimnI don't think that the data is copied if it is a numpy array, but maybe it needs to be copied because it is memmmaped