add ensemble avg for routing and landice ( one landice member so far)

[weiyuan-jiang]

Adds ensemble capability in GEOSldas for Route and Landice. The latter is hardwired to N_ens_landice=1 for now.

After merge, the following inputs to the GEOSldas regression test suite must be edited:

• /discover/nobackup/mathomp4/LDAS_Restarts/NGHTLY_TST_TV4000/HISTORY_L4_SM.rc
• /discover/nobackup/mathomp4/LDAS_Restarts/NGHTLY_TST_CS/assim/ldas179b8_C180/run/HISTORY.rc

These files are used by the GLOBAL[CS]/assim tests. Within the files, replace ENSAVG with LANDAVG.

Related PRs:
GEOS-ESM/GEOSgcm_GridComp#1421. (merged 21-July-2026)

cc: @mathomp4

[weiyuan-jiang]

This PR is zero-diff

[zyj8881357]

I have checked the PR with six members of ensemble run and compared with discharge observations. The results look good.

[gmao-rreichle]

@weiyuan-jiang : Thanks again for sorting through the ensavg output across the various new GridComps, this is great!

I added a couple of commits:

• 6787d9a, 4a34a1c: Renamed "ForceAvg" to "MetforceAvg" for consistency.
• ae53b7d: Fixed a HISTORY file used in the coupled land-atm DAS.
• cc05e77, 835d8fa: Resolved conflicts with current "develop" branch (ISSM-related).

Please double-check these commits. The big change on develop since the present PR was started is the addition of ISSM under Landice. Since we hardwire Landice to a single ensemble member, I assume that no further action is needed to accommodate ISSM within the new Landice ensemble capability. Is that correct? Or might the addition of ISSM require changes in the revised "ensavg" GridComp?

PS: I'm submitting this comment before the CI build completes. Apologies if I introduced a build error. If I did, I'll fix it tomorrow.

[gmao-rreichle]

@weiyuan-jiang : I don't understand why this branch built successfully yesterday. It should depend on NUM_SNOW_LAYERS and NUM_ICE_LAYERS being made public in the Landice GC, which is part of GEOS-ESM/GEOSgcm_GridComp#1421 but not on the GCM GC "develop" branch (which is presumably used by CI in the build test).

In looking a bit more into this, I noticed that NUM_SNOW_LAYERS and NUM_ICE_LAYERS exist with the same names in both the Landice GC and the sea ice model (CICE). That's ok as long as the variables are not public, but now we need the variables from LANDICE to be public. To make this safer, I appended "_LANDICE" to the public name:

• GEOS-ESM/GEOSgcm_GridComp@ffababc
• 029bce9

I still don't understand why the present PR builds without seeing the branch that makes the NUM_*_LAYERS public. I did not find anything that made the sea ice variables public, maybe I missed it. Can you explain this?

[weiyuan-jiang]

@weiyuan-jiang : I don't understand why this branch built successfully yesterday. It should depend on NUM_SNOW_LAYERS and NUM_ICE_LAYERS being made public in the Landice GC, which is part of GEOS-ESM/GEOSgcm_GridComp#1421 but not on the GCM GC "develop" branch (which is presumably used by CI in the build test).

In looking a bit more into this, I noticed that NUM_SNOW_LAYERS and NUM_ICE_LAYERS exist with the same names in both the Landice GC and the sea ice model (CICE). That's ok as long as the variables are not public, but now we need the variables from LANDICE to be public. To make this safer, I appended "_LANDICE" to the public name:

• GEOS-ESM/GEOSgcm_GridComp@ffababc
• 029bce9

I still don't understand why the present PR builds without seeing the branch that makes the NUM_*_LAYERS public. I did not find anything that made the sea ice variables public, maybe I missed it. Can you explain this?

I guess it wasn't really build with develop branch but the right branch of GEOS-ESM/GEOSgcm_GridComp#1421

[gmao-rreichle]

I guess it wasn't really build with develop branch but the right branch of GEOS-ESM/GEOSgcm_GridComp#1421

But where/how do we tell the CI build test to use the branch associated with GEOS-ESM/GEOSgcm_GridComp#1421 rather than the "develop" branch?

cc: @mathomp4