Repository navigation
Fetch reference data through fwl-io and require the tables each run reads - #919
Merged
Merged
Conversation
The Hammond et al. (2024) surface reflectance spectra are declared in the PROTEUS manifest as atmos_clim.surface_albedos.hammond_2024, pinned to Zenodo record 15880455 with a checksum registry, and fetched with fetch_dataset into the versioned dataset directory. A failed fetch raises, since AGNI needs the file. atmos_clim.agni.surf_material now names a file inside that dataset directory, for example lunarmarebasalt.dat, so the r<record-id> segment never appears in a configuration. The path form surface_albedos/Hammond24/<file> is also accepted and selects the same file. Any other value stays relative to FWL_DATA, and an absolute path is used as given. A bare file name previously resolved against FWL_DATA and now resolves into the Hammond dataset directory. The Hammond24 entry is removed from DATA_SOURCE_MAP. The example and dummy AGNI configurations, the data page and the regenerated configuration reference use the file name form.
The Seager et al. (2007) iron, silicate and water tables (Zenodo record 15727998) are described by a manifest table under the key interior_struct.eos.seager_2007, with a registry of the three files. download_Seager_EOS fetches the dataset through fetch_dataset, and both get_zalmoxis_EOS and load_zalmoxis_material_dictionaries resolve the tables through dataset_dir, so the location is $FWL_DATA/interior_struct/eos/seager_2007/r15727998. The legacy map entries for the Seager tables and the Population entry are removed, along with the fallbacks to $FWL_DATA/EOS_material_properties/EOS_Seager2007. A copy in that legacy directory is no longer read; the data must be fetched again.
The 13 spectral-file records (Dayspring, Frostflow and Honeyside at 16, 48, 256 and 4096 bands, and Oak at 318 bands) are declared in the manifest as `atmos_clim.spectral_files.<group>_<bands>`, each with a committed registry of file checksums. `spectral_file_key(group, bands)` builds the key, and `download_spectral_file` fetches it through `fetch_dataset`. `get_spfile_path` resolves the file inside the dataset's version directory, `$FWL_DATA/atmos_clim/spectral_files/<group>_<bands>/r<record-id>/`, so AGNI and JANUS receive the versioned path. The 13 spectral entries are removed from `DATA_SOURCE_MAP`, so the OSF fallback for these files is gone and the data must be fetched again into the new location. `proteus doctor` now checks `FWL_DATA/atmos_clim/spectral_files`, and `tools/postprocess.jl` finds the Honeyside 4096-band file in the versioned directory. The reference and doctor docs describe the new layout. Tests pin each record and location, check that every entry in `SPECTRAL_FILE_FOLDERS` has a manifest table and no leftover map entry, and check that `get_spfile_path` resolves into the versioned directory.
The three records (solar 17981836, Named 15721440, MUSCLES 17802209) are declared in the manifest as `stellar_spectra.solar`, `stellar_spectra.named` and `stellar_spectra.muscles`, each with a committed registry of file checksums. Files land in `$FWL_DATA/stellar_spectra/<name>/r<record-id>/`. `init_star` and `proteus solar` resolve the directory through `dataset_dir`, and `download_stellar_spectra` fetches the three datasets through `fetch_dataset`. PHOENIX stays on the legacy downloader. `download_muscles` keeps its per-star mode through the new `fetch_dataset_file`, which fetches one file of a declared dataset and verifies it against the registry. `force=True` deletes the existing files before the fetch. The three entries are removed from `DATA_SOURCE_MAP`, so the OSF fallback for these files is gone and the data must be fetched again into the new location. The lowercase `named` and `muscles` directories differ from the former `Named` and `MUSCLES` only by case, which a case-insensitive filesystem treats as one directory. Tests pin each record, location and registry size, and cover the whole-record, single-star, multi-star and failed-fetch paths of `download_muscles`. The reference page describes the new layout and corrects the provisioning table for the datasets that already use fwl-io. The integration fixture prefetches data for runs that select MORS, so the star spectra exist before the offline run starts. The packaging test derives the expected registry set from the manifest instead of a fixed count.
Six equation-of-state datasets move from the legacy record downloader into the manifest under interior_struct.eos: Wolf and Bower 2018, RTPress 100 TPa, PALEOS MgSiO3 two-phase (standard and high resolution), PALEOS unified, and Chabrier 2021. The tables land in $FWL_DATA/interior_struct/eos/<dataset>/r<record-id>/, and the Zalmoxis material dictionaries resolve their paths from the versioned directories. The PALEOS unified record is fetched one file at a time, so a run that needs one component does not pull the full 2.29 GB record. The RTPress family also fetches the Wolf and Bower solid density file that its registry entry references, which closes a missing-file failure for RTPress-only configurations. The Chabrier archive is extracted by fwl-io, and the archive metadata files it contains are now kept in the extracted tree. The seven legacy DATA_SOURCE_MAP entries and their download helpers are removed. Copies under $FWL_DATA/zalmoxis_eos are no longer read, so an existing installation fetches the tables again on the next run that needs them.
The PHOENIX grid moves from the legacy record downloader into the manifest as stellar_spectra.phoenix. The dataset registry lists all 52 archives of the Zenodo record, one per metallicity and alpha enhancement, and the files land in $FWL_DATA/stellar_spectra/phoenix/r17674612/. download_phoenix asks fwl-io for the single archive of the requested grid, verifies it against the registry checksum, and unpacks it into FeH<FeH>_alpha<alpha>/ beside the archive. The other archives of the 9.2 GB record are not downloaded, and the alpha override at run time fetches its own archive on demand. The archive is kept after unpacking so that the fwl-io dataset check finds every registry file present. The PHOENIX entry is removed from DATA_SOURCE_MAP. Copies under $FWL_DATA/stellar_spectra/PHOENIX are no longer read, so an existing installation fetches the grid it needs again on the next run.
The Wolf and Bower 2018 P-S lookup table and the Monteux+600, Monteux-600 and Wolf and Bower 2018 melting curves move from the legacy record downloader into the manifest under interior_struct.lookup and interior_struct.melting_curves. The lookup table lands in $FWL_DATA/interior_struct/lookup/wolf_bower_2018_1tpa/r19473625/, and each melting curve in $FWL_DATA/interior_struct/melting_curves/<name>/r<record-id>/. resolve_lookup_table_dir and resolve_melting_curve_files locate the fetched datasets for every caller. SPIDER and Aragog read the lookup table in the order a local FWL_DATA/interior_struct/eos/dynamic override, the fetched dataset, then the table bundled with the SPIDER submodule; find_lookup_table_dir reports the fetched directory only when the phase-property files it needs are actually present. A melting curve resolves to a local interior_lookup_tables/Melting_curves/<name> directory when one holds both P-T files, otherwise to the fetched dataset for one of the three names the manifest serves; any other name raises. The ARAGOG_BASIC constant and the six DATA_SOURCE_MAP entries for the lookup table and the melting curves are removed, and so is the step that copied a fetched solidus.dat/liquidus.dat into solidus_P-T.dat/liquidus_P-T.dat, since resolve_melting_curve_files now reads the fetched files directly. get_zalmoxis_EOS resolves the Wolf and Bower and RTPress directories through dataset_dir instead of a chain of legacy folder guesses. Copies under FWL_DATA/interior_lookup_tables are no longer read, so an existing installation fetches the four datasets again on the next run that needs them. Tests for resolve_melting_curve_files, resolve_lookup_table_dir and find_lookup_table_dir cover the local-directory precedence, a partial local directory falling back to the fetched dataset, and an unrecognised name. The download_melting_curves and download_interior_lookuptables tests replace the old download() mocks with fetch_dataset mocks and check that clean removes only the fetched dataset, never a local directory. The SPIDER and Aragog EOS-path tests exercise the new fetched-tier fallback, the manifest test suite pins the four new dataset entries and their registry checksums, and the reference page documents the new locations and the resolution order.
download_stellar_tracks only checked GetFWLData()/stellar_evolution_tracks/Spada after a download, which was the legacy path. A migrated MORS puts the Spada tracks under its own versioned directory, so the check failed and PROTEUS fell back to the OSF mirror even though the fwl-io fetch had already succeeded. I mirror what I already do for Baraffe: when the installed MORS exposes spada_data_dir, verify there instead of the legacy path. An older MORS with no such accessor still falls back to the legacy check, so both MORS versions work. Added tests for the versioned and the legacy case. This needs the MORS release built from tl/mors-spada-manifest; the fwl-mors floor in pyproject still needs bumping to that release separately.
Both releases carry the manifest support the migrated datasets need, so the minimum versions follow them. The data tests now check a second property each: the legacy downloader stays unused, a local melting-curve directory survives a clean, the fetch is attempted once, and the liquidus comes from the local files as well.
The spectral files, stellar spectra, equations of state, melting curves and the Wolf and Bower lookup table are declared in the shared manifest that fwl-io ships, and fwl-io relocate moves legacy trees to those keys. PROTEUS now reads them under the same keys instead of declaring the records a second time, so an existing tree moves into place without a new download and each record exists once on disk. proteus_manifest.toml keeps the data only PROTEUS reads: the exoplanet catalogue, the Zeng mass-radius curves, the Hammond surface spectra and the Seager tables. A test fails if a record is declared in both manifests. Records that hold more than a run reads are fetched file by file: the Wolf and Bower and RTPress tables Zalmoxis uses, the 150 or the 600 points-per-decade PALEOS MgSiO3 pair, and one unified PALEOS table per material. Each start-of-run fetch step now reports a failure and lets the next step run. fwl-io raises RuntimeError subclasses, which the OSError guard did not catch, so one unreachable mirror aborted the run before any other dataset was tried. The fetched lookup table is used only when every SPIDER table file is present, so an interrupted fetch falls back to the tables bundled with SPIDER. The Zalmoxis EOS paths use the data root the fetch writes to. generate_spider_phase_boundaries.py reads fetched melting curves and writes its output to the local folder SPIDER reads. postprocess.jl picks the Honeyside 4096 version directory by numeric record id.
download_stellar_tracks reports a failed download as RuntimeError, like the fwl-io fetch errors, so the start-of-run guard now catches RuntimeError and OSError. A missing track set then fails where it is read, and the spectral files and interior tables are still fetched.
The per-step guard catches OSError and the fwl-io fetch errors only, so a stale fwl-io or a programming error still raises, and the outer guard in download_sufficient_data catches OSError as before. The stellar-track step also catches RuntimeError, which is how download_stellar_tracks reports a failed download. Each stellar spectrum collection is fetched on its own, so a failing named-star record does not stop the solar or MUSCLES spectra. The melting curves are fetched outside the guard: without them SPIDER and Aragog fall back to other curves, so a failed fetch stops the run instead of changing its physics. A key missing from both manifests names the fwl-io version the shared keys need. proteus doctor checks star/spectra. generate_spider_phase_boundaries.py resolves its T(P) input as a run does. postprocess.jl skips version directories without a numeric record id. The data page says which legacy folders fwl-io relocate moves.
When interior_struct.melting_dir is set and its curve files are missing, _provide_spider_eos_tables and the SPIDER phase-boundary setup now raise FileNotFoundError, naming the melting_dir and the missing files. Before, they logged a warning and ran with the curves bundled with SPIDER, a different solidus and liquidus from the configured one. The check sits in the reader, so it also covers offline runs. With the reader enforcing this, the melting-curve fetches go back under the per-step guard: a failed fetch, including an OSError from a read-only or full data root, is logged, the later steps still run, and a curve the run needs stops it when it is read. A Wolf and Bower outage no longer stops runs that use another curve. download_stellar_tracks raises DownloadError when the tracks cannot be obtained, and lets any other error from MORS through unchanged, so a stale fwl-io inside MORS is not reported as a network problem. The fwl-io error classes are imported when needed, so an fwl-io older than the floor gets the upgrade message, which a schema error in the shared manifest now also gives. An unknown key names the installed fwl-io version. postprocess.jl warns about several versions only when several parse.
A constant-property SPIDER run passes no phase boundaries, so it no longer resolves melting curves and cannot stop on missing ones. A missing configured curve raises MissingMeltingCurveError, which the dummy-structure liquidus_super handler passes through unchanged instead of reporting a missing table set. The error names `proteus get interiordata --config-path`, which fetches the configured curve, and the SPIDER message about missing P-S files points to the phase-boundary tool only. The fetch error classes are resolved before a step runs, so on an fwl-io older than the floor an unrelated error in the step is no longer replaced by the upgrade message. An fwl-io without a shared manifest gets the upgrade message, and the unknown-key message no longer depends on package metadata. download_stellar_tracks raises one DownloadError when the OSF fallback finds nothing, and its docstring lists what it raises. The data page and the docstring of _provide_spider_eos_tables say which runs read melting_dir: with a PALEOS mantle equation of state the curves come from the PALEOS liquidus and melting_dir is not read.
download_stellar_tracks now imports DownloadError after _fetch_errors(), so an fwl-io without the error classes gives the upgrade message instead of a bare ImportError, and MORS is not called. In _dataset, only the import of shared_manifest_path is reported as a stale fwl-io. An ImportError raised while the shared manifest loads propagates as it is. The melting-curve resolution in _try_spider sits under one const_properties check. Tests assert the missing-curve messages name the right remedy (the fetch command for P-T files, the generate tool for P-S files), the MissingMeltingCurveError type, and the MORS failure as the cause of the OSF DownloadError.
Without a PALEOS table set, SPIDER and Aragog take their solidus and liquidus from interior_struct.melting_dir. When it was unset, _provide_spider_eos_tables used whichever curves it found on disk (the fetched Wolf and Bower set or the SPIDER bundle), and _try_spider failed with a TypeError. Both now raise MissingMeltingCurveError naming melting_dir; a SPIDER run with constant properties reads no curves and is exempt. This matches the rule aragog.py already applies. With module = "zalmoxis" and a PALEOS mantle EOS the curves are derived from PALEOS, so a configured melting_dir is not read. The config now logs one warning when it is set in that case. MissingMeltingCurveError moves to interior_energetics.common so spider.py raises the same type as the wrapper for a missing P-S curve. The resolution tests of _provide_spider_eos_tables now run with a configured curve, and the docs describe both rules.
_provide_spider_eos_tables now reuses a complete set already placed for the run before it asks for melting_dir, so an unset melting_dir stops the run only when the curves would come from FWL_DATA or the SPIDER bundle. The constant-property exemption applies to SPIDER only, since Aragog reads the curves in that mode too, and both error messages name the configured mantle EOS. The config warning skips PALEOS mixture strings: generate_spider_tables resolves only single-component entries, so a mixture gets no PALEOS table set and melting_dir is read. The docs name the SPIDER exemption and describe the warning as given when the configuration is loaded.
The dummy structure no longer calls generate_spider_tables. With SPIDER or Aragog energetics, it takes the P-S tables from FWL_DATA or the SPIDER lookup data, and the curves named by interior_struct.melting_dir, in every temperature mode, through _provide_spider_eos_tables. A dummy run used PALEOS tables only when an earlier Zalmoxis run had left the PALEOS files in FWL_DATA, so the curves depended on the machine, and Aragog read melting_dir while its entropy tables came from PALEOS. The start-of-run fetch gets the Wolf and Bower P-S set for the dummy structure, also when interior_struct.eos_dir is unset. If no table source exists, a RuntimeError names both modules and the fetch command. The initial-conditions guide and the dummy module page now describe this: the dummy structure reads the FWL_DATA tables, SPIDER or Aragog read melting_dir, and PALEOS is not used. Closes #905
needs_spider_ps_tables decides when a run reads the Wolf and Bower P-S set: with SPIDER or Aragog energetics, unless Zalmoxis generates a PALEOS table set from a single-component PALEOS mantle EOS. The start-of-run fetch uses it, and so does proteus get interiordata --config-path, so an offline run with the dummy structure, or with Zalmoxis and a non-PALEOS or mixed mantle EOS, finds the tables it needs. The table and melting-curve errors named proteus get all, which is not a command; they now name proteus get interiordata --config-path. The unset-melting_dir message names the mantle EOS only when Zalmoxis is the structure module, since the dummy and SPIDER structures do not use it. data.md states when the set is fetched.
generates_paleos_tables (utils/helper.py) is now the one test for whether Zalmoxis makes a PALEOS table set: the Zalmoxis structure with a single-component PALEOS mantle EOS. Aragog, the start-of-run table fetch and the config warning use it, so SPIDER, Aragog and the P-S tables of one run read the same curves. Aragog took the PALEOS-derived curves for any mantle EOS with a PALEOS prefix, mixtures included, while a mixture gets no generated table set, so SPIDER and the entropy tables read melting_dir. The curve choice now lives in _melting_curve_files, and a mixture reads melting_dir; the entropy cross-check against the PALEOS anchor is skipped for it as well.
compute_initial_entropy solved the PALEOS P-T anchor, and capped the P-S initial entropy at its entropy, for any mantle EOS with a PALEOS prefix. The cap keeps the initial condition off the filled cells of a PALEOS-generated table set, and a mixture gets no such set: its P-S tables come from melting_dir, while the anchor used the pure MgSiO3 PALEOS liquidus. The anchor and the cap now apply only when generates_paleos_tables is true, so a mixture solves its initial condition on the melting_dir tables alone. _anchor_failure_deferred uses the same test, so a failed structure anchor for a mixture propagates instead of waiting for an initial-condition solve that no longer runs.
The parametrized test of _anchor_failure_deferred also asserts that energetics without an initial-condition anchor solve never defer a failed structure anchor, for every mantle EOS case.
generates_paleos_tables now asks the Zalmoxis material registry for the exact mantle EOS key, the lookup generate_spider_tables makes. A string such as "PALEOS:MgSiO3:1.0", one with trailing whitespace, or an unknown PALEOS material gets no generated set, so the fetch, the config warning, the anchor cap and Aragog treat it as SPIDER does. Aragog builds its P-T property tables from PALEOS only when that set is generated. A PALEOS mixture now reads density, heat capacity and expansivity from the Wolf and Bower (2018) set or interior_struct.eos_dir, the family of its P-S tables and melting_dir curves, so no cell between the two liquidi reads a PALEOS phase table on the wrong side of its own liquidus. A warning names the table edge when P_cmb is above 1 TPa. needs_spider_ps_tables and data.md state that a set eos_dir asks for the P-S set. The initial-conditions guide states which tables a mixture reads and scopes the constant-property exemption to SPIDER energetics.
generates_paleos_tables compares the mantle EOS with PALEOS_REGISTRY_KEYS, a fixed set of the PALEOS keys of the Zalmoxis material registry, instead of building the registry. Config validation calls it, and building the registry imported Zalmoxis and created the FWL_DATA folder there. A test keeps the set equal to the PALEOS keys of load_zalmoxis_material_dictionaries. The Aragog table-edge warning applies only to the fetched Wolf and Bower set, not to a table set named by interior_struct.eos_dir, and the test pins the threshold from both sides. The initial-conditions guide says that the Wolf and Bower set is indexed by pressure and entropy and that the edge warning needs the Zalmoxis structure, which sets P_cmb. data.md says that eos_dir asks for the set only with SPIDER or Aragog.
A PALEOS mixture reads the fetched Wolf and Bower set, which the start-of-run fetch gets for it; an offline run without the set now stops with a message that names proteus get interiordata --config-path.
Aragog takes its thermodynamics and melt fraction from the P-S entropy tables, not from the phase-property files in its lookup directory. The table-edge warning now compares the core-mantle boundary pressure with the upper pressure of the loaded P-S tables, for every structure module and table set, and uses the Noack and Lasbleis (2020) estimate when the structure gives no P_cmb, as with the dummy structure. The initial-conditions guide states this. The table-choice test covers an eos_dir whose tables are missing, and the test entropy EOS carries an upper pressure.
The Aragog table-edge warning now checks the core-mantle boundary pressure only when the structure gives it, as Zalmoxis does, and uses the relative tolerance of the liquidus_super check. The Noack and Lasbleis estimate is not used, since Aragog's own mesh pressure can differ from it by more than the margin to the edge. The missing P-S table error also names proteus get interiordata --config-path. Tests cover P_cmb under, at and over the edge, a second table edge, a row without a structure P_cmb, and the error message. The initial-conditions guide states the edge as the highest pressure of the P-S table set in use.
…igrate-dark # Conflicts: # src/proteus/interior_energetics/spider.py # src/proteus/interior_struct/zalmoxis.py # tests/interior_energetics/test_aragog.py # tests/interior_struct/test_zalmoxis.py
The data page now lists the status code of each missing-data stop and names the two stops without a download command: a spectral file of an undeclared group and band count, and PALEOS-API tables, which are built from the paleos package.
A legacy folder with wrong or missing files made the doctor propose `fwl-io relocate`, which then moved nothing, so `proteus update` asked again. The doctor now reads the relocate dry-run plan and proposes relocate only for a legacy folder that holds a dataset it would move; otherwise it proposes the download.
AGNI stops with status 20 and the fetch command when the spectral file of its group is missing. The PHOENIX command is checked with distinct non-zero [Fe/H] and alpha, the 2-phase pair error with its relocate hint, the energetics check with another structure module and a NaN fraction at load. The stellar test checks that the error is logged and that no line names another star. The required flag of the pair lookup and the resume rule for liquidus_super are described as they are.
The 2-phase pair lookup, the P-S table inputs and the Aragog table set called the PALEOS-API resolver directly, so without paleos they hung on the resolver's worker pool and every call ran git again. resolve_paleos_api checks for paleos, keeps resolved entries per process and serves all four sites. A required PALEOS-API pair names the paleos package instead of a download, and a generated table removed since its build is reported as not built and built again.
A zero fraction left a mixture member out of the structure while the energetics could still follow it, so every fraction must now be positive. The doctor compares resolved paths, so a data root reached through a symlink or given with ~ still gets the relocate proposal. The status-20 test also covers a stop at the start check, and three long doc sentences are split.
A missing melting curve, SPIDER or Aragog P-S table or Aragog lookup table stopped the run without an error status. These stops now raise MissingDataError, a FileNotFoundError, so every existing fallback catches them as before, and it shares the MissingReferenceData base with the Zalmoxis EOS error, which the start() handler turns into status 20.
…d table The dummy structure turned a missing SPIDER or Aragog P-S table into a plain RuntimeError, so the run stopped without status 20; it now raises MissingDataError with the same message. A PALEOS-API entry kept from an earlier resolve whose tables were removed is resolved again, which rebuilds them, before the check reports anything. Tests reach the wrapper, Aragog lookup and Aragog P-S stops at their real raise sites, the paleos guard through importlib itself, and the P-S table inputs of a PALEOS-API mantle.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #919 +/- ##
==========================================
+ Coverage 95.07% 95.40% +0.32%
==========================================
Files 127 127
Lines 20547 20808 +261
Branches 3524 3522 -2
==========================================
+ Hits 19535 19851 +316
+ Misses 993 918 -75
- Partials 19 39 +20
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The fwl-mors badge now shows the >=26.9.23 pin from pyproject.toml.
The relocate dry run hashes every dataset in the data tree, which made `proteus doctor` several seconds slower on every call. It now runs only when a data set is missing and its older-layout folder holds files, the one case where its result changes the proposed fix.
A failing doctor check writes a failure log whose environment summary runs slow commands such as conda list, so the test hit its 30 s timeout in the pixi environment. The test stubs that summary and writes the log under tmp_path instead of the repository root.
The failure path of install.sh runs `conda list` to collect diagnostics, and in the pixi environment that call can exceed the 15 s test timeout. A stub conda first on PATH keeps the test to the error message, which still has to name conda and `conda create`.
Member
Author
|
This would be great to be reviewed, as it has many consequences for the PROTEUS workflow. |
The failure path of install.sh runs `conda list` for its diagnostics, and the first conda call on a CI runner can take longer than the 15 s test timeout. A module-level fixture now puts a no-op conda first on PATH for every test in the module, replacing the stub in the single no-env test. The tests still check the error messages, and install.sh is unchanged.
Member
Author
|
This is somewhat block me so I am going ahead soon. |
The spectral-cache tests patch require_spfile_path, the function the AGNI wrapper calls. The accretion main-loop test stubs the EOS table provision, which this branch runs at structure setup, so the test runs without melting curve files as the same test does on main. The output scan reads VOLATILE_EOS_MAP from proteus.utils.constants as a species domain, so the volatile profile reads in zalmoxis.py resolve to H2O and H2 and the output reference matches main.
The accretion main-loop test counts the P-S table provisions and expects one at setup and one at the impact re-solve, with a real melting_dir set. A second test makes the provision at the impact raise MissingMeltingCurveError and checks that start() re-raises it, writes status 20 and leaves the impact row out of the helpfile. A third test spies on _check_crystallization and checks that start() calls it after the init stage and never during it.
8 tasks done
IKisvardai
added a commit
that referenced
this pull request
Oct 1, 2026
Brings in the accretion module (#789), the fwl-io data fetch (#919) and the AGENTS.md move (#798). The helpfile registry, the golden trajectory and the migration test keep both the trapping and the accretion columns, and the trapping sites are declared in the scanner's per-function override table that #789 introduced. The output and config references are regenerated.
timlichtenberg
added a commit
that referenced
this pull request
Oct 1, 2026
Since #919 a run with Aragog and a mantle EOS without a generated PALEOS table set needs interior_struct.melting_dir. The WolfBower2018 case of test_zalmoxis_2layer_non_tdep_requires_zero_mantle_mass_fraction had none and failed on that check in the integration tier, so its config now sets melting_dir = "Monteux-600" and the test reaches the value it checks again.
8 tasks done
8 tasks done
timlichtenberg
added a commit
that referenced
this pull request
Oct 1, 2026
…le (#938) Since #919, the dummy structure placed the Wolf and Bower P-S set and the melting_dir curves for SPIDER and Aragog, also when the mantle EOS was PALEOS. Such runs then started from a different state, fully molten at 3360 K instead of 1718 K on a dummy-structure Aragog case, and the dummy-structure accretion resume tests failed. The dummy structure now follows mantle_eos. With a PALEOS mantle EOS, where a mixture follows its MgSiO3 component, it builds and uses the PALEOS P-S tables, their solidus and their liquidus, as the Zalmoxis structure does, and it fetches the PALEOS tables it needs. A non-PALEOS mantle keeps the Wolf and Bower set and melting_dir. Aragog still requires melting_dir under the dummy structure, and a melting_dir that the solve does not use logs a warning. The Zalmoxis structure is unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
PROTEUS now fetches and reads its reference data through fwl-io manifests, in the versioned FWL_DATA layout: SOCRATES spectral files, solar, Named, MUSCLES and PHOENIX stellar spectra, the Hammond surface spectra, the Seager and Zalmoxis EOS tables, the melting curves and the P-S lookup tables. It also sets which tables a Zalmoxis run needs and stops a run with missing data before it starts. Closes #905, closes #907.
Changes:
liquidus_superanchor read it, and PALEOS-API tables resolved at start (the check stops at once whenpaleosis not installed).proteus doctorproposesfwl-io relocateonly when it would move something, and names theproteus getcommand otherwise.Upgrading an older data folder
fwl-io relocate. It moves every dataset whose files all match their pinned checksums into its version directory;fwl-io relocate --dry-runlists what would move, what is incomplete and what does not match.proteus start --config <config.toml>once without--offline, which downloads the data that configuration needs, orproteus get interiordata --config-path <config.toml>for the interior tables alone. This downloads what the first step left: incomplete and mismatched datasets, and those relocate cannot move (the Chabrier archive, the surface albedos, the Seager tables and the Spada tracks).PHOENIX keeps each downloaded zip beside the extracted grid, so a PHOENIX grid takes about twice its extracted size on disk.
Validation of changes
Checklist