Skip to content

Conversation

@eclare108213
Copy link
Collaborator

@eclare108213 eclare108213 commented Jan 14, 2026

  • Short (1 sentence) summary of your PR:
    Merge of CICE Consortium main into E3SM fork, including conflict resolution. This is the first step in resynchronizing E3SM's version of icepack with the Consortium's.
  • Developer(s):
    @eclare108213
  • Suggest PR reviewers from list in the column to the right.
  • Please copy the PR test results link or provide a summary of testing completed below.
    This PR is in draft mode while I do the initial testing.
  • How much do the PR code changes differ from the unmodified code?
    • bit for bit
    • different at roundoff level
    • more substantial
  • Does this PR create or have dependencies on CICE or any other models?
    • Yes
    • No
  • Does this PR add any new test cases?
    • Yes
    • No
  • Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/.)
    • Yes
    • No, does the documentation need to be updated at a later time?
      • Yes
      • No
  • Please document the changes in detail, including why the changes are made. This will become part of the PR commit log.

This draft PR is intended for early perusal by the reviewers.

The Icepack code in this branch is identical to the current CICE Consortium main, although the histories are (probably) different. See eclare/seaice/icepack_20260114...eclare/seaice/e3sm_plus_consortium.

The Icepack submodule hash currently linked in E3SM contains changes (#db64ce3) that were not merged into the E3SM-Project/Icepack fork. Those changes show up in this PR but will not affect E3SM, which already has them.
eclare/seaice/e3sm_plus_consortium...db64ce3

I will use this branch for testing in E3SM.

For more details, see https://e3sm.atlassian.net/wiki/spaces/pd/pages/5813108745/Duplicate+of+Overview+of+Icepack+synchronization+January+2026

apcraig and others added 30 commits November 26, 2024 12:57
…3.2.0 (CICE-Consortium#509)

Update icepack_compute_tracers argument definitions to support cce/17.0.0.
Switched two arguments from explicit size to assumed shape.

Cleaned up some trailing blanks.
Currently, there are two bugs in how icepack computes the height of the ocean above the ice base in icepack_therm_mushy.F90 line 3141:

hocn = (ice_mass + hpond * apond * rhow + hsn * rhos) / rhow

First, rhow is the density of ocean water, but ponds that depress the ice surface are generally found to be fresh water. Thus, rhow in the numerator should be replaced by rhofresh.
Second, apond here is the category pond area tracer, however it is being treated as the category pond area fraction (see footnote below). For the level-ice scheme, the category pond area fraction is apnd*alvl.
This PR fixes both issues. There were also offsetting errors in the flushing_velocity and flush_pond subroutines that have been fixed.

I believe that the second bug was made more likely by using inconsistent naming conventions for the pond area tracer and pond area fraction. In icepack_meltpond_lvl.F90 and other parts of the code base, it appears that the general convention is to use apnd to denote the pond area tracer and apondn for the category or full-grid-cell pond area fraction (i.e., apondn = apnd*alvl for the level pond scheme). I propose that we follow this convention throughout the code base, such that apnd always refers to the pond area tracer. This PR makes these changes in the mushy and vertical thermodynamics modules.

Footnote: there is an alternate interpretation of using just the pond area tracer in the numerator for the level pond scheme which is that the level areas of an ice category separated from the deformed areas by borders of zero flexural rigidity (i.e., the thicker, pond-free, deformed ice cannot provide any upward buoyancy force to the level, ponded areas). If this is the intention, then I think we need to also use the level ice volume (vlvl) in the calculation of ice mass and the level-ice snow depth for consistency.
…rtium#510)

Update derecho gnu to support code coverage testing

    Update to ncarenv/24.12 and gcc/12.4.0
    Add coverage compiler flags
    Add parse_lcov.sh script to support manually parsing lcov info files (not used in production)
    Update lcov scripting as needed

Change derecho gnu non-debug tests to -O2. This should have always been the case, but was not. This results in answers changes relative to main but only for derecho gnu with debug off.

As part of the CICE port to the new coverage tools, a bug was found in the tools that requires debug flags to be disabled when compiling with coverage flags. This was not the case when coverage was running on cheyenne. See linux-test-project/lcov#385
The call to set_sfcflux in icepack_therm_vertical.F90 has the fsurfn_f and fcondtopn_f arguments switched, causing issues for models using calc_Tsfc = .false.. This PR fixes these.
The fix removes an incorrect if block around the silicate limitation functions which was mistakenly added in Icepack v1.5.0.  Silicate limitation should not be wrapped in an if statement for iron tracers.

nonBFB with active BGC.  BFB for all else.
The overall goal of these options added to the Icepack driver are to make it easier to use Icepack as a standalone tool forced with observations. These changes have been implemented specifically for the MOSAiC Expedition. But my hope is that they will be readily extendable to other field data (or reanalysis, etc), so that new datasets can simply be used in Icepack, rather than requiring code changes for every new forcing dataset.

Observational data presents the following complications:

    Missing values. Real observational datasets almost always have missing values (power loss, radiometer dome iced over, etc...). Furthermore, future versions of the observational datasets may fill some of these missing values (e.g., by reprocessing data that previously failed qc).

    Variable frequencies. Different data streams may be measured at different sampling frequencies. Data might be measured more often than the model's timestep (thus requiring aggregation) or less often (thus requiring interpolation).

    Different start and end time points. Different data streams may have different start or end times, and updated versions of datasets may extend the time domain.

    Merged observational datasets are a work-in-progress. The 3 challenges above all touch on the fact that for sea ice field campaigns, it can take years from the end of the campaign until a truly finalized observational dataset is available to force Icepack with (e.g., MOSAiC is 4 years and counting, SHEBA still does not have such a dataset). We still want to be able to use campaign data to support Icepack development during this time, without having to change the Icepack driver every time the forcing dataset is updated.

Additionally, for comparing with field data it is very useful to be able to easily adjust:

    The initial state of the sea ice and ocean mixed layer.

    Fixed values for the oceanic heat flux convergence (qdp) and sea surface salinity (sss).

To address these challenges the PR provides the following features:

    Precalculate the forcing values at each timestep on initialization (in init_forcing). The current paradigm for forcing data in Icepack is that when init_forcing is called, a subroutine for the specific dataset (e.g., atm_CFS) stores the forcing data in the *_data in essentially the same format that the raw data is present in, without timestamp information. It also hardcodes the maximum size that a forcing dataset can be to 8760. Then, at each timestep the get_forcing subroutine has a code block for each forcing dataset that contains the timestamp information and interpolates the forcing data to the given timestep. Under this paradigm, I could not figure out a graceful way to handle missing values, nor forcing data with higher sampling frequency than the Icepack timestep, nor changing start times of the forcing dataset. This PR adds a new option, precalc_forc, for use with the MOSAiC forcing. When precalc_forc = .true., the forcing data is aggregated/interpolated to the Icepack timestep in the call to init_forcing and stored the the *_data arrays. Then, the get_forcing subroutine merely indexes into the *_data arrays.

    Read forcing data from MDF-formatted netCDF files (Uttal et al. 2024; https://doi.org/10.5194/gmd-17-5225-2024, https://gitlab.com/mdf-makers/mdf-toolkit). I chose this format because its framework seemed well-aligned, but it is still in development so we can add variables to it that we need for the ice model (e.g., mixed layer depth).

    To handle variable frequencies and missing data, forcing data are first temporally-averaged for each timestep and then interpolated. For a give data variable (var_data), The MOSAiC_average subroutine takes the average of all forcing datapoints within each timestep +- 0.5 dt excluding missing values and stores the results in var_data. If there is no valid data within 0.5 dt of a given timestep (e.g., most timesteps if the model timestep is much smaller than the sampling period) then a missing value is placed in var_data(timestep). Then, the MOSAiC_interpolate subroutine linearly interpolates missing values in var_data.

    The option to explicitly set in the namelist the initial ice and snow thicknesses for the slab and ITD grid cells and the SST for the 3 ice grid cells.

    The option to explicitly set in the namelist fixed ocean mixed layer conditions qdp_fixed, sss_fixed, and hmix_fixed. These are overwritten by forcing data.
Remove zsalinity code (was previously deprecated via an abort)

    Remove variables salt_loss, dts_b, solve_zsal, restart_zsal, grid_oS, l_skS, nt_bgc_S

    Remove subroutine icepack_init_zsalinity

    Update interfaces to remove zsalinity arguments
    - in icepack_parameters.F90
    - in icepack_tracers.F90
    - subroutine icepack_step_ridge (fzsal)
    - subroutine icepack_step_therm2 (fzsal)
    - subroutine init_zbgc

    Leave zsalinity namelist input in place for backwards compatibility but they have no impact. If solve_zsal is set to true, the code aborts.

    Update interface documentation

    Update user guide
…nodo template (CICE-Consortium#522)

DistributionPolicy.pdf was updated to include institutions that have joined the CICE Consortium since its inception.

The zenodo template was updated with authors included in the most recent release and links back to github for more detailed information.
…rtium#523)

Update set_version_number.csh to update .zenodo.json file from the command line via

./icepack.setup --setvers x.y.z
…m#524)

Update Copyright and License consistent with latest changes in CICE,
includes updates in source code where needed.

In preparation for release, update version number, remove trailing
space.
This sets the calendar attribute correctly in history output. This update's any notes or other calendar references to support "proleptic_gregorian" as well as "gregorian" for calendar type.  Use of the calendar_type variable was also removed where it wasn't needed in the driver.  The correct cf-name for the calendar used is "proleptic_gregorian" but backward compatibility is maintained with the calendar name "gregorian". This is a companion PR to Setting calendar attribute in output to proleptic_gregorian CICE#1024.
…tions (CICE-Consortium#518)

Add GEOS coupling updates. This allows coupling to the GEOS coupled system where a semi-implicit thermodynamic coupling scheme is introduced. Similar to the explicit case, the fields fsurfn are provided by the coupler, along with their derivatives with respect to surface temperature dfsurfn_dTs. In this case, calc_Tsfc is still set to true, allowing ice surface and internal temperature to be updated implicitly. The resultant surface temperature change is passed back to the atmosphere model via coupler to complete the full update of its temperature profiles. This middle-ground approach, enabled by semi_implicit_Tsfc=true, does not sacrifice accuracy because it does not need limiting effective conductivity as in the explicit case. In addition, in GEOS, the atmosphere model assumes vapor deposits or sublimates at 0 degC. In this case, mass conservation is enforced and the resulting discrepancy in energy is resolved by another term, de_vapor, and passed to ocean. This option is only on when vapor_flux_correction is true.

Add 4 new shortwave terms, uvrdr, uvrdf, pardr, pardf to the coupling. These terms represent a breakdown of the direct and diffuse visible shortwave terms into two components, par = photosynthetical active radiation (400-700nm) and uvr = rest of the visible shortwave term (>700nm). The current visible shortwave is exactly represented by these two components. Includes adding atm forcing and terms associated with radiation passthru to the ocean.

Add support for GEOS semi-implicit coupling of surface temperature. In GEOS, surface and latent heat flux is computed in the atmosphere at 0degC. The sea ice model has to respect that calculation, but then computes the d(dh)/dTs terms to correct the heatflux for the sea ice temperature which is then applied conservatively in the coupled system. Implementation includes turning off some of the heat flux calculations in Icepack. This is controlled by the semi_implicit_Tsfc namelist.  Add check to not allow semi_implicit_Tsfc with tr_pond_topo.

Add calculation of a vapor flux correction. A correction is needed for GEOS coupling to compute a mass and enthalpy correction for evaporation and sublimation. This is controlled by the vapor_flux_correction namelist.

Rename sblx to de_vapor

Update treatment of rain coupling for GEOS, include rain in fresh water coupling flux. This will require modifications to the coupling system in GEOS, in particular, the partitioning of rain between sea ice and ocean.



Update discover port

Update documentation

---------

Co-authored-by: bzhao <Bin.Zhao@nasa.gov>
Remove extra use variable and update documentation.  These are a couple of minor changes that will complete the initial GEOS coupling integration.
)

* Moves snow grain radius parameters to namelist

Adds a minimum snow grain growth rate scale parameter, default 0
Moves the irreducible saturation fraction to the namelist.
BFB

* Moves S_wet to namelist snw_growth_wet

Snow grain radius metamorphism rate is scaled by snw_growth_wet
BFB

* update snow documentation

These changes are for sensitivity testing and model tuning. S_r (changed to snwliq_max) determines the maximum liquid water in snow which when cubed controls the rate at which snow grain size changes during wet metamorphism. drsnw_min is the minimum snow grain growth rate at 0 liquid water content. It's a new parameter but set to zero to be BFB though Brun 1989 experiments observe a non-zero value. Both parameters are physically based but with uncertainty in the literature, and they play a significant role in the snow grain evolution.
Add new sea level pond scheme.  Set with tr_pond_sealvl = .true. in namelist.

Added new module icepack_meltponds_sealvl.F90

Added new pond diagnostics (for all meltpond schemes): flpnd, expnd, frpnd, rfpnd, ilpnd (plus category versions), as well as mipnd, and rdpnd.

Added new code to icepack_therm_mushy.F90 to handle the case of sealevel pond drainage.

Updated shortwave code.

Added new pond history fields.

Added new namelist, tr_pond_sealvl, apnd_sl, tscale_pnd_drain

Added new pondsealvl test

Updated documentation

Co-authored-by: David Clemens-Sewall <dcsewall@ucar.edu>
Co-authored-by: David Clemens-Sewall <david.clemens-sewall@noaa.gov>
Co-authored-by: David Clemens-Sewall <davidclemenssewall@gmail.com>
Co-authored-by: eclare108213 <eclarehunke@gmail.com>
Co-authored-by: apcraig <anthony.p.craig@gmail.com>
Update the Ponds diagnostics. Fix a bug that was reporting pond history field values of zero for fields by category.

Rename the ponds history field names.
expnd -> dpnd_expon
flpnd -> dpnd_flush
frpnd -> dpnd_freebd
ilpnd -> dpnd_dlid
mipnd -> dpnd_melt
rdpnd -> dpnd_ridge
rfpnd -> dpnd_initial

Clean up trailing blanks. Clean up some alignment.

Update the interface documentation

Turn off the dpnd history fields for topo ponds and add a warning message in the output. Add a note in the documentation that ponds diagnostics are not fully implemented yet for topo ponds.

---------

Co-authored-by: eclare108213 <eclarehunke@gmail.com>
…ind (CICE-Consortium#532)

The nag error was introduced when the MOSAiC forcing was added to Icepack. It's in the Icepack driver so did not impact CICE testing. Some new variables were declared (kind=8) which isn't part of the Fortran standard even though most compilers allow it, but the nag compiler generated an error. The (kind=8) declarations were changed to (kind=dbl_kind). This should have been addressed sooner, but it should not impact solutions or results for compilers that allow it.
This error was introduced during some recent zenodo changes. It was caught when the model was released and zenodo failed to import the latest release due to metadata errors. We will try to also implement some tools to pre-release test the zenodo template.
A few updates to improve automation of the zenodo metadata.
Changed license from generic open to BSD-3-Clause. We have the BSD 3-Clause "New" or "Revised" License.
Added the Triad copyright statement.
List keywords separately to improve searchability.
Changed publication date for consistency with the v1.5.1 release, to avoid potential confusion.
Floating point math (e.g., in ridge_shift) may lead to tiny vicen increments without area that are not currently zapped. This zaps them too (+ similar logic for tiny vsnon). Closes CICE-Consortium#535
Update Version number in preparation for minor release
Missed a Copyright update in the last PR
Update Copyright in zenodo json file
Removing a few unused variables (aice_init, vice_init). 

Installed conda on a new laptop and discovered that the hardware platform is no longer x86_64, which slightly changes the miniconda porting instructions.
set qstatus = `${ICE_MACHINE_QSTAT} $job | grep $job | wc -l`

Some recent changes made the return status of "${ICE_MACHINE_QSTAT} $job"
no longer robust as a way to check if a job was in the queue or not.
Bug fix for the snow-ice interface temperature history variable (diagnostic only, does not affect the physics calculation). This code uses a straight line to interpolate between the bottom snow layer and top ice layer temperatures when snow is present, otherwise it is the surface temperature.
This PR addresses the long-standing residual ice problem in CICE by zapping grid-cell volumes with area or mass less than the new namelist parameters min_area and min_mass. To work properly, these parameters should likely be set to the same values as the dynamics area and mass minimum values dyn_area_min and dyn_area_mass. Since those parameters in CICE are quite large (and everyone should decrease them), the default values in Icepack are currently set to 1.e-11 and 1.e-10, respectively, maintaining the area/mass=0.1 relationship of the dynamics parameters. The driver (e.g. CICE) should initialize them as needed via an icepack_init_parameters call.
Add option for externally generated significant wave height

A new namelist flag allows significant wave height to be passed into the ice model from a coupler. In addition, this PR

    moves wave_spec_height out of icepack interface argument lists, since it is initialized via icepack_init_parameters
    consolidates multiple wave-spectrum calculations of significant wave height, to reduce duplication of code, used when wave_height_type = 'internal'.

This PR is the first step in resyncing the CICE Consortium and E3SM versions of Icepack. 

The Icepack interface is not fully backwards compatible, the optional dwavefreq argument has been removed from subroutine icepack_step_therm2.

---------

Co-authored-by: njeffery <njeffery@lanl.gov>
Co-authored-by: Erin Thomas <ethomas@lanl.gov>
Co-authored-by: Darin Comeau <darincomeau@gmail.com>
Comment on lines +120 to +123
fswthrun_uvrdr, & ! > 700nm vis uvr dir sw radiation through ice bot (W/m**2)
fswthrun_uvrdf, & ! > 700nm vis uvr dif sw radiation through ice bot (W/m**2)
fswthrun_pardr, & ! 400-700nm vis par dir sw radiation through ice bot (W/m**2)
fswthrun_pardf, & ! 400-700nm vis par dif sw radiation through ice bot (W/m**2)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The abbreviated commenting of fswthrun_uvrdr, fswthrun_uvrdf, fswthrun_pardr, and fswthrun_pardf needs to be expanded here. ">700nm vis uvr" appears to be an oxymoron, and I could not find a clear language explanation of "400-700nm vis par".

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expanded definitions are in the documentation file icepack_index.rst (which for some reason is not being rendered in readthedocs -- will need to investigate):
https://github.com/E3SM-Project/Icepack/pull/42/changes#diff-e85f96fcb99c37298c8ac35b5e6e0f6d440c27fcce88e26306c627951b26c866R194-R200

These changes came in with CICE-Consortium#518, where the PR header info says

Add 4 new shortwave terms, uvrdr, uvrdf, pardr, pardf to the coupling. These terms represent a breakdown of the direct and diffuse visible shortwave terms into two components, par = photosynthetical active radiation (400-700nm) and uvr = rest of the visible shortwave term (>700nm). The current visible shortwave is exactly represented by these two components. Includes adding atm forcing and terms associated with radiation passthru to the ocean.

So it sounds like uvr is the part of the visible spectrum that is not par... but the word 'ultraviolet' does not make sense with 'visible', I agree. Pinging @zhaobin74 for further clarification.

@eclare108213
Copy link
Collaborator Author

I'm fixing a problem with the documentation in CICE-Consortium#547, which will also be pulled into this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants