Improve WW3 mesh cap to allow using vortex formulation in ocean side

[janahaddad]

Background

[based on @uturuncoglu email] UFS Coastal is working on coupling WW3 and SCHISM. We're able to run 2D configurations of SCHISM + WW3 with mesh cap (or NCAR cap) without any issues, but we are preparing the way for running in 3D mode (https://github.com/oceanmodeling/ufs-coastal/issues/32). This requires additional fields from WW3.

The aim is to add missing fields to the WW3 cap (I think they are already available through OASIS complier) and complete the wiring with the SCHSIM (the interaction with wave with new formulation is already implemented) to enable 3d coupling

Info needed to proceed

• Need clarification of which variables are exported from WW3 and their units (mesh-cap)
  • Mesh-cap import/export variables and their units
• Need modification on WW3 side to get those field exported
• See here (NOAA EMC branch):
  https://github.com/NOAA-EMC/WW3/blob/d9b3172f4197c65d471662c6952a668152d71230/model/src/wav_import_export.F90#L138
• Oceanmodeling branch version:

  WW3/model/src/wav_import_export.F90

  Line 139 in 80a5ad5

  if (.not. unstr_mesh) then

@DeniseWorthen we will follow up for a description of what we're searching for here !

cc @josephzhang8 @uturuncoglu @yunfangsun @saeed-moghimi-noaa @anntsay

[DeniseWorthen]

The cpl_scalars are used when CMEPs write history or other files and allows the fields on the mesh to be written as 2-D fields. This simply removes the cpl_scalars from the export fields list, since in the unstructured case it doesn't make sense.

[janahaddad]

from @DeniseWorthen email:

In wav_import_export there are several "calc" routines which we moved over from the old esmf cap to the new mesh cap. I think some of the fields I see listed (like the stokes-drift spectrum, calcstokes3d) are there in the old cap, but were not added to the new cap. I think it is straightforward to add them to the new cap.

Some of the other fields---well, I have no idea what internal WW3 fields correspond to the needed export. But, if it is calculated as a "history" field in WW3, I think you could make them available by adding additional "calc" routines in wav_import_export. For example, in wav_grdout, I see

varatts( "BHD ", "BHD ", "Bernoulli head (J term) ", "m2 s-2 ", " ", .false.)

and if I look in w3iogomd, I see how that term is calculated on LN 1653. I think you can find the bottom momentum fluxes also.

As for units, I'm not 100% sure I got them right when I wrote the wav_grdout. Ana has found a couple of errors (I still have on my list to fix these!). I think you'll need to rely on wave modelers to be entirely sure of the units.

[janahaddad]

@uturuncoglu @DeniseWorthen transferring conversation on this issue from email to GH! thx

[DeniseWorthen]

For point of clarify, you do want any export fields to be calculated in the cap, and not just use them from the internal fields that WW3 might calculate as an output variable. The reason is that the output variables are only calculated at some set frequency, and you want the export fields to be updated at each modelAdvance. See NOAA-EMC#843

[uturuncoglu]

@DeniseWorthen Yes, it would be nice to have them in the cap and updated with coupling frequency. It would be also nice to have them in the output but we could still output import and export states for debugging purpose.

[janahaddad]

from @DeniseWorthen: w3ounfmetamd.F90 is script with BHD, etc. units as above...

[saeed-moghimi-noaa]

Denise Worthen - NOAA Affiliate
1:51 PM
All the mesh-cap files are named as wav_*F90

[saeed-moghimi-noaa]

Denise Worthen - NOAA Affiliate
1:53 PM
wav_import_export.F90

[saeed-moghimi-noaa]

where to add field to w3:

[saeed-moghimi-noaa]

[saeed-moghimi-noaa]

See in this file (in ufs-weather there is one) in application level: something like this:
Denise Worthen - NOAA Affiliate
1:56 PM
fd_ufs.yaml

[saeed-moghimi-noaa]

This file is not reserved for ufs-weather (coastal):

Panagiotis Velissariou - NOAA Affiliate
2:00 PM
./tests/parm/fd_ufs.yaml

