Sync with ESCOMP/CDEPS (2024-10-07)

[NickSzapiro-NOAA]

Description of changes

Merge authoritative ESCOMP into EMC fork (+cmake includes for new files)

Specific notes

Contributors other than yourself, if any: N/A

CDEPS Issues Fixed (include github issue #): #65

Are there dependencies on other component PRs (if so list): No

Are changes expected to change answers (bfb, different to roundoff, more substantial): bfb except for character dimension increase to CX

Any User Interface Changes (namelist or namelist defaults changes): No

Testing performed (e.g. aux_cdeps, CESM prealpha, etc): UFS RT suite + preceding ESCOMP/CDEPS tests

Hashes used for testing: See UFS PR (todo)

[NickSzapiro-NOAA]

Maybe it is a good time to fix ufs-community/ufs-weather-model#1548 ?

[uturuncoglu]

@NickSzapiro-NOAA Sorry for late response. Yes, it would be nice to work on ufs-community/ufs-weather-model#1548. I'll also try to review the PR. I think this PR also sync with ESCOMP. Right?

[NickSzapiro-NOAA]

Thanks in advance for review, @uturuncoglu! Yes, this sync PR is a git merge of ESCOMP/CDEPS into EMC fork

For consistent keys, it seems straightforward to just copy the xml keys (they seem more concise...)

stream_info  <-- stream_info
taxmode <-- taxmode
tintalgo <-- tInterpAlgo
readmode <-- readMode
mapalgo <-- mapalgo
dtlimit <-- dtlimit
yearFirst <-- yearFirst
yearLast <-- yearLast
yearAlign <-- yearAlign
vectors <-- stream_vectors
meshfile <-- stream_mesh_file
lev_dimname <-- stream_lev_dimname
datafiles <-- stream_data_files
datavars <-- stream_data_variables
offset <-- stream_offset

But how deep into the component source code does this impact? These are explicitly in CICE for example in a section using CDEPS inline:
https://github.com/NOAA-EMC/CICE/blob/develop/cicecore/drivers/nuopc/cmeps/ice_prescribed_mod.F90#L98-L107
If for other components too, there is a bigger cost to cleaning this up

[uturuncoglu]

@NickSzapiro-NOAA Yes, making those configuration files consistent would be great but I am not sure about its downstream effect. The workflows etc. (recently I implemented CDEPs driver in UWtools side) might also need to have changes. I am not sure how it will be handled. Any idea?

[NickSzapiro-NOAA]

Given the downstream impact, it's not so friendly to break backwards compatibility without a clear need. One option is to treat both sets of attribute labels as vaild synonyms in shr_stream_init_from_esmfconfig, with the "xml keys" taking precedence if present...

[uturuncoglu]

@NickSzapiro-NOAA I agree. Anyway, let me know if you need any help in my end.

[NickSzapiro-NOAA]

Thanks for review and discussion, @uturuncoglu ! Then, we'll proceed with this sync and separate issue of resolving divergent keys