search

ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
302 stars 307 forks source link

History variable `FATES_TRANSITION_MATRIX_LULU` contains garbage for `FatesColdDryDepSatPhen` and `FatesColdMeganSatPhen` #2656

Closed slevis-lmwg closed 1 week ago

slevis-lmwg commented 1 month ago

Yep, those cases are definitely garbage, but they've been that way for these two tests since that variable was introduced in ctsm5.2.013. Those values should be zero'd out. I'm not sure why the FatesColdSatPhen correctly zeros FATES_TRANSITION_MATRIX_LULU, but FatesColdDryDepSatPhen and FatesColdMeganSatPhen does not.

Originally posted by @glemieux in https://github.com/ESCOMP/CTSM/issues/2605#issuecomment-2243842711

slevis-lmwg commented 1 month ago

I originally spotted the problem in #2605 as a strange difference from baseline in these two tests:

SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdDryDepSatPhen.GC.0719-175606de_gnu/SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdDryDepSatPhen.GC.0719-175606de_gnu.clm2.h0.2000-01-01-00000.nc.cprnc.out: RMS FATES_TRANSITION_MATRIX_LULU       Infinity            NORMALIZED    Infinity
SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdMeganSatPhen.GC.0719-175606de_gnu/SMS_D.1x1_brazil.I2000Clm60FatesSpCruRsGs.derecho_gnu.clm-FatesColdMeganSatPhen.GC.0719-175606de_gnu.clm2.h0.2000-01-01-00000.nc.cprnc.out: RMS FATES_TRANSITION_MATRIX_LULU       Infinity            NORMALIZED    Infinity
glemieux commented 1 month ago

Checking the difference between FatesColdSatPhen testmod, which appropriately zeros FATES_TRANSITION_MATRIX_LULU, and these failing testmods, the only difference are the expected settings in shell_commands (i.e. CLM_BLDNML_OPTS set to '--drydep' or '--megan').

glemieux commented 1 month ago

This might simply be an initialization error on the fates side that is only showing up with gnu compiler tests. I noticed that the instances of FatesColdSatPhen that I've been checking are either intel or nvhpc. Testing.

glemieux commented 1 month ago

This might simply be an initialization error on the fates side that is only showing up with gnu compiler tests. I noticed that the instances of FatesColdSatPhen that I've been checking are either intel or nvhpc. Testing.

It looks like this is actually the case. Running gnu compiled version of the FatesColdSatPhen test results in the transition matrix reporting junk. I'll open an issue on the fates-side and cross reference here.

glemieux commented 1 month ago

This probably is being missed in more tests that are based on the Fates testmod as history output is being cleared and this output is not added.

glemieux commented 1 month ago

fates issue: https://github.com/NGEET/fates/issues/1230

glemieux commented 1 month ago

Note that this will be resolved via https://github.com/NGEET/fates/pull/1231, which will likely be fates tag sci.1.77.2_api.36.0.0. This tag could come in with #2594.

glemieux commented 1 month ago

This is fixed on fates main via sci.1.77.2_api.36.0.0.

glemieux commented 1 week ago

This should be fixed by #2624