Wave - ocean coupling - Githubissues

arunchawla-NOAA commented 4 years ago

Finalize wave - ocean coupling and confirm it is working

JessicaMeixner-NOAA commented 4 years ago

Work on this issue is on this branch: https://github.com/JessicaMeixner-NOAA/ufs-s2s-model/tree/feature/waveoceancpl

This will have updates in MOM6 and WW3.

Related issue for WW3: https://github.com/NOAA-EMC/WW3/issues/191 Related issue for MOM6: https://github.com/NOAA-EMC/MOM6/issues/2

Current status is all components are coupled together, but quickly crash in the second time step. Forcing the EPBL/Langmuir mixing to be off, the coupled model does run successfully. Next steps are to output intermediate values to see where unrealistic values that are crashing the model are occurring.

JessicaMeixner-NOAA commented 4 years ago

The current bug with wave-ocean has been identified as WaveNum_Cen were being reset to 0, which was causing Langmuir to be NaN which was causing MOM6 to abort with NaNs. Working on a fix for this now.

JessicaMeixner-NOAA commented 4 years ago

Cold start now runs again with wave-ocean coupling as of commit 955e56c0b4220eae17c5b19b28810456fea5d3e0 in ufs-s2s-model (thanks to @breichl for helping debug).

Next step is to run warm start and longer runs confirming everything is okay. Also need to double check what is happening in the wave model when exporting on cells with ice. We are now using wave mask in interpolation:

 WAV -> ATM :srcMaskValues=1
 WAV -> OCN :srcMaskValues=1

JessicaMeixner-NOAA commented 4 years ago

4 long runs (Jan, April, July and October of 2013) were made. They did not complete the 35 days in the wall-clock limit, the balance between the components will need to be re-adjusted. But given that they only made it through about 22 days, @LydiaStefanova-NOAA and @jiandewang can you help me look at the output: /scratch1/NCEPDEV/stmp2/Jessica.Meixner/scrub/rtgen.24716 and make sure everything looks okay?

jiandewang commented 4 years ago

I checked several random selected ocean output, they look fine.

JessicaMeixner-NOAA commented 4 years ago

Thanks @jiandewang

LydiaStefanova-NOAA commented 4 years ago

Here is what I see from the tiled phy* fields (having so far looked only at the 20130101 run):
(a) there are no pathological values for any of the fields (b) compared to the previous CCPP runs (saved from IPD vs CCPP comparison), the results have systematic differences. This is most pronounced over land, over the Mediterranean+Black+Caspian+Red seas, and possibly over sea ice. It appears to be related to a difference in the PBL parameterization or something that impacts it - or possibly initial conditions? see attached ppt: Waves-vs-CCPP-20130101.pptx (c) something else I noticed: for both IPD and CCPP comparison runs, the minimum value for sfc roughness was 1e-07, for the wave-coupled run it is 0 (but I can't speak to the importance of this)

JessicaMeixner-NOAA commented 4 years ago

For b) I think this maybe changes in the atmospheric model in-between the last two runs. I'll make some clean comparison runs as well to confirm, since I wouldn't expect that changes to add wave-atm and wave-ocean coupling would only show up on land.

For c) this is from wave->atm coupling in atmos_mod the lower bound is set to zero: https://github.com/NOAA-EMC/fv3atm/blob/develop/atmos_model.F90#L1681

junwang-noaa commented 4 years ago

For b) a physics update for a canopy heat storage parameterization was committed on Tuesday. It can cause changes near surface. Current s2s is using that version. It's good to have a clean run from the current top of s2s as baseline to compare with the runs with the ocean-wave coupling

For c) the lower bound is set to "0.1", not zero in the https://github.com/NOAA-EMC/fv3atm/blob/develop/atmos_model.F90#L1681 in atmosphere. Zero in the statement is to prevent negative values,

On Fri, May 1, 2020 at 9:48 AM Jessica Meixner notifications@github.com wrote:

For b) I think this maybe changes in the atmospheric model in-between the last two runs. I'll make some clean comparison runs as well to confirm, since I wouldn't expect that changes to add wave-atm and wave-ocean coupling would only show up on land.

For c) this is from wave->atm coupling in atmos_mod the lower bound is set to zero: https://github.com/NOAA-EMC/fv3atm/blob/develop/atmos_model.F90#L1681

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-s2s-model/issues/37#issuecomment-622395656, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7D6TMFILQH5MYXYCYS2ULRPLHJ3ANCNFSM4LCRDECA .

LydiaStefanova-NOAA commented 4 years ago

So, for (c), it seems that the end result of that line is that the lower bound is set to 0 (to prevent negative values) and the upper bound is set to 0.1 (*100)? Was the "zero" on that line previously "1e-09"? If it was always "0", that would mean that previously there were no negative values coming in to override, and now there are - right?

SMoorthi-emc commented 4 years ago

The minimum value was set to zero so that it is up to the wave model to provide the appropriate z0. However, upper limit is set at 0.1m, which can be relaxed if waves require larger value. When wave model is not used, GFS puts a lower limit of 1.0e-7cm for ocean. Please note that the unit of z0 is in cm; that is why the factor 100.

JessicaMeixner-NOAA commented 4 years ago

Status update for wave-ocean coupling:

Running with WW3 as well as all other components in debug mode has been challenging. Still working on this, but WW3 has not ever been run in debug mode with the cap successfully to my knowledge. The existing FV3-MOM6-CICE5 debug test can still be run though. If this is a requirement for the PR, this will take a while.
If debug for WW3 is not a requirement, currently running one last experiment trying to get exception values sent to FV3 for wave-atm coupling so that if WW3 has an area blocked out or not in the mesh (such as lakes) instead of 0s being set from WW3, hopefully FV3 will use its previous values. This could also help for ice coverage areas. If the exception value does not work, this will have to be something we improve on in further prototypes when WW3 goes through the mediator.
WW3 uses a variable called FICEN. The default of FICEN is 0.5. When the ice fraction exceeds FICEN when using IC0 (as we currently are), no wave fields are calculated. To me this is not the same as keeping the minimum ice fraction consistent through the components. This is basically saying if there is more than FICEN coverage of ice, that we are damping the waves to zero. More advanced wave-ice source terms can be (and are planned) to be explored in future prototypes.
A final set of regression tests for the ufs-s2s-model needs to be ran (and a new baseline created due to wave updates). Then MOM6 and WW3 will need to go to their respective PR processes. For WW3 this requires running the standalone regression tests. These currently cannot be run on Orion, so if they are not finished today it will be Wednesday before WW3 regression tests can be completed and the PR process can start. I have shown the changes of MOM6 to @jiandewang and @DeniseWorthen to get an advanced start on any possible requested changes/updates. This is why the debug tests are being run.

JessicaMeixner-NOAA commented 4 years ago

When we have the final set of updates I'll make a clean run comparing wave-coupling to the baseline, so that changes from fv3atm will not be confused with wave-ocean updates, before submitting the final PR to ufs-s2s-model.

DeniseWorthen commented 4 years ago

@JessicaMeixner-NOAA : Are we ready to close this issue or do you want to wait until we see the initial set of Prototype4 runs?

JessicaMeixner-NOAA commented 4 years ago

@DeniseWorthen let's wait for the 28 comparison runs, post the updates and then close.

ufs-community / ufs-s2s-model

Wave - ocean coupling #37