This one is the one we suppose to use the one under:
tests/parm/fd_ufs.yaml

[saeed-moghimi-noaa]

• need to create the variables
• create calculation routine
• create export var
• extort

[saeed-moghimi-noaa]

Just to document chats from the meeting:

Jana Haddad - NOAA Affiliate
1:33 PM
#11
Denise Worthen - NOAA Affiliate
1:44 PM
w3ounfmetamd.F90
Ali Abdolali
1:46 PM
Are we doing 2D or 3D coupling or both? And could you pass the list of variabls you need?
for 2D, we need SXX, XYY and SXY,
but for 3D, we need more
Ali Salimi - NOAA Affiliate
1:47 PM
https://docs.google.com/document/d/140_xAMOb30iljGL09C_S7tNAKGDY2j8GEjPb7Pg3Xxg/edit
Jana Haddad - NOAA Affiliate
1:47 PM
https://docs.google.com/document/d/140_xAMOb30iljGL09C_S7tNAKGDY2j8GEjPb7Pg3Xxg/edit
Ali Salimi - NOAA Affiliate
1:47 PM
Ali I think they are here
Ali Abdolali
1:47 PM
thanks
Ali Abdolali
1:48 PM
SO, as Denise said, for ufs-weather-model, we already have a few variables for coupling. Do you want Ufuk to add the rest to the same location?
I would recommend do not go back and forth between wmesmf, OASIS, cstorm, ... because as Denise said, they do not show up magically.
Ali Abdolali
1:51 PM
the same should apply to import fields to WW3 mesh cap
Denise Worthen - NOAA Affiliate
1:51 PM
All the mesh-cap files are named as wav_*F90
Denise Worthen - NOAA Affiliate
1:53 PM
wav_import_export.F90
Denise Worthen - NOAA Affiliate
1:56 PM
fd_ufs.yaml
Panagiotis Velissariou - NOAA Affiliate
2:00 PM
./tests/parm/fd_ufs.yaml
Denise Worthen - NOAA Affiliate
2:00 PM
can I ask---your coastal oceanmodel is now a fork of ufs-wm?
Panagiotis Velissariou - NOAA Affiliate
2:00 PM
./CMEPS-interface/CMEPS/mediator/fd_cesm.yaml
Denise Worthen - NOAA Affiliate
2:02 PM
tests/parm/fd_ufs.yaml
Ali Abdolali
2:06 PM
where is the caluclation routine? in wave_import?
Ali Abdolali
2:16 PM
FYI, Denise does not consider herself a WW3 developer :)
Ali Salimi - NOAA Affiliate
2:19 PM
We are not seeing
Denise Worthen - NOAA Affiliate
2:22 PM
w3outg is the SR where the output variables are calculated

[josephzhang8]

Thank you all! Here is the list of arrays we need from WW3:

    wave_hs(1:np)=WW3__OHS !Sig wave height [m]
    wave_dir(1:np)=WW3__DIR !mean wave dir [deg]
    wave_tm1(1:np)=WW3_T0M1 !mean wave period [s]
    wave_wnm(1:np)=WW3__WNM !mean wave number [1/m]
    wave_pres(1:np)=WW3__BHD !wave-induced Bernoulli head pressure [N/m or Pa?]
    wave_stokes_x(1:np)=WW3_USSX !Stokes drift [m/s]
    wave_stokes_y(1:np)=WW3_USSY
    wave_ocean_flux_x(1:np)=WW3_TWOX !wave-ocean mom flux [m2/s2]
    wave_ocean_flux_y(1:np)=WW3_TWOY
    wave_flux_friction_x(1:np)=WW3_TBBX !Momentum flux due to bottom friction [m2/s2]
    wave_flux_friction_y(1:np)=WW3_TBBY
    wave_orbu(1:np)=WW3_UBRX !near bed orbital vel [m/s]
    wave_orbv(1:np)=WW3_UBRY

[DeniseWorthen]

Take the bottom momentum fields as an example: wave_flux_friction_x,y, the "momentum flux due to bottom friction" in m2 s-2. I can see this field is exported via the oasis coupler (in w3gocmmd.F90).

