-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix u.cycle bugs on astropy 4.0 #616
Conversation
Nice work! BTW, I think we should delete htest_optimize.py from PINT. It is a quick hack I made and isn't worth maintaining. |
OK. I've been bold and added a commit removing it. |
Do we need htest functionality in PINT? |
What do we mean by htest functionality? |
@paulray mentioned the htest_optimize.py is a quick hack. But should we have a more serious htest code in PINT? or should it be independent? |
@luojing1211 I understood that much. I just don't know what "htest code" is supposed to do. Maybe we should have a new issue for it if it's something we want to add? |
Given that PINT is really useful for processing event mode data from many spacecraft, it is approppriate that we have H-test calculation routines (among others) available in pint.eventstats. However, the htest_optimize.py script was a quick hack that I wrote that wasn't being maintained and so I suggested deleting it. So, with that deletion, I think we are in fine shape. If someone else has feature requests it is fine to put them in as issues. |
Also, note that other higher-level manipulations of event data that make use of PINT are in packages such as NICERSoft and HENDRICS. This include TOA generation and pulsation searches. |
Let us remove it in a separate PR, so we can better track on it. |
6bb8bed
to
2dcbed8
Compare
OK, I took the removal out of this PR. |
I guess we need to fix this conflict now that #618 has been merged. |
2dcbed8
to
b4fd40e
Compare
I just rebased on master, skipping one commit that only modified |
The Python 2.7 build is now failing for a reason I don't understand. One of the precision tests failed -- it looks like it might just have randomly chosen a rare example that it happens to break on? |
Yeah, I don't understand it either. @aarchiba wrote those tests, so maybe she can help? |
Or sometimes if you just re-run the test it passes! |
b4fd40e
to
4b11739
Compare
Just made a do-nothing change to re-trigger the Travis build. |
OK, still failing. So it's not that Flaky... |
@paulray Did you manage to reproduce it locally? I don't have a working Python 2.7 environment with PINT installed. |
So, I just installed a py27 virtualenv and tried it two ways, with "make test" and with "tox -e py27". I noticed a couple of errors/warnings in the install:
and
Then, the "make test" passed the precision tests but had one fail in test_observatory:
This is due to me having TEMPO2 installed, but I'm not sure why we have a test that fails looking for fake2gps.clk. The tox run passed all tests. So, I can't replicate the error either way. It may be due to the fact that hypothesis is being disabled. We may want to tweak the versions of packages being installed under py27. |
Ah, looking at the test_observatory fail, it looks like it is supposed to fail, but the test is looking for OSError and it is triggering IOError instead. Perhaps something having to do with me having Tempo2 installed is causing the difference. |
OK, I fixed test_observatory in my branch so it will test for both OSError and IOError. |
Should we merge this? I wonder if for the time being we should restore the astropy<4.0 specifications? Or are we really ready to allow astropy 4? |
4b11739
to
fbacf88
Compare
I finally got a chance to try to reproduce the test failure here in a working Python 2.7 environment today, and I can't. All the tests pass on this branch on my machine. Examining the Travis output more closely leads me to believe |
I concur. That must be the issue. Any idea how to extend the deadline? |
We could turn off the deadline on this particular function by applying the |
Seems like it is worth a shot |
The relevant part of the Also, in response to your earlier comment, removing the astropy < 4 requirement is part of this PR, so it hasn't made it to the main branch yet. |
I've added a commit extending the deadline to 1 second (from 200 milliseconds). Hopefully that fixes it. I'm still not sure why the issue only affects this branch, and only after I rebased. It can't be an astropy 4.0 thing, since it only happens on Python 2.7. |
On whether we're really ready to allow astropy 4.0, I'd like to point out that all the Python 3 Travis builds of this branch are already using it, and have been passing for quite a while (even as Python 2.7 failed). |
The extended deadline worked! All tests are now passing! |
Sweet! I guess we can just take the plunge and enable astropy 4.0. We can always back off if we find an issue. |
Yeah. Let's take the plunge and allow Astropy4 and merge this. |
This is the result of following up on the weird behavior @paulray noticed in #615. Certain operations on quantities with the
u.cycle
unit were causing them to be implicitly made dimensionless, i.e. converted to radians by multiplying by 2π. This turns out not to be an astropy 4.0-specific behavior, but it was causing bugs on astropy 4.0 because theu.cycle
unit was being propagated further than it had been. I found that the weird behavior could be traced to this line, which sets theu.dimensionless_angles()
equivalency globally.This PR gets rid of this behavior by deleting the offending line. However, doing this caused quite a few test failures due to the resulting stricter unit checks. The follow-up commits fix these failures, which turned out to have four different causes:
photonphase.py
, had relied onnp.where()
silently stripping theu.cycle
unit from its arguments. I fixed these instances by explicitly stripping the units with a line likephases=phases.to(u.cycle).value
before the call tonp.where()
.u.rad
unit being treated as equivalent to dimensionless units. I fixed these instances by wrapping the offending code in awith u.set_enabled_equivalencies(u.dimensionless_angles())
block.IFunc
andWave
model components explicitly converted dimensionless quantities (in radians) into theu.cycle
unit. I fixed these by going directly to cycles, rather converting from radians.SolarWindDispersion
model component took the inverse cosine of a dimensionlessQuantity
, which in astropy 4.0 results in aQuantity
with theu.rad
unit. Withoutu.dimensionless_angles()
, this lead to unit incompatibilities later. I fixed this by converting the dimensionlessQuantity
into a regularnp.ndarray
before taking the inverse cosine.With these changes, all of the tests now pass on astropy 4.0! So I added a final commit removing astropy <4.0 requirement from
requirements.txt
,requirements_dev.txt
, andsetup.cfg
.