global ephemeris data cache

[nicHoch]

add a internal ephemeris data cache. This allows to bypass hidden internal FIDO searches and downloads of the same data multiple times

All coordinate transform and imaging methods might internally search for correct ephemeris data for higher precession.
To get the ephemeris data a FIDO search (defaults to our stix data server) is uses and data gets downloaded.

The ephemeris data search utilises a global cache in order to avoid unnecessary network traffic or file loading. ANC ephemeris fits files are organised as daily files. The entire day is put to cache if touched once.

A user can prefetch or pinpoint specific ephemeris data files with the `load_ephemeris_fits_to_cache(filename)' method.

    from stixpy.coordinates.transforms import load_ephemeris_fits_to_cache

    start_time = Time("2023-01-01T12:00:00")
    end_time = Time("2023-01-01T12:30:00")
    query = Fido.search(
        a.Time(start_time, end_time),
        a.Instrument.stix,
        a.Level.anc,
        a.stix.DataType.asp,
        a.stix.DataProduct.asp_ephemeris,
    )

    aux_files = Fido.fetch(query["stix"])
    for file in aux_files:
        load_ephemeris_fits_to_cache(file)

[codecov]

Codecov Report

❌ Patch coverage is 96.62757% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.19%. Comparing base (5275652) to head (d14bda6).

Files with missing lines	Patch %	Lines
stixpy/product/product_factory.py	81.81%	6 Missing ⚠️
stixpy/coordinates/_ephemeris_fetcher.py	91.83%	4 Missing ⚠️
stixpy/coordinates/transforms.py	94.80%	4 Missing ⚠️
stixpy/product/sources/anc.py	87.09%	4 Missing ⚠️
stixpy/utils/table_lru.py	97.41%	3 Missing ⚠️
stixpy/product/sources/science.py	50.00%	1 Missing ⚠️
stixpy/utils/tests/test_table_lru_cache.py	99.57%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #165      +/-   ##
==========================================
+ Coverage   85.40%   87.19%   +1.78%     
==========================================
  Files          50       58       +8     
  Lines        3186     3748     +562     
==========================================
+ Hits         2721     3268     +547     
- Misses        465      480      +15     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[samaloney]

Yea this is very different from what I was thinking but that not a bad thing, any idea on performance? As the reason I added the cache in the first place was because this code is call a lot during plotting operations.

It would be nice to be disable the cache maybe add a module level variable. Needs some narrative documentation could be added to top of the rst file and also needs a corresponding change log.

In the future if we have different version of the anc-ephem files and I wanted to compare the results from V0X to V0Y is this in the table or does the user have to remember which one the loaded last so will be in the cache? It would probably be useful to know which file the data came from anyway for debugging purposes anyway

[samaloney]

@nicHoch I force pushed, sorry, so don't forget to pull the changes back down to your local branch.

[samaloney]

pre-commit.ci autofix

[samaloney]

Hum the changlog entries seem repetitive/duplicates?

I'm not sure why the CI is failing seems unrelated to the changes in this PR?

How does this play with plotting on WCSAxes e.g. sunpy Maps as that was the original driver for the lrucache.

[nicHoch]

@samaloney — heads-up on the one (latest) non-obvious part of this PR: the testing flow change.

Why: the py313-online job was failing intermittently with truncated-FITS errors (Empty or corrupt FITS file, No SIMPLE card found, …). It's not our code — the test-data server (pub099 / dataarchive.stix.i4ds.net, same host) occasionally truncates responses under the concurrency of pytest -n auto, and parfive caches the partial file as if complete. A diagnostic run with -n 1 (serial) was reliably good, which confirmed it's concurrency-induced, not a logic bug. All three download paths funnel through sunpy's cache.download, and one of them (TimeSeries(url)) lives inside sunpy, so we can't fix it cleanly per-call-site.

How: instead of guarding each download site, tests now run through a small wrapper (tools/run_online_tests.py, wired into tox.ini):

1. run the suite in parallel as before;
2. only if an online run fails, clear the sunpy download caches and re-run just the failed tests once, serially (-n 1).

--last-failed selects by node id, so this also covers doctests and setup errors. Offline envs pass through untouched (no --remote-data → no retry). Net effect: same speed on the happy path, self-healing on the flaky one — without masking real failures (a genuine failure just fails again on the serial rerun).

Two things worth a look in review:

• The rerun strips all --cov*/-n options so it doesn't rewrite coverage.xml with only the reran subset (that briefly made codecov/project red while codecov/patch stayed green).
• I removed the earlier per-path validate+redownload guards (they covered only 2 of 3 paths), but kept the stixpy/utils/io.py::is_valid_fits helper + tests, with comments marking where to reintroduce a client-side guard if we ever want end-user (non-CI) resilience.

Server-side hardening (the truncation likely also has an Apache/network angle on the FHNW/our side) is noted as a separate follow-up, out of scope here.

[samaloney]

What about just disabling the parallel runs for the online tests?

Suggested change

	online: --remote-data=any \
	online: -n 1 \
	--pyargs stixpy \

[nicHoch]

my goal was to support the "normal case" as fast as possible (as done so fare) and only do something in the "rare" cases where it breaks. so the local runs can stay the very same.