Jon Wolfe

@xylar -- no, I don't remember why we would have done that. But it was many years ago... I looked and it seems like we were getting start times from...

OK, I think I understand what is happening -- and have a possible solution. First, for E3SM the mpas components get their config_start_time settings from the coupler/system using code blocks...

@zhangshixuan1987 -- have you tried using the env_run.xml settings instead?

@zhangshixuan1987 -- I'm not sure the mpas components are working as you expect. The config_start_time in the namelist is not used by the code in e3sm. But you're also correct...

Thanks @zhangshixuan1987. Please let me know if it works for you

@rljacob -- we did merge #5123 last December, so it's not that

But it did take some effort to get the results blessed, because #5123 changed output file names and blessing ti required some special commands from @jgfouca: SES-2269 09/Feb/23 So that's...

And at least some of the FAILs look like: ```` 2023-03-01 05:37:33: BASELINE FAIL for test 'JNextAtm_nbfb20230301_003435'. Test status: fail; Variables analyzed: 121; Rejecting: 24; Critical value: 13; Ensembles: statistically...

Thanks @ekluzek - that's a perfect description and I appreciate you opening an issue over the error message

Tested by running the e3sm_landice_developer suite on chrysalis with gnu. The new test passes, though there are issues with the gnu compiler that impact other tests merged to next