Cadair They are bridged together so take your pick
Cadair I have not tried to run my own irc bridge yet. I just use the matrix.org one. It's got much better recently.
dan i'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
dan the main concern is that i don't think that the astropy community can afford to be the primary maintainer of the pytest doctest plugin
on the pytest side we are preparing to do much more release automation on pytest and the plugins we provide
however we also want to take a look at having things we currently don't put due diligence on be managed soundly (like doctest for example)
so from my pov there is going to be some back and forth to sort out the comprehension and and the future direction
It is clear that it is possible to apply
mod2pi to a solution, but this is not always convenient.
matrixbot wildlander on Freenode says goodbye: see you in the next! o/
kerel on Freenode lbracher: 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 Freenode lbracher: Here is an example for propagation with sgp4: https://gitlab.com/kerel-fs/jupyter-notebooks/blob/master/beresheet/Beresheet.ipynb
kerel on Freenode If you implement a method for next perigee I would be interested as well (might use it to follow Beresheet :D).
mithrison on Freenode what’s exactly this framework for?
SuperMcFreaky on Freenode Is there a way to convert a PrimaryHDU object to an ImageHDU object?
SuperMcFreaky on Freenode I can do i = fits.ImageHDU(primary.data, header=primary.header)
SuperMcFreaky on Freenode and that works, but it copies the data into memory, which can be a real problem in my case
SuperMcFreaky on Freenode for debugging purposes it is sometimes useful to write this aggregate object as a single FITS file
SuperMcFreaky on Freenode and an HDUList with all PrimaryHDUs produces a non-compliant FITS file
SuperMcFreaky on Freenode it 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 Freenode well, it won't do that unless I tell it that I'm OK with a non-standard file
SuperMcFreaky on Freenode I feel like the capability should/could be there because io.fits already is really good about using memmap, etc.
SuperMcFreaky on Freenode for 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 Freenode which is exactly what I want, except for PrimaryHDUs
saimn I 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
wait, is CircleCI running astropy as root? really?