It appears to be calculated in w3sbt4md.F90, at LN 556-570:

! 5. Fills output arrays and estimates the energy and momentum loss
!
DO IK=1, NK
  CONST2=DDEN(IK)/CG(IK) &         !Jacobian to get energy in band
       *GRAV/(SIG(IK)/WN(IK))    ! coefficient to get momentum
  DSUM(IK)=-FW*UORB*CBETA(IK)      !*WSUB(ISUB)
  DO ITH=1,NTH
    IS=ITH+(IK-1)*NTH
    D(IS)=DSUM(IK)
    TEMP2=CONST2*D(IS)*A(IS)
    TAUBBL(1) = TAUBBL(1) - TEMP2*ECOS(IS)
    TAUBBL(2) = TAUBBL(2) - TEMP2*ESIN(IS)
    S(IS)=D(IS)*A(IS)
  END DO
END DO

This is the code (and any preceding code on which it depends) which would need to be added in wav_import_export.F90 as a new "calc" routine. So, the steps would be (I've invented a field name here):

1. add the fields to the list of exported fields

call fldlist_add(fldsFrWav_num, fldsFrWav, 'Sw_taubot_x')
call fldlist_add(fldsFrWav_num, fldsFrWav, 'Sw_taubot_y')

2. add in export_fields (a SR in wav_import_export) code similar to the other export variables

a) define pointers to the esmf fields:

    real(r8), pointer :: tauxbot(:)
    real(r8), pointer :: tauybot(:)

b) check that the field is required in the export state using and get pointers to the fields

   if ( state_fldchk(exportState, 'Sw_taubot_x') .and. &
         state_fldchk(exportState, 'Sw_taubot_y') )then
      if (ChkErr(rc,__LINE__,u_FILE_u)) return
      call state_getfldptr(exportState, 'Sw_taubot_x', tauxbot, rc=rc)
      if (ChkErr(rc,__LINE__,u_FILE_u)) return
      call state_getfldptr(exportState, 'Sw_taubot_y', tauybot, rc=rc)
      if (ChkErr(rc,__LINE__,u_FILE_u)) return

c) Create a "calc" routine to calculate the fields, replicating whatever is required from the w3sbt4md.F90 routine.

call CalcBottomStress(input argument list, tauxbot, tauybot)

At this point, the bottom stress should be ready to be exported by WW3 at every model advance. There is more to be done however to get them sent to another component:

1. the new field names need to be defined in the field-dictionary used by all components (in UFS-WM this is in tests/parm/fd_ufs.yaml)
2. the fields need to be added to the FieldExchange module in CMEP.
3. the fields need to be requested and realized by whatever model is expecting these fields as imports.

[janahaddad]

Summary from meeting 5/28:

• both 2D and 3D coupling need to go through mesh_cap
• Ufuk updated the mesh cap in oceanmodeling/ww3 (wav_*F90) for 2D ocn+wav coupling
  • need to expand this for 3D (can collaborate to prepare PR and send PR to EMC when @uturuncoglu returns)
• there is a discrepancy between oceanmodeling/WW3 and NOAA-EMC/WW3 (by Denise) wrt how the ww3 exported fields are fed into derived fields and shared with SCHISM cap
• all models need to share test/parm/fd_ufs.yml
  • any fields needed exported from ww3 need to be added to this yml file. This yml file is fed to a generic routine that sends these fields to RealizeFields in the cap
  • calculation of each of those fields needs to be added to WW3/model/src/wave_import_export.F90
• from SCHISM interface routine, @josephzhang8 has currently put a placeholder list of field arrays expected from WW3. The names are currently from Oasis cap, and need to be updated -- See Joseph's list above.
  • these fields are in general are availble as output fields in WW3 (but not all of them @aliabdolali ?)

Next steps:

need to eventually merge import_export work that's already done for the 2d coupling:

• Ufuk needs to bring all 2D ocn-wav WW3 variable exports implemented in UFS Coastal into NOAA-EMC/WW3. @uturuncoglu perhaps this was already sent as PR to ufs-wm's WW3?
  • Takis & Joseph: Ufuk has already only added the radiation stresses, nothing else.
  • wait for Ufuk to return before making any PRs to UFS-WM/WW3

