Conversation
Error code evaluation all happens on C++ side. Make run/finalize bridge functions return void, since fortran has no use for their error codes.
Apply reviewer's suggestion Co-authored-by: Luke Van Roekel <lvanroekel@lanl.gov>
No Omega document resolves a reference through an external inventory: every {ref} target is a label defined within these docs, and there are no python-domain roles at all. A build with `intersphinx_mapping = {}` succeeds with no warnings.
The inventories were nevertheless fetched on every build, and the docs job runs `sphinx-build -nW`, so an outage at any of those hosts fails CI for reasons unrelated to the change under test. That happened on 2026-09-04: docs.scipy.org stopped responding partway through the day and the docs job began failing with "failed to reach any of the inventories".
Drop all seven mappings along with the sphinx.ext.intersphinx extension. Add a mapping back, one host at a time, if the docs ever cross-reference another project; polaris is the likeliest candidate, at its current address https://docs.e3sm.org/polaris/main.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ve-unneeded-intersphinx Remove unused intersphinx inventories
Add a missing assignment of the error code returned by OMEGA::ocnFinalize. We also clean up the C++/Fortran interface, by making the C++ function return void (now consistent with their Fortran declaration). Error codes are all handled on the C++ side; any logic dependent on the error code value is handled in C++. So, we have no need to pass the return codes to Fortran. Missing assignment came to light when testing E3SM-Project#526.
* Pass `IOBaseTask` and `IORearranger` from CIME through the Fortran/C++ interface * Add `IO::init(IOInitParams)` while preserving configuration-based initialization for standalone runs * Block `IO.IOBaseTask` and `IO.IORearranger` overrides in `omega_buildnml` * Log the PIO settings used to initialize SCORPIO * Add `IO_INIT_PARAMS_TEST` to verify driver-provided settings reach SCORPIO
…dulesImpl function
…moc-streamfunction Add MOC stream function analysis capability ### Overview This PR introduces a complete MOC (Meridional Overturning Circulation) analysis capability to Omega, enabling computation of the MOC streamfunction using two complementary methods: 1. **Latitude-binned regional MOC**: Computes MOC as a function of latitude and depth for specified ocean regions 2. **Transect-based MOC**: Computes MOC across specific transects as a function of depth The implementation adds 8 new analysis operators, enhanced analysis infrastructure with regional mask support, a new MOC analysis group, and comprehensive configuration templates. ### Key Features **New Analysis Operators (8 total)**: - `BinaryMultiplyOp`: Element-wise field multiplication with vertical expansion support - `BinnedAccumulatorOp`: Accumulates field values into spatial bins (core MOC operator) - `CoordinateBinningOp`: Assigns mesh entities to bins based on coordinate values - `ExtractRegionOp`: Applies regional masks to fields - `PrefixSumOp`: Cumulative summation (integration) along specified dimension - `PseudoToGeometricOp`: Converts pseudo-height quantities to geometric coordinates - `ScalarMultiplyOp`: Multiplies field by scalar constant for unit conversion - `TransectAccumulatorOp`: Accumulates transport across transect edges **Infrastructure Enhancements**: - **Field Class Regional Mask Support**: Fields can carry spatial mask information through operator chains with automatic propagation - **IOStream IOName Metadata**: Provides user-friendly variable names in netCDF output while maintaining internal operator chain naming - **Enhanced AnalysisGroup Base Class**: New `setOutputIOName` method and operator-specific configuration support **MOC Analysis Group**: - Bundled analysis group for computing MOC streamfunction - Configurable latitude binning (number of bins, lat range) - Regional MOC computation for named ocean regions - Transect-based MOC computation across specified transects - Configurable temporal output (reduction periods and snapshots) - IOStream integration for netCDF output ### MOC Computation Pipeline **Latitude-binned Regional MOC chain**: 1. Assign cells to latitude bins (static, initialization) 2. Convert vertical pseudo-velocity to geometric coordinates 3. Compute vertical flux (velocity × area) 4. Apply regional mask (optional) 5. Accumulate into latitude bins 6. Horizontal integration (south→north) 7. Convert to Sverdrups **Transect-based MOC chain**: 1. Convert pseudo-thickness to geometric layer thickness 2. Compute transport (thickness × velocity × edge width) 3. Accumulate across transect edges 4. Vertical integration (bottom→top) 5. Convert to Sverdrups ### Technical Implementation **Design Features**: - Field-level regional mask storage and automatic propagation - IOName metadata system separating internal from user-facing names - Kokkos hierarchical parallelism for 2D/3D operators - SFINAE compile-time optimization to prevent invalid template instantiations - Operator parameters passed via Config objects through chain parsing **Output Format**: - MOC streamfunction in Sverdrups (1 Sv = 10⁶ m³/s) - Dimensions: latitude bins × depth levels (regional), or depth only (transect) - NetCDF files with user-friendly variable names (e.g., "MOC_streamfunction_Global") - Configurable temporal averaging and snapshot output ### Limitations - Regional masks not yet implemented (operator infrastructure ready, placeholder in config) - Transect masks not yet implemented (operator infrastructure ready, placeholder in config)
…e-gptl-link In a coupled E3SM build, Omega built its own copy of Scorpio and of Scorpio's bundled GPTL, and e3sm.exe linked both copies of each (E3SM-Project#563). With this PR, Omega uses the case's shared Scorpio and GPTL in a coupled build, as EAMxx already does. All changes are in components/omega/external/CMakeLists.txt. - Wrap spio as pioc and gptl when the build provides spio - Carry HAVE_MPI on the gptl wrapper. It is added unless MPILIB is mpi-serial. - In the threaded standalone GPTL patch, request OpenMP's Fortran component only where Fortran is enabled. Fixes E3SM-Project#563, E3SM-Project#572
…i_cpl_indices.F,seq_flds_mod.F90
add index_x2i_Fioo_frazilh (frazil heat flux from ocean) add index_x2i_Fioi_frazil (frazil mass flux from sea ice) add index_x2i_Fioi_frazils (frazil salt flux from sea ice) add index_x2i_Fioi_frazilh (frazil heat flux from sea ice) All added to mpassi_cpl_indices.F and seq_flds_mod.F90. Fioi_frazil and Fioi_frazils added to ice_comp_mct.F
Updates Icepack submodule to frazil coupling branch Adds ocean-ice coupling fields: frazil salt flux (Fioo_frazils) frazil enthalpy flux (Fioo_frazilh) defined consistent with freezingMeltPotential To use, set config_frazil_coupling_type to ‘omega-fluxes’ Backwards compatible with mpas-ocean for config_frazil_coupling_type = ‘external’ Stealth
Sea ice initialize now allows for the config_frazil_coupling_type option: "omega-fluxes"
Sea ice initialize NOW allows for config_frazil_coupling_type option: “omega-fluxes”
Removes double counting of frazil energy in coupler budget. Corrects possible but in temperature tendency of frazil melt. nBFB
Adds optional formulation in frazil.
Revert to original formulation with comments.
1. Initialized frazilMassFlux to 0 for SOM 2. Corrected indexing of component-level salt budget sum 3. Type in comment 4. Corrected definition of Fioo_frazils in MOAB to be consistent with mct
Also removes redundant write in coupler diagnostics Clean up confusing comments in ocean conservation member
Co-authored-by: Carolyn Begeman <cbegeman@lanl.gov>
Makes the following changes to be consistent with salt/energy flux name convention: 1. Fioi_frazil to Fioi_frazilm 2. Fioo_frazil to Fioo_frazilm
njeffery
force-pushed
the
njeffery/frazil-coupling
branch
from
September 29, 2026 17:18
a735fde to
69b15d1
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated version of #535
Fixes double counting of ocean heat flux during frazil ice formation.
For the ocean to ice coupler fields, Fioo_q now only contains the melt potential while Fioo_frazilh contains the heat from frazil ice formation. frazilh and q are combined in ice_comp_mct to reproduce the sea ice freezingMeltingPotential
Fioo_q is removed from driver-mct as it is no longer a heat flux.
A new flag, config_use_accumulated_frazil_energy default false, is added to the ocean model. Default retains the latent heat definition of frazil energy.
config_use_accumulated_frazil_energy = true uses the accumulatedFrazilHeat variable from frazil formation.
Tested in XS_2x5 GMPAS runs in 2 configurations:
Both completed successfully.
Test 1 was compared with darin's codebase from the previous PR (darincomeau@ea24e0f). Restart files at the end of day 11 showed differences in only 4 fields: o2x_ox_Fioo_frazilh, budg_dataG, o2x_ox_Fioo_q, and freezingMeltingPotential.
Differences in o2x_ox_Fioo_frazilh and freezingMeltingPotential were round off level only.
Differences in o2x_ox_Fioo_q, were all negative, as expected.
Differences in budg_dataG, also expected, were significant in regions of frazil ice formation.
Part of the frazil implementation documentation (sections 1.3-1.5). Currently here: https://www.overleaf.com/project/68896a760125362ca62587d1