Stokes Drift Vel mismatch between WWM and WW3 in VF coupled mode

[janahaddad]

Description

Stokes drift velocity mismatch between Vortex formalism implementations in SCHISM+WW3 and SCHISM+WWM

https://github.com/NOAA-EMC/WW3/blob/dev/ufs-weather-model/model/src/w3oacpmd.F90 --> OASIS coupler

https://github.com/NOAA-EMC/WW3/blob/dev/ufs-weather-model/model/src/wav_import_export.F90#L1464 --< CalcStokes subroutine which is used in UFS

https://github.com/NOAA-EMC/WW3/blob/dev/ufs-weather-model/model/src/w3iogomd.F90 --> main code computation of Stokes drift vels (USSX, USSY)

https://github.com/NOAA-EMC/WW3/blob/dev/ufs-weather-model/model/src/wmesmfmd.F90 --> looks like a NUOPC Cap code for multi-grid WW3 which also computes it's own Stokes drift terms

Code inside WWM: https://github.com/schism-dev/schism/blob/master/src/WWMIII/wwm_coupl_selfe.F90#L103

Calc of Stokes Drift for WW3 output : https://github.com/NOAA-EMC/WW3/blob/d09a7a97241a5c75b9c5452711f0080b2a2dba1b/model/src/wav_import_export.F90#L723C5-L754

• actually this looks like it's for CESM

Notes:

• Frequency definitions in WWM and WW3 are inherently different (WW3 has a formula to define freq spread, while WWM has upper and lower limits and linearly interpolates)

Additional context

Output

[uturuncoglu]

Denise's comments about the calculation of stokes drift:

For UFS, we only export and use the partitioned stokes drift. I believe since CESM also only uses partitioned stokes drift (to send to MOM6). 

The important bit is here, related to the comment about the frequency that it is being calculated.

https://github.com/NOAA-EMC/WW3/blob/d09a7a97241a5c75b9c5452711f0080b2a2dba1b/model/src/wav_import_export.F90#L723C5-L754

Originally, the export of spectrum stokes was outside of the CESM ifdef and it would have been updated only at the history frequency, since it is directly using the USSX and USSY fields from w3adatmd. 

When exporting the stokes spectrum for Coastal, I needed to add a calculation of the field at the coupling frequency.

Even though I was pretty sure that CESM was never using the spectrum stokes drift, I didn't want to change the frequency at which it was calculated for CESM. So I moved it inside the ifdef.

When I was adding the export for the coastal fields, I checked them against what was being written to the history files (at the coupling frequency) and made sure they matched. I'm pretty sure I would have verified that the history field was the same as the export field, but I might not have recognized that the history field itself looked funny.

If you add in ww3_shel.nml the list of output variables

&output_type_nml
  type%field%list = 'USS ....'

and
&output_date_nml
  date%field%outffile  = '1'
  date%field%stride    = coupling frequency

that should write the spectrum stokes to the history file (USSX, USSY) and you can check it and compare w/ the export field.

[danishyo]

Hi @uturuncoglu & @yunfangsun ,
WWM input setup is at /work2/noaa/nosofs/yjzhang/Dan/UFS/Sandy_DUCK/wwm_test
Change RADFLAG to "VOR" or "LON" in wwminput.nml will run different coupling setting.
Also, make sure delete any fort.5002 before launch the run.

UFS-run for different coupling run, path are
LON: /work2/noaa/nosofs/yjzhang/Dan/UFS/Sandy_DUCK/couple_run_final_BT1_lon
VOR: /work2/noaa/nosofs/yjzhang/Dan/UFS/Sandy_DUCK/couple_run_final_BT1_vor

By the way, @uturuncoglu , could you point me which files I can modify to change compile opt-level for UFS-coastal? Thx!

[yunfangsun]

The SCHISM-WWM and SCHISM-WW3 current profile comparisons at 2 stations are as follows:

comparisons

The SCHISM-WW3 one way coupling (atm>sch atm>ww3 sch>ww3) results are compared with SCHISM-WW3
comparisons

Hi @danishyo ,

Could you suggest how could I run a sch-wwm ((atm>sch atm>ww3m sch>wwm)) one way coupling case? Thank you

[janahaddad]

@felicio93 note that this is where this issue is being logged.

[felicio93]

@yunfangsun, SCHISM+WWM has these options:
'icou_elfe_wwm':
! 0: no elevation and no currents in wwm, no wave force in SCHISM (but wave turbulecne, WBL etc are still in SCHISM);
! 1: full coupled (elevation, vel, and wind are all passed to WWM);
! 2: elevation and currents in wwm, no wave force in SCHISM;
! 3: no elevation and no currents in wwm, wave force in SCHISM;
! 4: elevation but no currents in wwm, wave force in SCHISM;
! 5: elevation but no currents in wwm, no wave force in SCHISM;
! 6: no elevation but currents in wwm, wave force in SCHISM;
! 7: no elevation but currents in wwm, no wave force in SCHISM;

I think atm>sch and atm>wwm would be icou_elfe_wwm=0, and sch>wwm would be icou_elfe_wwm=2, correct @danishyo ?

[danishyo]

Thanks @felicio93 , yes, this is the right option.

[uturuncoglu]

@yunfangsun @janahaddad @josephzhang8 I think both link belongs to same document. Right? and you have no feedback from wave. If so, It seems that there is no too much difference in the currents when you compare two-way vs. one-way. So, this indicates that the issue is in ocean side. Maybe mixing parametrization etc. You might want to try different options to simulate circulation better. Once we have confidence datm->schism is fine and consistent with observation you could try to move and add wave component.

[yunfangsun]

Hi @uturuncoglu ,

The two links are two documents, and there are big differences between the one-way and two-way simulation, for the one-way coupling, both the 2d and 3d coupling have the same results for currents, which means the schism part is consistent, however, they are not near to the observations.

[uturuncoglu]

@yunfangsun Maybe I am misinterpreting but if you look at 2nd document and compare SCHISM results with the observation (slide 1 and column 1) the 2d and 3d results way more off from the observation. It is also same for slide 2. Why? I think we have to answer this question before comparing one-way with two-way.

[danishyo]

I think right now we should focus on mismatch exchange fields like stoke's drift.
This is more bigger issue need to be resolved first.
Then we can do model tuning for the final step.

[josephzhang8]

I agree with @danishyo. We know how to calibrate/tune the model once the variables make sense.