in the meantime:

• Jospeh/VIMS team + SSM team + WW3 devs (Ali A., Ali S., Saeideh) can work together to prepare the way for a future PR following these steps outlined by Denise & Ali. Thank you @DeniseWorthen for the example steps outlined above.

1. find where Joseph's list of fields above are calc'd as output fields
2. note the variable name being used & find that in subroutine that calc's the output: w3outg is the SR where the output variables are calculated
3. copy how it's being calc'd in that output routine and paste it into wave_import_export.f90. Then go into the cap and expose/export the variables to WW3

attendees: @DeniseWorthen @saeed-moghimi-noaa @josephzhang8 @pvelissariou1 @aliabdolali @AliS-Noaa Saeideh Banihashemi @yunfangsun

[janahaddad]

Here is the history showing Ufuk's addition of radiation stress components to wav_import_export.f90, on the UFS Coastal side:

He added to advertise_fields SR:

      call fldlist_add(fldsFrWav_num, fldsFrWav, 'Sw_wavsuu')
      call fldlist_add(fldsFrWav_num, fldsFrWav, 'Sw_wavsuv')
      call fldlist_add(fldsFrWav_num, fldsFrWav, 'Sw_wavsvv')

and corrected those names in export_fields SR.

Looks like those changes have not been merged to UFS-WM's WW3 branch. See here.

[DeniseWorthen]

