API Notes¶
Data model¶
pyeuvtools.response.models.AIAChannelWavelengthResponse stores:
- channel label
- observation time
- wavelength grid
- response values with units
- EVE correction flag
- correction source metadata
It exports to an astropy.table.QTable through to_table().
pyeuvtools.response.models.WavelengthResponseSet stores:
- instrument name
- observation time
- ordered channel labels
- common wavelength grid
- per-channel response arrays
It exports to an astropy.table.QTable through to_table(), with one response
column per channel.
AIA module¶
pyeuvtools.response.aia currently provides:
build_aia_wavelength_responsebuild_aia_wavelength_response_setbuild_aia_effective_areabuild_aia_effective_area_setbuild_aia_temperature_responsefor the raw folding step analogous to SSWaia_bp_make_tresp.probuild_aia_temperature_response_setfor multi-channel raw folding on a shared emissivity gridbuild_aia_temperature_response_idl_viewto package that folded matrix into the same normalizedinstrument/channels/LOGTE/ALLstructure used by the IDL benchmark loaderbuild_aia_temperature_response_gx_payloadto package that same temperature response into the exact structured-array field layout expected by downstreamComputeEUV-style consumers:ds,NT,Nchannels,logte,allaia_get_responseas a compact Python wrapper over the current AIA response milestone
The current temperature-response builder is intentionally narrower than the full
IDL aia_get_response(/temperature, ...) path. It performs the core numerical
folding step: interpolate the wavelength response onto the emissivity wavelength
grid, zero the out-of-band region, and integrate over wavelength for each
temperature bin. The surrounding SSW control flow, correction structures, and
chiantifix behavior are now partially implemented through a Python-readable
export of the SSW aia_V#_chiantifix.genx grid.
For the current 0.1.0 milestone, aia_get_response is intended to cover:
- compact EUV
area/effective_arearesponses - compact
emissivityresponses sourced from the hybrid export - compact
temperatureresponses with the explicit correction statesraw,evenorm, andevenorm_chiantifix
The following remain later milestones rather than 0.1.0 requirements:
fullstructuresallchannel mode beyond the standard thin-filter EUV setuvchannels
The compact Python wrapper is deliberately non-interactive. It does not inherit
the SSW prompting behavior for under-specified correction choices. Instead, the
public surface accepts only scientifically valid correction states through the
correction= keyword:
rawevenormevenorm_chiantifix
The legacy evenorm= and chiantifix= keywords remain temporarily for
compatibility, but they are deprecated. A nominal chiantifix-only request is
rejected in the public API rather than being silently promoted, because the
package is meant to be safe for automated workflows.
Returned temperature-response metadata now includes a single authoritative
correction_state field, while the legacy requested_state and
effective_state fields are kept aligned to that same normalized value for
compatibility with existing artifacts and tests.
For downstream GX integration, the intended public bridge is
build_aia_temperature_response_gx_payload(...). It returns:
- a length-1 structured NumPy array ready for direct downstream packing
- the exact dtype used to build that array
- a lightweight metadata dictionary carrying instrument, channels,
correction_state,response_units, the chosends_arcsec, and the nested normalized IDL-view metadata
This keeps the response-construction logic in pyEUVTools while avoiding a hard
dependency on gximagecomputing implementation types.
For 0.1.0, the required correction grid is shipped as packaged runtime data
under src/pyeuvtools/data/aia/chiantifix-exports/. The IDL helper
scripts/idl/ExportAIAChiantifix.pro remains the contributor refresh path for
rebuilding that packaged asset from the SSW .genx source.
CHIANTI backend prototype¶
pyeuvtools.response.chianti currently provides:
get_fiasco_backend_statusto report whetherfiascois importable and whether its configured CHIANTI database is accessibleensure_fiasco_databaseto askfiascoto provision its configured ASCII and HDF5 CHIANTI databases if they are missingrebuild_fiasco_databaseto repair a partial or corrupt local HDF5 cache from the ASCII CHIANTI treebuild_fiasco_ion_spectrum_gridto build a real wavelength/temperature spectrum grid from an explicit ion subsetsave_fiasco_spectrum_gridto persist that expensive CHIANTI-backed spectrum grid as a.npzcache artifactload_fiasco_spectrum_gridto reload that cache artifact for repeated folds without rebuilding the spectrumscreen_fiasco_ions_for_temperature_gridto find which explicit ions actually support a requested temperature grid under the current backend settingsFiascoBackendStatusto carry the backend version, configured database roots, and current availability state
This is intentionally a backend-readiness helper, not a temperature-response builder.
It exists to separate fiasco installed from database actually usable, which is
the next concrete gate for the Python-native CHIANTI path.
This backend is currently provisional and is not the default production path for
the package. The optional fiasco dependency and its database are therefore not
required for a normal pyeuvtools installation, and the CHIANTI-backend tests
are excluded from the default pytest run unless explicitly requested.
When the ASCII CHIANTI tree is available, the status helper also reports the detected CHIANTI database version.
The ion-spectrum helper is narrower than a full CHIANTI emissivity engine, but it
provides the first real scientific bridge between fiasco and the raw AIA benchmark
comparison path by returning a binned wavelength/temperature surface for a chosen ion set.
The ion-screening helper complements that bridge by letting callers preflight a
candidate ion list with the same temperature grid and low-level fiasco kwargs,
such as use_two_ion_model or include_protons, before attempting a larger spectrum build.
The spectrum-grid cache helpers are intended for repeated local parity runs where the CHIANTI build dominates runtime but the fold inputs have not changed.
Hybrid genx export prototype¶
pyeuvtools.response.hybrid now provides the first hybrid-backend scaffolding:
load_aia_hybrid_genx_exportto load a normalized export assembled from the source AIAfullinstandfullemiss.genxproductsbuild_aia_temperature_response_from_hybrid_exportto fold that normalized export through the existing Python AIA temperature-response path
By default, those helpers now resolve the highest installed exported AIA
response version under the packaged runtime-data tree
src/pyeuvtools/data/aia/genx-exports/ and load the matching
aia_hybrid_genx_export_v1.sav. Callers can instead pass an explicit path or a
version selector such as emversion="V9" when they need to pin an older
artifact for regression or comparison work.
The shipped repository therefore carries two copies with different roles:
- runtime package data under
src/pyeuvtools/data/aia/genx-exports/ - benchmark/provenance copies under
benchmark-data/aia/genx-exports/
User-generated exports still default to an external user-local directory unless
outdir is passed explicitly to the IDL exporter.
The hybrid temperature-response constructor now mirrors the main SSW selector split more closely:
versionselects the instrument response version by resolving the matchingfullinstfile when availableemversionselects the exported emissivity artifact version under the packaged runtime-data treerespversionselects a specific degradation response table, either by path or by matching a version/timestamp-like filename fragment under the AIA response tree
The current contract is intentionally narrow. It does not attempt to reproduce the full SSW response-control flow inside the export itself. Instead it defines a stable interchange surface for the upstream instrument and emissivity products so Python can use those compact data directly.
The currently published hybrid comparison snapshot should therefore be read as a
raw-baseline artifact in the narrow benchmark sense: the vendored IDL reference
records evenorm=0 and chiantifix=0, while crosstalk is not recorded as a
separate metadata field in that fixture.
The hybrid comparison CLI follows the same policy: its default artifact output directory now lives outside the repository, and contributors must pass an explicit repo-local artifact directory when they intentionally want to refresh committed benchmark artifacts.
IDL comparison helpers¶
pyeuvtools.response.compare provides:
load_idl_aia_responseto read a GX-style AIA response SAV fixturecompare_aia_response_to_idlto compare that fixture against the shipped Python AIA layercompare_aia_temperature_response_to_idlto compare a Python-folded temperature-response matrix against the raw IDL benchmarksave_aia_temperature_response_comparison_datato persist a completed comparison as a.npzartifact for later replottingload_aia_temperature_response_comparison_datato reload that.npzartifact without recomputing the CHIANTI bridgeplot_aia_temperature_response_comparisonto save a channel-by-channel visual comparison of the IDL and Python temperature-response curves versuslogte
The comparison is intentionally structural at this stage. It records channel and instrument agreement and surfaces blocking gaps when the IDL and Python layers do not yet represent the same scientific object.
When an emissivity grid is available, compare_aia_temperature_response_to_idl
can perform the direct matrix comparison against the IDL ALL temperature-response
array and report per-channel numerical differences.
The same normalized structure is now available on the Python side through
build_aia_temperature_response_idl_view, which makes it possible to inspect or
serialize a Python-built response with the same logical shape as the SSW/IDL
benchmark before chasing remaining numerical differences.
It also checks whether the IDL fixture metadata records the response-generation
flags needed for reproducibility, including evenorm and chiantifix.
The current comparison helpers remain useful for interim validation against
legacy GX-style fixtures, but the long-term scientific target is the raw IDL
temperature-response benchmark defined in docs/benchmark_spec.md.
For channel-specific interpretation, AIA 335 should currently be treated as a lower-confidence validation channel than 171, 193, or 211. Public references report passband inconsistencies, higher-order contamination, and incomplete spectral content in the 335 A region: Boerner et al. 2013 (Sol. Phys. 289, 2377; arXiv:1307.8045) and Trabert and Beiersdorfer 2018 (A&A 617, A8; DOI 10.1051/0004-6361/201833256).
Current scientific scope¶
The shipped API currently covers the AIA wavelength-response layer via aiapy.
It is time-dependent through the observation time input and uses the jsoc
correction table by default. It does not yet claim GX-compatible temperature-response
equivalence.