external wave height option #545

eclare108213 · 2025-12-05T16:28:54Z

PR checklist

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. It is in draft form until we ensure it runs as expected in E3SM. A few extra commits show up in the list because of differences in histories between the Consortium and E3SM Icepack repositories, going back to the last time they were in sync. Only the wave-height related changes are new, as shown in the file comparison.

Merge CICE-Consortium/Icepack main (v1.5.0) to E3SM-Project/Icepack main

Fixes a bug introduced in V1.5.0. Silicate limitation should not be wrapped in an if statement for iron tracers. nonBFB with active BGC. BFB for all else.

…negative-silicate Corrects negative silicate values in sea ice

…eight add optional wave height input to subroutines in icepack that calculate wave heights

eclare108213 · 2025-12-05T16:31:51Z

I'm thinking of changing the wave_height_type = 'internal' option to 'spectral', and wave_height to wave_sig_ht, wherever it appears in the code.
CICE draft PR will be posted soon to illustrate the changes needed in the driver.
FYI @lettie-roach

lettie-roach · 2025-12-05T17:30:32Z

Thanks for consolidating! I think that looks good.

Just a comment on the naming. Now wave_spec_type is only used to determine how wave fracture is computed (convergence over random sea surface height phase, vs one iteration and constant phase). Maybe we should rename 'wave_spec_type' to 'wave_frac_method' or something similar? Then we can later add in new wave fracture methods using this as well.

Then we might keep 'wave_spec_type' for the other option (instead of wave_height_type) - as the input data is the wave energy spectrum as a function of frequency, E(f)

eclare108213 · 2025-12-05T17:51:30Z

Just a comment on the naming. Now wave_spec_type is only used to determine how wave fracture is computed (convergence over random sea surface height phase, vs one iteration and constant phase). Maybe we should rename 'wave_spec_type' to 'wave_frac_method' or something similar? Then we can later add in new wave fracture methods using this as well.

We can certainly generalize this, but I'd prefer to do that in a separate PR from this one.

Then we might keep 'wave_spec_type' for the other option (instead of wave_height_type) - as the input data is the wave energy spectrum as a function of frequency, E(f)

This would be really confusing, I think. We don't have any new wave data for CICE at the moment, but the input data for wave_height_type = 'coupled' in E3SM is actually significant wave height calculated by WW3. This PR is intended to support that coupling approach while still allowing the existing options.

dabail10

I guess this looks fine. I am still confused about why dwavefreq goes away.

dabail10 · 2025-12-05T22:29:15Z

columnphysics/icepack_fsd.F90

                                  wave_sig_ht,               &
                                  wave_spectrum,             &
                                  wavefreq,                  &
-                                  dwavefreq,                 &


I guess I am not sure why you are removing dwavefreq from the call, but not wavefreq?

dabail10 · 2025-12-05T22:29:55Z

columnphysics/icepack_fsd.F90

               if (wave_spec) then
                  if (wave_sig_ht > puny) then