I need to amend what I wrote previously, because it appears that taubbl might be calculated prognostically at each model advance in the w3srcemd routine. In that case, I believe it would not be required to add a new calc routine, but you could simply 'use' the taubbl values as calculated by the model (they're in w3adatmd). Then in export_fields, you'd have instead of calling a new calc routine in step 2c above,

       do jsea=1, nseal_cpl
        call init_get_isea(isea, jsea)
        ix  = mapsf(isea,1)
        iy  = mapsf(isea,2)
        if (mapsta(iy,ix) == 1) then
           tauxbot(jsea) = taubbl(1)
           tauybot(jsea) = taubbl(2)
        end if
      end do

[josephzhang8]

Thx @DeniseWorthen for your instructions!
The calculation of tau*bot you showed above seems to suggest it's from the multi-grid (not UG) version of WW3?

[DeniseWorthen]

@josephzhang8 Thanks, I should have looked more carefully. I think it should actually just be

        do jsea=1, nseal_cpl
           tauxbot(jsea) = taubbl(jsea,1)
           tauybot(jsea) = taubbl(jsea,2)
        end do

since taubbl allocated as (nsealm,2)

[josephzhang8]

That makes sense. Thx @DeniseWorthen

[josephzhang8]

The list of WW3 variables SCHISM needs (from OASIS ):
wave_hs(1:np)=WW3__OHS !Sig wave height [m]
wave_dir(1:np)=WW3__DIR !mean wave dir [deg]
wave_tm1(1:np)=WW3_T0M1 !mean wave period [s]
wave_wnm(1:np)=WW3__WNM !mean wave number [1/m]
wave_pres(1:np)=WW3__BHD !wave-induced Bernoulli head pressure [N/m or Pa?]
wave_stokes_x(1:np)=WW3_USSX !Stokes drift [m/s]
wave_stokes_y(1:np)=WW3_USSY
wave_ocean_flux_x(1:np)=WW3_TWOX !wave-ocean mom flux [m2/s2]
wave_ocean_flux_y(1:np)=WW3_TWOY
wave_flux_friction_x(1:np)=WW3_TBBX !Momentum flux due to bottom friction [m2/s2]
wave_flux_friction_y(1:np)=WW3_TBBY
wave_orbu(1:np)=WW3_UBRX !near bed orbital vel [m/s]
wave_orbv(1:np)=WW3_UBRY

[josephzhang8]

@aliabdolali many thanks for taking time help us set up the test!

You can find the setup for SCHISM-WWM for the analytical case at:
https://columbia.vims.edu/schism/schism_verification_tests/Test_WWM_Analytical/

The web may warn you about potential risk; just accept and you'll see the dir (our IT guy is still looking to upgrade). Let me know if you have any questions. Thx!

[uturuncoglu]

@DeniseWorthen @josephzhang8 I think we could use this issue for WW3 implementation. I'll open another one under SCHSIM-ESMF to track issues specifically for ocean component.

[danishyo]

@danishyo Please let me know which level you could reach. So, I could fix it after that point.

I can access till /work2/noaa/stmp/tufuk/stmp/tufuk

[uturuncoglu]

@danishyo Okay. I think I fixed it. Could you try again?

[danishyo]

@danishyo Okay. I think I fixed it. Could you try again?

No, I can reach to /work2/noaa/stmp/tufuk/stmp/tufuk/FV3_RT/

[uturuncoglu]

Strange. Could you try again?

[danishyo]

It works now, thanks! Ufuk Turunçoğlu ***@***.***>於 2024年9月10日 週二，下午6:07寫道：

…

Strange. Could you try again? — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3S4J4V7H64K52UWBXKRMLZV5USBAVCNFSM6AAAAABHU5JEW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBSGEYDCOJSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[danishyo]

Hi @uturuncoglu

I got the following compile error on Hercules but this does not happen on Frontera.
I also need to replace fd_ufs.yaml of this branch to bypass errors in PET log (like Sw_hs conneting error).
But the run stops with “EXTCDE MPI_ABORT, IEXIT= 17”, which comes from WW3.
You can check run folder on Frontera at /scratch1/06923/hyu05/FV3/ufs-coastal/Test_Duck/couple_test

Hercules compiling error are as following:
/home/feiye/work2_Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/WW3/model/src/wav_shr_mod.F90(11): error #7013: This module file was not generated by any release of this compiler. [ESMF]
use ESMF , only : operator(<), operator(/=), operator(+)
------^
/home/feiye/work2_Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/WW3/model/src/wav_shr_mod.F90(147): internal error: Please visit 'http://www.intel.com/software/products/support' for assistance.
rc = ESMF_SUCCESS
^
[ Aborting due to internal error. ]
compilation aborted for /home/feiye/work2_Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/WW3/model/src/wav_shr_mod.F90 (code 1)
make[2]: *** [WW3/model/src/CMakeFiles/ww3_lib.dir/build.make:933: WW3/model/src/CMakeFiles/ww3_lib.dir/wav_shr_mod.F90.o] Error 1
make[2]: *** Waiting for unfinished jobs....
SCHISM version not available, searching for src/schism_user_version.txt or default
Attempting to get version text manually from first line of
src/Core/schism_version_user.txt if file exists
d5cc484
SCHISM version: develop
GIT commit d5cc484
make[2]: Leaving directory '/work2/noaa/nosofs/Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/tests/build_fv3_coastal'
[ 25%] Built target sversion
make[2]: Leaving directory '/work2/noaa/nosofs/Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/tests/build_fv3_coastal'
make[1]: *** [CMakeFiles/Makefile2:405: WW3/model/src/CMakeFiles/ww3_lib.dir/all] Error 2
make[1]: Leaving directory '/work2/noaa/nosofs/Dan/UFS/YunFang_case/ufs-coastal_schism_3d_20240910/ufs-weather-model/tests/build_fv3_coastal'

[uturuncoglu]

@danishyo The fd_ufs.yaml was updated version in my run directory but it was linked to the source. So, maybe you could not copy that one due to the permission issue. As I understand, you fix that one. Right? Hercules compile error seems something strange. It seems that you are having issue to find the ESMF library. So maybe you are compiling model in a wrong way. Let me checkout the branch and try again in my end. It was working for me on Hercules.

[danishyo]

Hi @uturuncoglu, yes, I fixed that one for frontera run (copy from ufs-weather-model/tests/parm/fd_ufs.yaml). I use exactly the same command after "git clone" to compile on hercules, but the error came out. Since it is compile under spack-stack env, my module env should not affect it, right? My modules loaded on hercules are the following:

Currently Loaded Modules:

1. zlib/1.2.13 7) netcdf-c/4.9.0
2. sqlite/3.39.4 8) glx/1.4
3. intel-oneapi-compilers/2022.2.1 9) libxkbcommon/1.4.0
4. intel-oneapi-mpi/2021.7.1 10) qt/5.15.8
5. hdf5/1.12.2 11) cmake/3.26.3
6. netcdf-fortran/4.6.0 12) python/3.10.8

