How will this affect the next version number?
New feature (increment MINOR version)
Is your feature request related to a problem?
Yes. Currently, the zppy [ts] (time series post-processing with nco package) workflow supports time-series processing and regridding for atmosphere, land, and river components, but it does not recognize MPAS-Ocean (mpaso) or MPAS-Sea-Ice (mpassi) components in the same way.
This creates a limitation for coupled-model post-processing workflows where selected ocean or sea-ice variables are needed outside of MPAS-Analysis. For example, some downstream diagnostics, such as the PCMDI ENSO diagnostics, require ocean surface variables such as sea surface height (ssh) for complete process-level diagnostics. Atmosphere-focused users may also need ocean surface variables such as sea surface temperature, sea surface salinity, or mixed-layer depth on a common latitude–longitude grid for diagnostic comparison and analysis.
At present, users cannot easily use the existing zppy [ts] framework to process and regrid selected MPAS-Ocean or MPAS-Sea-Ice variables in the same flexible way as atmosphere, land, and river variables. This means users may need separate or manual post-processing steps even when the existing [ts] workflow could potentially handle the general time-series and regridding logic.
I searched the existing zppy GitHub issues and did not find a clear existing feature request for adding [ts] support for MPAS-Ocean and MPAS-Sea-Ice components.
Describe the solution you'd like
I would like zppy to support selected MPAS-Ocean (mpaso) and MPAS-Sea-Ice (mpassi) variables through the existing [ts] time-series processing workflow.
A minimal solution would be for zppy to recognize mpaso and mpassi as valid input_component values and assign the corresponding output component and prc_typ. For example, in zppy/utils.py, set_component_and_prc_typ() could include logic similar to:
elif tmp in ("mpaso",):
component = "ocn"
prc_typ = tmp
elif tmp in ("mpassi",):
component = "ice"
prc_typ = tmp
With this change, users could define [ts] subsections for selected MPAS-Ocean or MPAS-Sea-Ice variables, provide the appropriate regridding maps, and let zppy process those variables using the existing time-series and regridding framework.
The goal is not to create a new diagnostic workflow or duplicate MPAS-Analysis. Instead, the goal is to make the existing [ts] workflow more flexible so that users can process selected ocean and sea-ice variables needed for downstream diagnostics, such as PCMDI ENSO metrics or coupled atmosphere–ocean analysis.
Describe alternatives you've considered
One alternative is to rely entirely on MPAS-Analysis for ocean and sea-ice diagnostics. However, MPAS-Analysis is mainly a diagnostic workflow, while the proposed request is for more general-purpose time-series processing and regridding of selected variables that may be needed by other downstream tools.
Another alternative is for users to manually process MPAS-Ocean and MPAS-Sea-Ice variables outside zppy using custom scripts. This is possible, but it can lead to duplicated effort and less consistent post-processing across users and projects.
A third alternative is to create a separate dedicated zppy workflow for MPAS-Ocean and MPAS-Sea-Ice time-series processing. However, this may be more complicated than necessary. Since the existing [ts] framework already handles general time-series processing and regridding for other components, a minimal extension to recognize mpaso and mpassi seems like a simpler and more flexible first step.
Additional context
Below I shared a cfg file that I tested with the minimal changes I suggested above:
# 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
[[ atm_2d_monthly_180x360_aave ]]
input_component = "eamxx"
input_subdir = "archive/atm/hist"
case = "output.scream.ne256_coupled_test"
input_files = "monthlyAVG_ne30pg2.AVERAGE.nmonths_x1"
frequency = "monthly"
mapping_file = /global/cfs/cdirs/e3sm/diagnostics/maps/map_ne30pg2_to_cmip6_180x360_aave.20200201.nc
# list for pcmdi diag, note: PHIS,hyam,hybm,hyai,hybi need to be included to process the 3D fields
vars="ps,surf_radiative_T,SeaLevelPressure,IceWaterPath,qv_2m,precip_liq_surf_mass_flux,precip_ice_surf_mass_flux,omega_at_500hPa,omega_at_700hPa,omega_at_850hPa,T_mid_at_700hPa,T_2m,surface_upward_latent_heat_flux,surf_sens_flux,z_mid_at_700hPa,wind_speed_10m,surf_evap,U_at_10m_above_surface,V_at_10m_above_surface,LW_clrsky_flux_dn_at_model_bot,LW_clrsky_flux_up_at_model_top,LW_flux_dn_at_model_bot,LW_flux_up_at_model_bot,LW_flux_up_at_model_top,SW_clrsky_flux_dn_at_model_bot,SW_clrsky_flux_dn_at_model_top,SW_clrsky_flux_up_at_model_bot,SW_clrsky_flux_up_at_model_top,SW_flux_dn_at_model_bot,SW_flux_dn_at_model_top,SW_flux_up_at_model_bot,SW_flux_up_at_model_top,ShortwaveCloudForcing,LongwaveCloudForcing"
extra_vars= "area,landfrac,ocnfrac"
[[ atm_3d_monthly_180x360_aave ]]
input_component = "eamxx"
input_subdir = "archive/atm/hist"
case = "output.scream.ne256_coupled_test"
input_files = "monthlyAVG_ne30pg2.AVERAGE.nmonths_x1"
frequency = "monthly"
mapping_file = /global/cfs/cdirs/e3sm/diagnostics/maps/map_ne30pg2_to_cmip6_180x360_aave.20200201.nc
# list for pcmdi diag, note: PHIS,hyam,hybm,hyai,hybi need to be included to process the 3D fields
vars="U,V,T_mid,z_mid,omega,RelativeHumidity,p_mid,qv"
extra_vars= "ps,hyai,hyam,hybi,hybm,area,landfrac,ocnfrac"
[[ 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
# list for pcmdi diag, note: PHIS,hyam,hybm,hyai,hybi need to be included to process the 3D fields
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"
Note that I added the [[ocn_2d_monthly_180x360_aave]] section, along with some mpaso variables. The test was successful on Perlmutter. However, further tests are needed for robustness.
How will this affect the next version number?
New feature (increment MINOR version)
Is your feature request related to a problem?
Yes. Currently, the zppy [ts] (time series post-processing with nco package) workflow supports time-series processing and regridding for atmosphere, land, and river components, but it does not recognize MPAS-Ocean (mpaso) or MPAS-Sea-Ice (mpassi) components in the same way.
This creates a limitation for coupled-model post-processing workflows where selected ocean or sea-ice variables are needed outside of MPAS-Analysis. For example, some downstream diagnostics, such as the PCMDI ENSO diagnostics, require ocean surface variables such as sea surface height (ssh) for complete process-level diagnostics. Atmosphere-focused users may also need ocean surface variables such as sea surface temperature, sea surface salinity, or mixed-layer depth on a common latitude–longitude grid for diagnostic comparison and analysis.
At present, users cannot easily use the existing zppy [ts] framework to process and regrid selected MPAS-Ocean or MPAS-Sea-Ice variables in the same flexible way as atmosphere, land, and river variables. This means users may need separate or manual post-processing steps even when the existing [ts] workflow could potentially handle the general time-series and regridding logic.
I searched the existing zppy GitHub issues and did not find a clear existing feature request for adding [ts] support for MPAS-Ocean and MPAS-Sea-Ice components.
Describe the solution you'd like
I would like zppy to support selected MPAS-Ocean (mpaso) and MPAS-Sea-Ice (mpassi) variables through the existing [ts] time-series processing workflow.
A minimal solution would be for zppy to recognize mpaso and mpassi as valid input_component values and assign the corresponding output component and prc_typ. For example, in zppy/utils.py, set_component_and_prc_typ() could include logic similar to:
elif tmp in ("mpaso",):
component = "ocn"
prc_typ = tmp
elif tmp in ("mpassi",):
component = "ice"
prc_typ = tmp
With this change, users could define [ts] subsections for selected MPAS-Ocean or MPAS-Sea-Ice variables, provide the appropriate regridding maps, and let zppy process those variables using the existing time-series and regridding framework.
The goal is not to create a new diagnostic workflow or duplicate MPAS-Analysis. Instead, the goal is to make the existing [ts] workflow more flexible so that users can process selected ocean and sea-ice variables needed for downstream diagnostics, such as PCMDI ENSO metrics or coupled atmosphere–ocean analysis.
Describe alternatives you've considered
One alternative is to rely entirely on MPAS-Analysis for ocean and sea-ice diagnostics. However, MPAS-Analysis is mainly a diagnostic workflow, while the proposed request is for more general-purpose time-series processing and regridding of selected variables that may be needed by other downstream tools.
Another alternative is for users to manually process MPAS-Ocean and MPAS-Sea-Ice variables outside zppy using custom scripts. This is possible, but it can lead to duplicated effort and less consistent post-processing across users and projects.
A third alternative is to create a separate dedicated zppy workflow for MPAS-Ocean and MPAS-Sea-Ice time-series processing. However, this may be more complicated than necessary. Since the existing [ts] framework already handles general time-series processing and regridding for other components, a minimal extension to recognize mpaso and mpassi seems like a simpler and more flexible first step.
Additional context
Below I shared a cfg file that I tested with the minimal changes I suggested above:
Note that I added the [[ocn_2d_monthly_180x360_aave]] section, along with some mpaso variables. The test was successful on Perlmutter. However, further tests are needed for robustness.