-                     call wave_dep_growth (wave_spectrum, &
-                                           wavefreq, dwavefreq, &


Ok. I see here that you removed dwavefreq.

dabail10 · 2025-12-05T22:32:00Z

columnphysics/icepack_fsd.F90


      integer (kind=int_kind) :: k

-      w_amp = c2* SQRT(SUM(local_wave_spec*dwavefreq))   ! sig wave amplitude


Starting to understand now. Is this bfb?

It is BFB in my tests so far.

lettie-roach · 2025-12-06T09:11:36Z

Then we might keep 'wave_spec_type' for the other option (instead of wave_height_type) - as the input data is the wave energy spectrum as a function of frequency, E(f)

This would be really confusing, I think. We don't have any new wave data for CICE at the moment, but the input data for wave_height_type = 'coupled' in E3SM is actually significant wave height calculated by WW3. This PR is intended to support that coupling approach while still allowing the existing options.

Ah, I hadn't realized that E3SM is using wave significant height rather than the spectrum. Then 'wave_height_type' makes sense.

I do think 'wave_frac_method' or 'wave_frac_type' would be less confusing than 'wave_spec_type' for the option to do convergence over random sea surface height phase vs one iteration and constant phase in the wave fracture scheme.

anton-seaice · 2025-12-07T21:07:24Z

FYI @NoahDay @ezhilsabareesh8 - I don't think this impacts us? (There will be a companion change to cice - see CICE-Consortium/CICE#1071)

lettie-roach · 2025-12-08T07:18:07Z

doc/source/user_guide/ug_case_settings.rst

   "", "``random``", "wave data file is provided, sea surface height generated using random number (multiple iterations of wave fracture)", ""
+   "``wave_height_type``", "``internal``", "significant wave heights are calculated by icepack from the wave_spectra", "``none``"
+   "", "``none``", "No wave data provided, no wave-ice interactions", ""
+   "", "``coupled``", "significant wave heights data provided from a coupled wave model, like WW3", ""


What about the wave spectra? Are these passed from E3SM in addition to significant wave height? Or is there some reconstruction of the wave spectra (e.g. Bretschneider) occurring somewhere?

I think they are passing the data to ensure the fields are all consistent. Treating wave height as external forcing makes sense to me since the wave model is a separate component (in E3SM), but sea ice could still modify wave height during the timestep if the coupling needs to be tighter.

yes- we pass the direction integrated wave spectra for the breaking (controlled by wave_spec_type), as well as wave height (controlled by wave_height_type) .

Perhaps for a later PR then, we could make the logic like this?

wave_spec_type
= ‘none’ - No wave data provided, no wave-ice interactions
= ‘profile’ - constant spectra, for testing only
= ‘coupled’ - from file or coupling with wave model

wave_height_type
= ‘none’ ?
= ‘internal’ - calculated from wave spectra within sea ice model
= ‘coupled’ - from file or coupling with wave model

wave_frac_type
= ‘none’ ?
= ‘HT15-single’ - as Horvat & Tziperman (2015) - one iteration with fixed sea surface height phase
= ‘HT15-convergence’ - as Horvat & Tziperman (2015) - run to convergence with random sea surface height phases

Sounds good. I made a new issue to keep this on the radar. Thanks!

I like this idea for for the future!

apcraig · 2025-12-08T22:33:13Z

Please run

./icepack.setup --docintfc

before final PR. This will update the Icepack interface document as needed. Do a git diff on the doc files to make sure it looks reasonable. Thanks!

erinethomas · 2025-12-18T19:17:19Z

The wave-ice parts of this PR has now been fully tested in E3SM. I fully approve of all @eclare108213s consolidations!

eclare108213 and others added 21 commits November 21, 2024 10:42

Merge pull request CICE-Consortium#35 from CICE-Consortium/main

22b8769

Merge CICE-Consortium/Icepack main (v1.5.0) to E3SM-Project/Icepack main

Corrects negative silicate values

a7f7916

Fixes a bug introduced in V1.5.0. Silicate limitation should not be wrapped in an if statement for iron tracers. nonBFB with active BGC. BFB for all else.

Merge pull request CICE-Consortium#39 from E3SM-Project/njeffery/fix-…

aff40ce

…negative-silicate Corrects negative silicate values in sea ice

add optional wave height input to wavefracspec

992f7ce

add wave height optional argument to wave_dep_growth

b32a55f

bug fix

e75110b

adding units to sig. wave height variable comments

a79a5f3

adding wave_height_type namelist option to control wave_height_coupling.

4744095

clean up coupled wave_height code options

58a7e56

fix abort when noe wave hiehgt data provided in fsd

32e7295

bug fix

e3079de

tidy up

bca5def

bug fix to abort

c89d3a2

clean up

9c78389

new comment for clarity

de39323

modify fsd tests for new wave_height_type

38f0192

fix namelist checking for wave_height_type

53fcc4a

add endif

2b94b15

Merge pull request CICE-Consortium#40 from erinethomas/optional_WaveH…

7e35af5

…eight add optional wave height input to subroutines in icepack that calculate wave heights

resolve parameter conflicts

c58d740

consolidate wave height calcs for reuse, simplify logic

43a2779

eclare108213 requested review from apcraig and dabail10 December 5, 2025 16:28

eclare108213 assigned apcraig Dec 5, 2025

eclare108213 added Type: Feature Forcing Priority: High labels Dec 5, 2025

eclare108213 mentioned this pull request Dec 5, 2025

Add wave_height_type options CICE-Consortium/CICE#1071

Draft

18 tasks

dabail10 reviewed Dec 5, 2025

View reviewed changes

lettie-roach reviewed Dec 8, 2025

View reviewed changes

eclare108213 mentioned this pull request Dec 10, 2025

Adjust wave forcing logic #546

Open

erinethomas mentioned this pull request Dec 18, 2025

Wave-Sea Ice Coupling E3SM-Project/E3SM#7958

Draft


		integer (kind=int_kind) :: k

		w_amp = c2* SQRT(SUM(local_wave_spec*dwavefreq)) ! sig wave amplitude

external wave height option #545

Are you sure you want to change the base?

external wave height option #545

Uh oh!

Conversation

eclare108213 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR checklist

Uh oh!

eclare108213 commented Dec 5, 2025

Uh oh!

lettie-roach commented Dec 5, 2025

Uh oh!

eclare108213 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dabail10 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lettie-roach commented Dec 6, 2025

Uh oh!

anton-seaice commented Dec 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apcraig commented Dec 8, 2025

Uh oh!

erinethomas commented Dec 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

eclare108213 commented Dec 5, 2025 •

edited

Loading

eclare108213 commented Dec 5, 2025 •

edited

Loading