FV3 + SCHISM

[danishyo]

Start with RT coastal_ike_shinnecock_atm2sch & control_c192 (FV3), tests on hercules.
Both RT can run without problem.
Copy inputs from both, and tests at /work/noaa/nosofs/yjzhang/Dan/run_coastal/stmp/yjzhang/FV3_RT/manual_airSCHISM_test

Link FV3 to SCHISM:
The followings are changed in cmake/configure_apps.cmake (within CSTL region)

#set(CDEPS ON CACHE BOOL "Enable CDEPS" FORCE)
set(FV3 ON CACHE BOOL "Enable FV3" FORCE)
set(STOCH_PHYS ON CACHE BOOL "Enable Stochastic Physics" FORCE)

Then compile under tests by
./compile.sh "hercules" "-DAPP=CSTLS -DUSE_ATMOS=ON -DNO_PARMETIS=OFF -DOLDIO=ON -DCCPP_SUITES=FV3_GFS_v16" coastal_schism_atm intel NO NO

No errors in MED PETs.log (0-79) & OCN PETs log (284-286).
But ATM log(80-283) shows FV3 had some allocated errors like the following:

PET197.ESMF_LogFile:20240126 224157.830 ERROR PET197 atmos_model.F90:3154 Pointer must already be allocated - Failure to populate exported field: mean_down_lw_flx

Followed by @uturuncoglu suggestions, choose RT in HAFS, since control_c192 is standardalone ATM.
@uturuncoglu also suggest to be careful about the CCPP suite that is used by the FV3. So, some suite files are designed to work on standalone atmosphere and others for coupled application. Anyway, this is totally different application and suggested to use one of the existing atm-ocn coupled RT configuration (could be one of the HAFS one but coupling mode will be different in CMEPS side) and try to replace the ocean component (rather than using HYCOM or MOM6 use SCHISM).

Check HAFS in RT, only HAFSW & HAFS-ALL are available.

Currently choose HAFSW hafs_regional_atm_ocn to perform the test.
I will update here for further info.

[danishyo]

By using RT hafs_regional_atm_ocn setup, and replace its ocn to SCHISM (from RT coastal_ike_shinnecock_atm2sch), now SCHISM can receive sflux variables directly from FV3 without problem.

But, when SCHISM send SST to FV3 through mediator, mapping SST has weird value and cause FV3 routine stops.
It stops at "compute_qs" which use SST to derive relative humidity.

Print out input “t” before compute_qs, and a large value do exist in the array.

Check Mediator history output, and SCHISM -> Mediator is OK.

So, the issue is from the export mapping SST value (Mediator -> FV3).

The code I've changed is listed in the following and put at /work/noaa/nosofs/yjzhang/Dan/ufs-coastal/ufs-coastal

• MEPS-interface/CMEPS/mediator

  • esmFldsExchange_coastal_mod.F90, add SST part

• SCHISM-interface/SCHISM-ESMF/src/schism

  • schism_esmf_util.F90
    • Correct windy2 & dictionary name
    • Change tr_nd to only export surface for the right mapping
  • schism_nuopc_cap.F90
    • Add sst_K for unit conversion and change to only export surface tr_nd.
    • Add iwet_e for the correct ocn_mask

• FV3/atmos_cubed_sphere/tools/fv_diagnostics.F90

  • In subroutine rh_calc, print out “t” before call compute_qs

@uturuncoglu Could you give me any suggestions about how to fix mapping from SCHISM to FV3?
Currently, I follow "esmFldsExchange_hafs_mod.F90" to use mapfillv_bilnr for So_t.
I also try other method, but cause segfault or the same "compute_qs" error messages.

[uturuncoglu]

@danishyo Sorry about late response. Thanks for your attempt to bring fully coupled configuration. At this point I am overbook with other things but I'll look at this. In the mean time if I could reproduce you run in my end that would be great. BTW, maybe it would be nice to move this issue under https://github.com/oceanmodeling/schism-esmf. @janahaddad if you don't mind can you do it?

[danishyo]

Thanks @uturuncoglu
After applying your latest change (point hotfix/ocean_mask branch for SCHISM-ESMF), the previous error are gone and ufs can run without problem (I test it on Frontera).
FV3 and SCHISM now can pass info to each other. Below is the compare plot from FV3.
By the way, I will regularly do RT for schism.

[janahaddad]

@uturuncoglu closing this as done

[uturuncoglu]

@janahaddad I think it would be nice to keep this open since we did not verify it is working and also it needs to be tested regularly. Also this is not defined as RT at this point.

@danishyo If you don't mind could you crate PR for this implementation. You need to create PR in each sub component first and then UFS Coastal level if you have any changes over there. The following information would be helpful for you. BTW, I think this is only one way coupling. Please add detailed information to your PR about the configuration that you use and any other relevant information.

@janahaddad I think it would be nice to add link to our documentation to point following,

https://github.com/ufs-community/ufs-weather-model/wiki/Developer-Information
https://github.com/ufs-community/ufs-weather-model/wiki/Making-code-changes-in-the-UFS-weather-model-and-its-subcomponents

[danishyo]

Thanks @uturuncoglu
I will do the PR and add the info according to the doc link and your suggestion.
By the way, the test is done with 2 way coupling.