Skip to content

Conversation

hdrake
Copy link

@hdrake hdrake commented Aug 15, 2024

@hdrake hdrake changed the title Attempt to pass new seaice_melt field through the GFDL MOM6-SIS2 coupler Attempt to pass new seaice_melt field through the GFDL MOM6-SIS2 coupler Aug 15, 2024
@hdrake hdrake marked this pull request as draft August 15, 2024 17:27
@hdrake hdrake changed the title Attempt to pass new seaice_melt field through the GFDL MOM6-SIS2 coupler Attempt to new seaice_melt field from SIS2 to MOM6 Aug 16, 2024
@hdrake hdrake marked this pull request as ready for review August 16, 2024 23:54
@hdrake hdrake changed the title Attempt to new seaice_melt field from SIS2 to MOM6 Pass new seaice_melt field from SIS2 to MOM6 Aug 16, 2024
@theresa-cordero
Copy link

Were you able to test the changes to the non-FMS caps with the associated couplers?

@theresa-cordero
Copy link

Is the expected behavior here that lprec_new + seaice_melt = lprec_old? And if so, do you find that to be the case?
lprec_new being the the liquid precititation into the ocean after these changes and lprec_old being the liquid precititation before these changes.

@hdrake
Copy link
Author

hdrake commented Aug 19, 2024

Is the expected behavior here that lprec_new + seaice_melt = lprec_old? And if so, do you find that to be the case?
lprec_new being the the liquid precititation into the ocean after these changes and lprec_old being the liquid precititation before these changes.

Yes, that is the expected behavior. I have not done a careful side by side comparison to verify they are the same, but visually they look like it.

What kind of workflow do you use to directly compare two configurations? Checkout the different commits and manually run different configurations and compare the outputs?

@hdrake
Copy link
Author

hdrake commented Aug 19, 2024

Were you able to test the changes to the non-FMS caps with the associated couplers?

No, I've only tested with the Baltic_OM4_05 configuration that I believe uses the FMS cap.

@theresa-cordero
Copy link

What kind of workflow do you use to directly compare two configurations? Checkout the different commits and manually run different configurations and compare the outputs?

Yes. Checkout and compile the dev/gfdl code, run and save lprec. Then recompile with all changes are rerun the experiment saving lprec and seaice_melt. I think it would be sufficient to test the final versions of MOM6, SIS2, and the coupler and not every commmit along the way (assuming of course that it works).

@hdrake
Copy link
Author

hdrake commented Aug 19, 2024

Were you able to test the changes to the non-FMS caps with the associated couplers?

@theresa-morrison, are these particular experiments I should test with? I guess all of the ones named SIS2_* in the MOM6-examples/ice_ocean_SIS2?

@hdrake
Copy link
Author

hdrake commented Aug 20, 2024

Is the expected behavior here that lprec_new + seaice_melt = lprec_old? And if so, do you find that to be the case?
lprec_new being the the liquid precititation into the ocean after these changes and lprec_old being the liquid precititation before these changes.

Below is a comparison between the current MOM6-examples/dev/gfdl and my three PRs.

Screenshot 2024-08-19 at 5 13 46 PM

I do not have any idea why the two are different. I don't see how I could have gone wrong in separating the diagnostics in the source code...

@hdrake
Copy link
Author

hdrake commented Aug 20, 2024

Is it possible that the answers with default parameter values have changed this much?

The boundary mass flux diagnostics seem internally consistent within each of the simulations:
Screenshot 2024-08-19 at 6 05 22 PM

(These residuals are about 1e-5 each of the individual terms in the budget, so indistinguishable from zero at single precision.)

@theresa-cordero
Copy link

There should be no parameter changes between the two experiments!
If you are using the version of MOM6 in MOM6 examples for the "old" experiment, you should instead use the version of dev/gfdl that this was branched from to make sure you have all the same defaults.

@hdrake
Copy link
Author

hdrake commented Aug 20, 2024

