ROMS-WRF running errors

[bwendu]

Hi, when I run a test case with ROMS and WRF, I met some problems, maybe I need some suggestions, my problems are as follow.

1. I run WRF with FNL data and ERA5-SST data, I used Vtable.ECMWF to ungrib ERA5-SST data. Actually, I'm not sure which one to choose is correct between Vtable.SST and Vtable.ECMWF
2. My grid settings are 2 for WRF and 1 for ROMS, but my WRF child grid doesn't cover all ROMS grid area. I'm wondering WRF how to receive SST(roms2wrf) from ROMS where no ROMS grid. My understanding is that when sst_update=0, it is obtained from the sst that remains unchanged in the initial field of wrf. If sst_update=1, these areas without ROMS grids are read from the provided wrflowip file for the changed sst. I don't know if this is the case.
3. Could I set different start time for wrf and roms, if ROMS needs to start before WRF to spin up a period of time?
4. My domain is China's coastal ocean, and my settings of the parameterization scheme of WRF are same as Sandy. I don't know if they're suitable.
5. When I set different coupling times, the running time of the model also varies (the same error density blow up will occur in the end). I checked the wrfout (the SST field in wrfout always has a very obvious shape of the ocean grid boundary, and the wrfout_sst.png in the attachment is a common SST distribution field) and the ocean history files separately, which are caused by overflow due to high temperature. Previously, I ran wrf at the same period of the duplicate case separately without any error messages. After coupling, it seems that the shorter the coupling time, the longer the run time can be. Therefore, I am confused whether coupling in my case makes the calculation results better or worse.
6. Should the namelist. input used in running real.exe and coawstM in wrf remain the same, as real.exe and wrf.exe in wrf are in the same directory, while in coawst they are in different locations. What modifications need to be made in namelist.input by running real.exe again to create the bry and input files? I have modified some parameters in &physics, but I am not sure if it is necessary to run real.exe again.

Below are my .h, ocean.in, namelist.input files and abnormal sst in wrfout and history.
Really thank you for any help.

coupling.in.txt
ocean.in.txt
test.h.txt
namelist.input.txt

[jcwarner-usgs]

here are some suggestions.

1. I am not sure the best vtable. that would probably be a good question for the WRF git site.

2. yes. if you set sst update =0, then wrf will not update the sst and it will stay the same. for roms coupling, you should set sst update = 1, and then wrf will update the sst from both the wrflow file and the roms grid. SST from the roms grid will overwrite the sst from the wrflow file. you can look at the wrf out file and you should see the sst changing, and it should be what is in roms. just change the units from K to C.

3. the way i have the coupling, all models are expected to start at the same time, and end at the same time.
   you could run one of the models for a bit, then save a rst file.

4. i am not sure how well the Sandy settings are for anywhere else. that is something you need to work with and try other options.

5. i am not sure/clear what is going on here. All the models need to start at the same time. The coupling interval needs to divide evenly into the model time steps. for example:
   coupling interval = 600s, ocean dt = 60 s, wrf dt = 20 sec = GOOD
   coupling interval = 600s, ocean dt = 90 s, wrf dt = 20 sec = BAD , ocean dt 90 does not go into 600 evenly.
   do you see what i mean?
   I have not had much luck with

define TS_SMAGORINSKY

define UV_SMAGORINSKY

that could be a problem, but i know others who use those options.
I am not sure what the color scale is for the wrf temp. Does roms have a problem or does wrf?

6. coawstM looks for input in the same folder as coawstM.
   If you are asking about when to rerun real, that is better to ask on the wrf forum.
   Some people have a folder with COAWST, and just #define WRF_MODEL, and compile that.
   then you can always go to that folder and run real or any wrf utility.
   Then in a separate folder with COAWST, you can have the application compiled and that way you dont need to worry about recompiling the code.

[bwendu]

Really thank for your timely reply, I got all your suggestions and i'm trying to make some adjustments to my test case. as you mentioned, my sst in wrf and roms are same and both unrealistic high, but those abnormal high values occur in ocean area, especially in coastal region and roms grid's open boundry. as for settings on coupling time, i got what you explained and I have always done so. the suggestion to create a new coawst folder to avoid recompiling wrf is really great and helpful. | | Du_bw | | ***@***.*** | ---- Replied Message ---- | From | john ***@***.***> | | Date | 4/25/2024 01:13 | | To | ***@***.***> | | Cc | ***@***.***> , ***@***.***> | | Subject | Re: [DOI-USGS/COAWST] ROMS-WRF running errors (Issue #249) | here are some suggestions. I am not sure the best vtable. that would probably be a good question for the WRF git site. yes. if you set sst update =0, then wrf will not update the sst and it will stay the same. for roms coupling, you should set sst update = 1, and then wrf will update the sst from both the wrflow file and the roms grid. SST from the roms grid will overwrite the sst from the wrflow file. you can look at the wrf out file and you should see the sst changing, and it should be what is in roms. just change the units from K to C. the way i have the coupling, all models are expected to start at the same time, and end at the same time. you could run one of the models for a bit, then save a rst file. i am not sure how well the Sandy settings are for anywhere else. that is something you need to work with and try other options. i am not sure/clear what is going on here. All the models need to start at the same time. The coupling interval needs to divide evenly into the model time steps. for example: coupling interval = 600s, ocean dt = 60 s, wrf dt = 20 sec = GOOD coupling interval = 600s, ocean dt = 90 s, wrf dt = 20 sec = BAD , ocean dt 90 does not go into 600 evenly. do you see what i mean? I have not had much luck with define TS_SMAGORINSKY define UV_SMAGORINSKY that could be a problem, but i know others who use those options. I am not sure what the color scale is for the wrf temp. Does roms have a problem or does wrf? coawstM looks for input in the same folder as coawstM. If you are asking about when to rerun real, that is better to ask on the wrf forum. Some people have a folder with COAWST, and just #define WRF_MODEL, and compile that. then you can always go to that folder and run real or any wrf utility. Then in a separate folder with COAWST, you can have the application compiled and that way you dont need to worry about recompiling the code. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>