[uturuncoglu]

@danishyo I am not sure. It could interfere. Please try to run module purge before compiling manually to see what happens. You just need to go tests directory and issue command like ./compile.sh "hercules" "-DAPP=CSTLSW -DUSE_ATMOS=ON -DUSE_WW3=ON -DNO_PARMETIS=OFF -DOLDIO=ON -DPDLIB_BT4=ON" coastal intel NO NO

[danishyo]

Thanks @uturuncoglu, I clone another copy and it can compile without problem on hercules now.
Test shows exact error as Frontera run, same "EXTCDE MPI_ABORT, IEXIT= 17" error messages from WW3.
I am not really familiar about WW3 and have no clues how to solve this.
Maybe @yunfangsun can help about this?

[DeniseWorthen]

@danishyo This probably indicates an issue w/ your mod_def file being inconsistent. Is your run on hercules?

[danishyo]

Hi @DeniseWorthen, yes, you can find it at /work2/noaa/nosofs/Dan/UFS/YunFang_case/Test_DUCK/ufs_schism_ww3

[DeniseWorthen]

Is "Duck" the same domain as "Ike"?

[danishyo]

If you are refering ike_shinnecock, they are not the same domain.

[DeniseWorthen]

From the excde (17) message you're seeing, I think it might be failing in reading the mod_def file. A new mod_def file was created for Duck, right?

WW3/model/src/w3iogrmd.F90

Lines 655 to 665 in 80a5ad5

	IF ( FNAME3 .NE. TNAME3 ) THEN
	IF ( IAPROC .EQ. NAPERR ) &
	WRITE (NDSE,905) 3, FILEXT(:IEXT), FNAME3, TNAME3, &
	MESSAGE
	CALL EXTCDE ( 17 )
	END IF
	IF ( FNAMEI .NE. TNAMEI ) THEN
	IF ( IAPROC .EQ. NAPERR ) &
	WRITE (NDSE,905) 3, FILEXT(:IEXT), FNAMEI, TNAMEI, &
	MESSAGE
	CALL EXTCDE ( 17 )

[danishyo]

Yes, mod_def.ww3 & nest.ww3 are generated by standard-alone ww3_grid & ww3_bounc, and ww3_shel can run with them without problem.

[danishyo]

I think I found the problem, thanks @DeniseWorthen ‘s hint.
This branch uses different WW3 switch from coastal_app. Therefore, I need to re-compile WW3 & re-generate these *.ww3 inputs.

In coastal_app, switch are
NCO PDLIB SCOTCH SCRIP SCRIPNC NOGRB DIST MPI PR3 UQ FLX0 SEED ST4 STAB0 NL1 BT1 DB1 MLIM FLD2 TR0 BS0 RWND WNX1 WNT1 CRX1 CRT1 O0 O1 O2 O3 O4 O5 O6 O7 O14 O15 IC0 IS0 REF0

In this schism_3d branch, switch are
NCO PDLIB SCOTCH NOGRB DIST MPI PR3 UQ FLX0 SEED ST4 STAB0 NL1 BT4 DB1 MLIM FLD2 TR0 BS0 RWND WNX1 WNT1 CRX1 CRT1 O0 O1 O2 O3 O4 O5 O6 O7 O14 O15 IC0 IS0 REF0

Now the case can run successfully, but I got similar result as coastal_app. Both standard-alone WW3 & schism_3d shows similar result as the following figure.

SCHISM-WWM with VOR coupling result looks like the following:

[danishyo]

After long trial, I think we finally have larger Hs in SCHISM-WW3 result. Although the result is not similar to SCHISM-WWM.
One key setting is to set SPECTRUM%FREQ1= 0.04 in ww3_grid.nml to include lower frequency in DUCK94_wave_spectra_8m_array.nc, which has larger efth to increase Hs. It is set to 0.257 previously. This setting is equal to FRLOW in wwminput.nml.
The following figure is the test result of schism_3d SCHISM-WW3 with both NK (number of frequencies) and NTH (number of direction bins) = 12, which are set in SCHISM-WWM case.

The following figure is standard-alone WW3 results with the same settings.

I will keep to check if still anything missing in WW3 configuration in DUCK case.

[saeed-moghimi-noaa]

@danishyo Good progress!

[yunfangsun]

Hi @sbanihash, Thank you very much for your suggestions today. We and @danishyo will check our configurations again. And could you please share your WW3 stand-alone setting on Hercules @danishyo ?

[danishyo]

Hi, my standard-alone WW3 duck test configuration on Hercules is at /home/feiye/work2_Dan/UFS/YunFang_case/Test_DUCK/test_ww3/

[danishyo]

Based on @aliabdolali ’s suggestion, check “direction” from spec nc file.
Spec nc file direction convention in SCHISM-WWM (in wwm_bdcons.F90), the code description (the following figure) say it is designed as WW3 and origin from East.

Also, in original nc file, direction is about 0~10 degree, which means origin from East., In netcdf convention also show like the following:

Assuming WW3 use origin from North, after rotating 90 degrees in spec nc, (direction+90, clockwise to 90 degrees), which means also origin from East, the standard-alone WW3 result is as follows, we finally got similar pattern.

However, schism_3d couple SCHISM-WW3 looks like the following:

I will keep checking other outputs to see the possible reason from this couple result.

[danishyo]

After changing coupling setting RADFLAG=VOR in param.nml, the couple result is similar to standard-alone WW3.

[sbanihash]

Thanks for the update!

[uturuncoglu]

@danishyo yes, that is the option that needs to be activated.

[danishyo]

Hi all, I did some comparisons for both results, please see the following.

1. Hs is smaller in SCHISM-WW3
   

2. Elevation is similar.
   

3. Surface current is much smaller in SCHISM-WW3, and the flow direction is opposite.
   

4. Bottom current is also smaller in SCHISM-WW3, and the flow direction are uniform from surface to bottom.
   

[saeed-moghimi-noaa]

@danishyo @yunfangsun

Dan,
Thanks a lot for the diligent work and great progress. Impressive!

I think, making sure WW3 boundary condition is correct seems to be the 1st order of the plan. There is a course grid schism-ww3 set up that Yunfag has worked on. It might be also handy if you compare those as well.

Thanks

[danishyo]

Thanks @saeed-moghimi-noaa , sure, I can have a look to see anything still missed in the setting.
@yunfangsun could you show me the path?

[danishyo]

Hi all, I use feature/coastal_app branch (c9d2936) to test LON coupling with the same case, the following are the same comparison.
Note: in this branch, So_h is NOT imported to WW3.

1. SWH comparison, LON is similar to VOR coupling.
   

2. Elevation is similar, elevation in WW3 is 0, the figure is showing outputs from schism.
   

3. Surface current is similar but slightly different, after checking ufs.cpld.cpl.hi*nc files, I notice wavExp_So_u/v are 0, radial stress are NOT 0 in both Imp/Exp ocn/wav, this means only radial stress affect SCHISM, WW3 is NOT affected by SCHISM u/v.
   

4. Bottom current shows similar pattern as surface.
   

I also check ufs.cpld.cpl.hi*nc files in previous VOR coupling run (using feature/schism_3d branch, 51fc37a), all exchange variables (wavImp_Sw_bhd, ocnExp_Sw_bhd......) are NOT 0, so SCHISM & WW3 should exchange these info without problems.

[saeed-moghimi-noaa]

Hi @danishyo

Great job. To me wave pattern is very similar. Would you please check the spectra dimension. Seems like there is a missing g (=9.81) or a factor. or extra on the schism side. Would it be possible to also have crude comparison with observation. Or calculate record Hs from nodes very close to the boundary!

Just a hunch,
-Saeed