If you are using the version of MOM6 in MOM6 examples for the "old" experiment, you should instead use the version of dev/gfdl that this was branched from to make sure you have all the same defaults.

Okay, yeah that makes sense. I'll figure out how to do that and regenerate these plots.

@marshallward
Copy link
Member

Some additional comments

  • The changes to STALE_mct_cap and nuopc_cap should be removed. These caps are not meant to be used with the FMS coupler, and we don't maintain them. They already have their methods for handling ice-ocean boundaries.

    Additionally, STALE_mct_cap is an archived copy of an unmaintained MCT cap, so it should never be changed.

  • Are modifications to MESO permitted? I am unsure if it's meant to be an archive of the original experiments, or if we should extend its support? (I suppose it should give identical answers either way? Maybe this is OK. I will confirm.)

    Similar comments for BFB and dumbbell, although they are probably OK.

@hdrake
Copy link
Author

hdrake commented Aug 20, 2024

There should be no parameter changes between the two experiments!
If you are using the version of MOM6 in MOM6 examples for the "old" experiment, you should instead use the version of dev/gfdl that this was branched from to make sure you have all the same defaults.

Okay, I did a clean comparison where the only changes were those in my three branches, and I confirmed there were no differences between the MOM_parameter_doc.all and SIS_parameter_doc.all files. However, the differences in the outputs shown above persisted. So it seems I must be doing something wrong in one of these PRs.

@hdrake hdrake marked this pull request as draft August 20, 2024 17:00
Copy link

codecov bot commented Aug 20, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 35.91%. Comparing base (9b45087) to head (13b9960).

Additional details and impacted files
@@             Coverage Diff              @@
##           dev/gfdl     #710      +/-   ##
============================================
- Coverage     37.03%   35.91%   -1.13%     
============================================
  Files           273      270       -3     
  Lines         82538    81496    -1042     
  Branches      15441    15427      -14     
============================================
- Hits          30568    29269    -1299     
- Misses        46253    46458     +205     
- Partials       5717     5769      +52     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@hdrake
Copy link
Author

hdrake commented Dec 11, 2024

This recent SIS2 commit (NOAA-GFDL/SIS2@5ecae71) to the related PR NOAA-GFDL/SIS2#214 fixes the bug discussed in the above #710 (comment). Essentially, I had removed the line of code that reset the calculation of the sea ice melt rate to zero every timestep,

net_melt(:,:) = 0.

and was just accumulating larger and larger melt rates every timestep...

After fixing this, this PR (and the related ones) now correctly separates the liquid precipitation and sea ice melt rate ocean diagnostics, as demonstrated by tests of the Baltic_OM4_05 configuration with and without the new code:
Screenshot 2024-12-11 at 2 04 23 PM

Screenshot 2024-12-11 at 2 23 39 PM

@hdrake
Copy link
Author

hdrake commented Dec 11, 2024

@marshallward and @theresa-morrison, I think this is ready for review now!

@hdrake hdrake marked this pull request as ready for review December 11, 2024 22:47
Copy link
Member

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

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

This PR is incomplete. Because fluxes%seaice_melt was separated out from fluxes%lprec, they should always occur together. As such, I suspect that there need to be changes added to diagnostics/MOM_sum_output.F90, ice_shelf/MOM_marine_ice.F90 and ice_shelf/MOM_ice_shelf.F90, and there are still about 2 dozen places in MOM_forcing_types.F90 where fluxes%lprec is used but fluxes%seaice_melt is not. Please reexamine the indicated files for the missing code additions.

