Draft code to enable mpas ocean/seaice time series processing with re…

[zhangshixuan1987]

Add robust MPAS ocean/sea-ice time-series regridding

Split MPAS-Ocean and MPAS-Seaice time-series processing into native ncclimo generation followed by explicit ncremap regridding. This allows the workflow to restore MPAS-native time metadata, construct a CF-style numeric time coordinate from timeMonthly_avg_daysSinceStartOfSim, and preserve missing_value metadata after regridding.

For MPAS-Seaice, construct spatial-only SGS helper variables from timeMonthly_avg_iceAreaCell before regridding. This avoids failures when ncremap attempts to use the time-dependent timeMonthly_avg_iceAreaCell field directly as the SGS fraction. Temporary helper variables are removed from final output, and timeMonthly_avg_iceAreaCell is retained only when it is the requested output variable.

Summary

Objectives:

• Add a separate MPAS-Ocean and MPAS-Seaice time-series regridding path using native ncclimo output followed by explicit ncremap regridding.
• Restore MPAS-native time metadata and construct a CF-style numeric time coordinate from timeMonthly_avg_daysSinceStartOfSim.
• Construct valid spatial-only SGS helper variables for MPAS-Seaice regridding to avoid using time-dependent timeMonthly_avg_iceAreaCell directly as the SGS fraction.
• Remove temporary helper variables from final regridded outputs while retaining timeMonthly_avg_iceAreaCell when it is the requested output variable.

Issue resolution:

• Closes #<ISSUE_NUMBER_HERE>

Select one: This pull request is...

• a bug fix: increment the patch version
• a small improvement: increment the minor version
• a new feature: increment the minor version
• an incompatible (non-backwards compatible) API change: increment the major version

Please fill out either the "Small Change" or "Big Change" section (the latter includes the numbered subsections), and delete the other.

Small Change

• To merge, I will use "Squash and merge". That is, this change should be a single commit.
• Logic: I have visually inspected the entire pull request myself.
• Pre-commit checks: All the pre-commits checks have passed.

Big Change

• To merge, I will use "Create a merge commit". That is, this change is large enough to require multiple units of work (i.e., it should be multiple commits).

1. Does this do what we want it to do?

Required:

• Product Management: I have confirmed with the stakeholders that the objectives above are correct and complete.
• Testing: I have added or modified at least one "min-case" configuration file to test this change. Every objective above is represented in at least one cfg.
• Testing: I have considered likely and/or severe edge cases and have included them in testing.

If applicable:

• Testing: this pull request introduces an important feature or bug fix that we must test often. I have updated the weekly-test configuration files, not just a "min-case" one.
• Testing: this pull request adds at least one new possible parameter to the cfg. I have tested using this parameter with and without any other parameter that may interact with it.

2. Are the implementation details accurate & efficient?

Required:

• Logic: I have visually inspected the entire pull request myself.
• Logic: I have left GitHub comments highlighting important pieces of code logic. I have had these code blocks reviewed by at least one other team member.

If applicable:

• Dependencies: This pull request introduces a new dependency. I have discussed this requirement with at least one other team member. The dependency is noted in zppy/conda, not just an import statement.

3. Is this well documented?

Required:

• Documentation: by looking at the docs, a new user could easily understand the functionality introduced by this pull request.

4. Is this code clean?

Required:

• Readability: The code is as simple as possible and well-commented, such that a new team member could understand what's happening.
• Pre-commit checks: All the pre-commits checks have passed.

If applicable:

• Software architecture: I have discussed relevant trade-offs in design decisions with at least one other team member. It is unlikely that this pull request will increase tech debt.

Configuration files used for test

# Directions to run:
# 1. Update <output>, <www>, <environment_commands_secondary> below.
# 2. Run with `zppy -c examples/post.v3.LR.amip.0101.cfg`.
# Direction to create stand-alone test data for zppy-interfaces:
# 3. Once the jobs finish, `cd <output>/post/scripts`.
# 4. Run `grep -n "Running a zi-pcmdi command" pcmdi_diags*.o*` to find the pcmdi_diags commands.
# 5. Then, you can run those lines stand-alone.
[default]
input = /pscratch/sd/z/zhan391/e3smv4_project/20260204.ne256.WCYCLXX1850.SOI
output = /pscratch/sd/z/zhan391/e3smv4_project/20260204.ne256.WCYCLXX1850.SOI
case = 20260204.ne256.WCYCLXX1850.SOI
www = /global/cfs/cdirs/e3sm/www/zhan391/eamxx-pcmdi

partition = "debug"
account = "e3sm"
#account = "priority"
campaign = "water_cycle"
debug = False
environment_commands = "source /global/common/software/e3sm/anaconda_envs/load_latest_e3sm_unified_pm-cpu.sh"

[ts]
active = True
walltime = "00:10:00"
years = "0001:0010:5"
ts_num_years=5


  [[ ocn_2d_monthly_180x360_aave ]]
  input_component = "mpaso"
  input_subdir = "archive/ocn/hist"
  input_files = "mpaso.hist.am.timeSeriesStatsMonthly"
  frequency = "monthly"
  mapping_file = /global/cfs/cdirs/e3sm/diagnostics/maps/map_RRSwISC6to18E3r5_to_cmip6_180x360_traave.20240327.nc
  vars="timeMonthly_avg_ssh,timeMonthly_avg_windStressZonal,timeMonthly_avg_windStressMeridional,timeMonthly_avg_surfaceBuoyancyForcing,timeMonthly_avg_oceanHeatContentSfcToBot,timeMonthly_avg_oceanHeatContentSfcTo700m,timeMonthly_avg_oceanHeatContent700mTo2000m,timeMonthly_avg_oceanHeatContent2000mToBot"
  extra_vars= "timeMonthly_avg_daysSinceStartOfSim,xtime_startMonthly,xtime_endMonthly"
  # MPAS calendar used to construct a CF-style numeric time coordinate
  mpas_calendar = "noleap"
  # MPAS simulation start time used as the reference time for time coordinate
  # This should match the MPAS/E3SM config_start_time 
  mpas_start_time = "0001-01-01 00:00:00"
  
  
  [[ ice_2d_monthly_180x360_aave ]]
  input_component = "mpassi"
  input_subdir = "archive/ice/hist"
  input_files = "mpassi.hist.am.timeSeriesStatsMonthly"
  frequency = "monthly"
  mapping_file = /global/cfs/cdirs/e3sm/diagnostics/maps/map_RRSwISC6to18E3r5_to_cmip6_180x360_traave.20240327.nc
  vars="timeMonthly_avg_icePresent,timeMonthly_avg_iceAreaCell,timeMonthly_avg_surfaceTemperatureCell,timeMonthly_avg_seaSurfaceTemperature,timeMonthly_avg_seaSurfaceSalinity,timeMonthly_avg_airTemperature,timeMonthly_avg_snowMelt,timeMonthly_avg_surfaceIceMelt,timeMonthly_avg_snowAlbedoCell" 
  extra_vars= "timeMonthly_avg_iceAreaCell,timeMonthly_avg_daysSinceStartOfSim,xtime_startMonthly,xtime_endMonthly"
  # MPAS calendar used to construct a CF-style numeric time coordinate
  mpas_calendar = "noleap"
  # MPAS simulation start time used as the reference time for time coordinate
  # This should match the MPAS/E3SM config_start_time 
  mpas_start_time = "0001-01-01 00:00:00"
  

[zhangshixuan1987]

@chengzhuzhang : Hi Jill, the code change above was tested successfully at Perlmutter on my side with the EAMxx model output. The test script directory can be seen at

/pscratch/sd/z/zhan391/e3smv4_project/20260204.ne256.WCYCLXX1850.SOI/post/scripts