Problem
gpp-FLUXNET2015 is the one ILAMB diagnostic whose reference data lives in obs4REF but which cannot be moved to a dict-form sources entry (the form that makes the reference visible to the solver and the solve-regression tests). It is stuck as a string-form registry-key source in packages/climate-ref-ilamb/src/climate_ref_ilamb/configure/ilamb.yaml.
Root cause
The dataset spells its source_id three different ways: FLUXNET2015-1-0 in the obs4REF path, Fluxnet-2015-1-0 in the filename, and Fluxnet-2015 as the internal netCDF attribute. This will break if published as is
Fix
Re-mint / rename the obs4REF FLUXNET2015 dataset so path, filename, and internal source_id attribute all agree on one spelling.
Impact until fixed
gpp-FLUXNET2015 still executes correctly (reference resolved at execute-time via the registry key), but its solve-regression snapshot shows only CMIP model data, not the obs4REF reference.
Problem
gpp-FLUXNET2015is the one ILAMB diagnostic whose reference data lives in obs4REF but which cannot be moved to a dict-formsourcesentry (the form that makes the reference visible to the solver and the solve-regression tests). It is stuck as a string-form registry-key source inpackages/climate-ref-ilamb/src/climate_ref_ilamb/configure/ilamb.yaml.Root cause
The dataset spells its
source_idthree different ways:FLUXNET2015-1-0in the obs4REF path,Fluxnet-2015-1-0in the filename, andFluxnet-2015as the internal netCDF attribute. This will break if published as isFix
Re-mint / rename the obs4REF FLUXNET2015 dataset so path, filename, and internal
source_idattribute all agree on one spelling.Impact until fixed
gpp-FLUXNET2015still executes correctly (reference resolved at execute-time via the registry key), but its solve-regression snapshot shows only CMIP model data, not the obs4REF reference.