@@ -604,7 +611,7 @@ subroutine convert_IOB_to_fluxes(IOB, fluxes, index_bounds, Time, valid_time, G,
if (CS%use_net_FW_adjustment_sign_bug) sign_for_net_FW_bug = -1.
do j=js,je ; do i=is,ie
net_FW(i,j) = US%RZ_T_to_kg_m2s* &
(((fluxes%lprec(i,j) + fluxes%fprec(i,j)) + &
((((fluxes%lprec(i,j) + fluxes%seaice_melt(i,j)) + fluxes%fprec(i,j)) + &
(fluxes%lrunoff(i,j) + fluxes%frunoff(i,j))) + &
(fluxes%evap(i,j) + fluxes%vprec(i,j)) ) * US%L_to_m**2*G%areaT(i,j)
! The following contribution appears to be calculating the volume flux of sea-ice
Copy link

Choose a reason for hiding this comment

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

I think that seaice_melt might now be removed from the summation above, since the purpose of the code below appears to be to remove it from the net_FW flux.

We recently noticed some diagnosed imbalances in ice+ocean water conservation in OM5 with (CS%adjust_net_fresh_water_to_zero=.true.). If I understood the comments below, then I think this PR would take care of that non-conservation by no longer using the imperfect estimate for seaice_melt below.

Copy link
Author

Choose a reason for hiding this comment

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

Oh, I see. I will try to replacenet_FW with fluxes%seaice_melt directly then.

Continues to address @Hallberg-NOAA's [concern](NOAA-GFDL/SIS2#214 (comment)) that these diagnostics could change
with the level of compiler optimization by adding parentheses to preserve the order
in which fluxes are added together.

However, there are some locations where I did not see how this was possible, as in
this comment: NOAA-GFDL/SIS2#214 (comment)
@@ -2496,6 +2489,9 @@ subroutine get_net_mass_forcing(fluxes, G, US, net_mass_src)
if (associated(fluxes%lprec)) then ; do j=js,je ; do i=is,ie
net_mass_src(i,j) = net_mass_src(i,j) + fluxes%lprec(i,j)
enddo ; enddo ; endif
if (associated(fluxes%seaice_melt)) then ; do j=js,je ; do i=is,ie
Copy link
Member

@Hallberg-NOAA Hallberg-NOAA Apr 30, 2025

Choose a reason for hiding this comment

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

Moving up the contribution of fluxes%seaice_melt will change answers for people who are using the NUOPC coupler. Adding the contributions from fluxes%lprec and fluxes%seaice_melt separately will change answers for people using the FMS coupler. I suspect that we are going to need a runtime logical flag here as well to avoid changing somebody's answers.

if (associated(fluxes%heat_content_lprec)) then
if (fluxes%lprec(i,j) > 0.0) then
Copy link
Member

Choose a reason for hiding this comment

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

I believe that these changes will change answers for people (like EMC and NCAR) that were already using fluxes%seaice_melt. We are probably going to need to control this with a runtime logical flag.

@@ -631,12 +634,9 @@ subroutine extractFluxes1d(G, GV, US, fluxes, optics, nsw, j, dt, &
if (fluxes%evap(i,j) < 0.0) netMassOut(i) = netMassOut(i) + fluxes%evap(i,j)
! if (associated(fluxes%heat_content_cond)) fluxes%heat_content_cond(i,j) = 0.0 !??? --AJA

! lprec < 0 means sea ice formation taking water from the ocean.
! smg: we should split the ice melt/formation from the lprec
if (fluxes%lprec(i,j) < 0.0) netMassOut(i) = netMassOut(i) + fluxes%lprec(i,j)
Copy link
Member

@Hallberg-NOAA Hallberg-NOAA Apr 30, 2025

Choose a reason for hiding this comment

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

The changes in the next ~8 lines will change answers for people who are using the NUOPC coupler and are already using fluxes%seaice_melt. A runtime flag might be needed here as well to recreate previous answers.

+ fluxes%vprec(i,j) ) &
+ fluxes%seaice_melt(i,j)) &
+ fluxes%frunoff(i,j) ))
+ fluxes%seaice_melt(i,j)) &
Copy link
Member

Choose a reason for hiding this comment

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

Both this reordering of the math and the one in about another 10 lines are needed to preserve answers with the FMS coupler, but will change answers with the NUOPC coupler. A runtime logical flag might be needed here to preserve both sets of answers, and make the default the setting that is needed with the NUOPC coupler, since active intervention will be needed to use seaice_melt with the FMS coupler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants