ESCOMP
fates history flushing
Description of changes
FATES flushes history output arrays to the ignore value, and then zero's out values that are located on fates columns. The flushing need only happen once, since the non-fates columns aren't touched. And the zero'ing should happen on the FATES side of the code since this removes dependence on the interface code.
Specific notes
Contributors other than yourself, if any:
@samsrabin @glemieux
CTSM Issues Fixed (include github issue #):
Are answers expected to change (and if so in what way)?
No
Any User Interface Changes (namelist or namelist defaults changes)?
No
Does this create a need to change or add documentation? Did you do so?
No
Testing performed, if any:
TBD
(List what testing you did to show your changes worked as expected) (This can be manual testing or running of the different test suites) (Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide) (aux_clm on derecho for intel/gnu and izumi for intel/gnu/nag/nvhpc is the standard for tags on master)
NOTE: Be sure to check your coding style against the standard (https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review the list of common problems to watch out for (https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).
@ekluzek once regression testing for https://github.com/NGEET/fates/pull/1231 is done (likely today), I could update this PR to use the new fates tag to address #2656. Assuming aux_clm testing goes well, this could be brought in to master pretty quickly I think.
@rgknox regression testing aux_clm and fates suites on derecho looks pretty good. Issue #2656 is confirmed fixed with this update.
For aux_clm, all non-fates testmods are b4b with one exception,ERP_P64x2_Lm13.f10_f10_mg37.IHistClm60Bgc.derecho_intel.clm-monthly--clm-matrixcnOn_ignore_warnings, which appears to be a known issue per https://github.com/ESCOMP/CTSM/issues/2619#issuecomment-2253332936. There are fates FIELDLIST and NLCOMP diffs that are expected as I removed the LULU dimension output from the base Fates tesmod namelist. The AllVars testmod only has fill pattern differences for FATES_EXCESS_RESP, which I think is expected per history flushing PR https://github.com/NGEET/fates/pull/1208, based on the update to that output's upfreq.
For the fates test suite, the FatesColdLUH2 tests failed RUN due a typo in the history output. I've since corrected this and kicked off rerun of just those tests. Otherwise the same diff types are seen as above in the aux_clm tests, although for the fill pattern only diffs there are more variables represented. Also, there is a BFAIL as I've added an nvhcp compiler version of the SatPhen testmod for more coverage, so it has nothing to compare against.
Test results:
/glade/derecho/scratch/glemieux/ctsm-tests/tests_pr2594-aux/glade/derecho/scratch/glemieux/ctsm-tests/tests_pr2594-fates
This still needs testing on izumi
Merging in latest master updates and rerunning tests on derecho and izumi.
Testing results on for aux_clm against ctsm5.2.027 on izumi are b4b with the expected exception of the fates testmods. The fates testmod diffs are consistent with the diffs per https://github.com/NGEET/fates/pull/1215.
Location: /home/glemieux/scratch/ctsm-tests/tests_0829-105549iz
Regression testing on derecho is complete. All expected non-fates tests pass B4B. There are expected NLCOMP differences due to updates to the fates testmod outputs per this PR. The fates DIFFs are consistent with NGEET/fates#1215 as mentioned above.
Location: /glade/u/home/glemieux/scratch/ctsm-tests/tests_pr2594-aux_clm
On derecho the list of changes to baseline ctsm5.2.027 is:
ERP_Ld9.f45_f45_mg37.I2000Clm50FatesRs.derecho_intel.clm-FatesColdAllVars ERP_P128x2_Ld30.f45_f45_mg37.I2000Clm60FatesSpCruRsGs.derecho_intel.clm-FatesColdSatPhen ERP_P64x2_Lm13.f10_f10_mg37.IHistClm60Bgc.derecho_intel.clm-monthly--clm-matrixcnOn_ignore_warnings EXPECTED POSSIBILITY ERS_D_Ld3_PS.f09_g17.I2000Clm50FatesRs.derecho_intel.clm-FatesCold ERS_D_Ld5.f10_f10_mg37.I2000Clm50Fates.derecho_intel.clm-FatesCold ERS_D_Mmpi-serial_Ld5.1x1_brazil.I2000Clm50FatesRs.derecho_gnu.clm-FatesCold ERS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm50FatesRs.derecho_gnu.clm-FatesCold ERS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60FatesRs.derecho_intel.clm-FatesCold ERS_Ld30.f45_f45_mg37.I2000Clm50FatesRs.derecho_intel.clm-FatesColdFixedBiogeo ERS_Ld9.f10_f10_mg37.I2000Clm50FatesCruRsGs.derecho_intel.clm-FatesColdCH4Off ERS_P128x1_Lm25.f10_f10_mg37.I2000Clm60Fates.derecho_intel.clm-FatesColdNoComp SMS.f45_f45_mg37.I2000Clm60FatesSpRsGs.derecho_nvhpc.clm-FatesColdSatPhen SMS_D_Ld5.f10_f10_mg37.I2000Clm45Fates.derecho_intel.clm-FatesCold SMS_D_Ld5.f10_f10_mg37.I2000Clm50FatesRs.derecho_gnu.clm-FatesCold SMS_D_Ld5.f10_f10_mg37.I2000Clm50FatesRs.derecho_intel.clm-FatesCold SMS_D_Lm6_P256x1.f45_f45_mg37.I2000Clm50FatesRs.derecho_intel.clm-FatesCold SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.derecho_gnu.clm-FatesPRISM--clm-NEON-FATES-YELL SMS_Ld5.f10_f10_mg37.I2000Clm45Fates.derecho_intel.clm-FatesCold SMS_Ld5.f10_f10_mg37.I2000Clm50FatesRs.derecho_intel.clm-FatesCold SMS_Ld5_PS.f19_g17.I2000Clm50FatesRs.derecho_gnu.clm-FatesCold
In those tests the only field that changes is: FATES_EFFECT_WSPEED
On izumi the following tests compare different to baseline, but just for FATES_EFFECT_WSPEED
ERS_D_Ld5.f10_f10_mg37.I2000Clm50Fates.izumi_nag.clm-FatesCold ERS_D_Mmpi-serial_Ld5.1x1_brazil.I2000Clm50FatesRs.izumi_nag.clm-FatesCold ERS_Ld30.f45_f45_mg37.I2000Clm50FatesRs.izumi_intel.clm-FatesColdFixedBiogeo SMS_D_Ld5.f10_f10_mg37.I2000Clm50FatesRs.izumi_nag.clm-FatesCold SMS_D_Ld5.f45_f45_mg37.I2000Clm60Fates.izumi_nag.clm-FatesCold SMS_D_Mmpi-serial_Ld5.5x5_amazon.I2000Clm60FatesRs.izumi_nag.clm-FatesCold SMS_Ld10_D_Mmpi-serial.CLM_USRDAT.I1PtClm60Fates.izumi_nag.clm-FatesPRISM--clm-NEON-FATES-YELL SMS_Ld5.f10_f10_mg37.I2000Clm45Fates.izumi_intel.clm-FatesCold SMS_Ld5.f10_f10_mg37.I2000Clm50FatesRs.izumi_intel.clm-FatesCold
OK, the changes to baseline are just due to the minimal changes that came in the fire weather refactor which just affects: FATES_EFFECT_WSPEED. I double checked that the FATES tag is correct and it is. And both aux_clm and fates baselines are in place, so this is good to go.