search

oceanmodeling / schism-esmf

Earth System Modeling Framework cap for SCHISM
0 stars 0 forks source link

FV3 + SCHISM #1

Open danishyo opened 6 months ago

danishyo commented 6 months ago

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 commented 5 months ago

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.

wind_import

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. image Print out input “t” before compute_qs, and a large value do exist in the array. image

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

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

@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 commented 5 months ago

@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 commented 5 months ago

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.

image

janahaddad commented 4 months ago

@uturuncoglu closing this as done

uturuncoglu commented 4 months ago

@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 commented 4 months ago

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.