-
Notifications
You must be signed in to change notification settings - Fork 8
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
TLE archiving raises ValueError and copies to wrong directories #10
Comments
Related: #2 |
Added a test case that reproduces the TLE ValueError as reported in pytroll#10. Since this appears to be the first test case, also adapt .travis.yml to run this test with pytest, and update the Python version to the modern era.
The problem here appears to lie in the archival strategy. As currently implemented, for each matching regex it creates a copy and for each regex that matches but can't be decomposed as desired it logs an exception: pytroll-aapp-runner/aapp_runner/tle_satpos_prepare.py Lines 446 to 470 in d806497
that means that I'm not even sure anymore if the exception I'm seeing is the cause of the later AAPP problem I'm having, but it does explain why I get several spurious directories, which clutters up the archive and is confusing. I'm not sure how I can safely fix this without risking breaking compatibility. |
Make sure we only copy a TLE file to a single archive directory. Fixes pytroll#10.
Describe the bug
The AAPP runner on my system is failing to archive TLE files correctly. Subsequently, probably as a consequence,
SATPOSTLE
fails and processing stops. There are two issues:ValueError
is raised due to "unconverted data"To reproduce
It's a bit difficult to produce a MCVE for this case. On my system, this reproduces it:
After running this, I have:
Expected behaviour
I would expect that the TLE for 2021-01-19 06:16 gets copied to the directory
tle-20210119
. I'm not sure if I should expect anything for the older TLEs. Although this copying does happen, I expect that either the other TLEs are also copied, or nothing further gets copied and processing stops here.Actual results
In reality, the aforementioned script results in:
with files being copied to where I don't expect them.
Subsequently, further AAPP processing fails:
Additional context
It's possible that there is something wrong in my configuration. The relevant part is probably:
I don't understand why this leads to the observed behaviour, though.
The text was updated successfully, but these errors were encountered: