Questions about wrf-roms coupling

[zhaolv]

I have recently been using wrf-roms coupling to simulate a typhoon in the South China Sea. However, according to the roms output, the flow field is showing strange vortices in the southern part of the simulation area, this simulation is from 2018-09-15 to 17, the flow field diagram is below, when I try to simulate 13 to 17, the model crashes on 15, again showing a vortex causing high flow velocity.

I would like to know why this is, maybe there is something wrong with my boundary conditions?The boundary conditions in the in file are as follows

Code: Select all

   LBC(isFsur) ==   Gra     Cha     Cha     Gra \       ! free-surface
                    Nes     Nes     Nes     Nes
   LBC(isUbar) ==   Gra     Fla     Fla     Gra \       ! 2D U-momentum
                    Nes     Nes     Nes     Nes
   LBC(isVbar) ==   Gra     Fla     Fla     Gra \       ! 2D V-momentum
                    Nes     Nes     Nes     Nes
   LBC(isUvel) ==   RadNud  RadNud  RadNud  RadNud \    ! 3D U-momentum
                    Nes     Nes     Nes     Nes
   LBC(isVvel) ==   RadNud  RadNud  RadNud  RadNud \    ! 3D V-momentum
                    Nes     Nes     Nes     Nes
   LBC(isMtke) ==   Gra     Gra     Gra     Gra \       ! mixing TKE
                    Nes     Nes     Nes     Nes

   LBC(isTvar) ==   Gra     RadNud  RadNud  Gra \       ! temperature
                    Gra     RadNud  RadNud  Gra \       ! salinity
                    Nes     Nes     Nes     Nes \
                    Nes     Nes     Nes     Nes

! Wec boundary conditions

   LBC(isU2Sd) ==   Gra     Gra     Gra     Gra \       ! 2D U-stokes
                    Nes     Nes     Nes     Nes
   LBC(isV2Sd) ==   Gra     Gra     Gra     Gra \       ! 2D V-stokes
                    Nes     Nes     Nes     Nes
   LBC(isU3Sd) ==   Gra     Gra     Gra     Gra \       ! 3D U-stokes
                    Nes     Nes     Nes     Nes
   LBC(isV3Sd) ==   Gra     Gra     Gra     Gra \       ! 3D V-stokes
                    Nes     Nes     Nes     Nes

This is part of the flow field from day 15 to 17

This is a simulation from 13 to 17, when the model collapses on the 14th, and the flow field is as follows

[jcwarner]

is this the nest or the parent grid?
if this is the nest, are the vortices advected into the nest from the parent?
what do the temp and salt fields look like? you are using radnudge on the south, so what are you nudging to?

[zhaolv]

This is my grid situation, I noticed that the area where the vortex appears is at the junction of the grid, should I change the grid area?
Here are my temperature and salinity fields. Although there are some areas that are rather strange, I don't think they should be the cause of the vortex generation.

2022-05-19 14-46-33 的屏幕截图.png (71.15 KiB) Viewed 82163 times

2022-05-19 14-46-41 的屏幕截图.png (22.01 KiB) Viewed 82163 times

[arango]

These grids are badly designed. I suggest that you run without the nested grids first. You always have to start SIMPLE! Then, you add complexity. Tropical storms are large, so the resolution of the coarser grids is sufficient. WFR would need surface temperature everywhere (land/ocean). If the ROMS grid doesn't provide the SST that WRF needs because of the incongruent grids, you must complement it with data. Nowadays, a third component is added: the DATA model is used to export melded (DATA and ROMS) SST to WRF! By the way, if the ocean and atmosphere grids are not congruent, the atmosphere grid has to be always larger than the ocean grid. Otherwise, you will be forcing the fine-resolution ocean grid with two different resolutions of winds, which may give a horizontal gradient and curl at that open boundary.

[jcwarner]

I think this person is using COAWST. And yes they should add SST to cover non-Roms areas, and they probably are. We have had this option since the beginning of the coupling. What we do is use the SST from the WRFlow file, and replace that with ROMS data wherever the ocean is. We do that for each roms grid, so that coupling can use the high res data from refined meshes. This also works for moving WRF nests, etc.

I am not sure exactly what is going on here. Can you try it with just the parent WRF grid to make sure the WRF nesting is not causing anything strange. I dont think it is.
Are you using COAWST?
if so maybe this thread should get moved to here to avoid confusion from the rutgers roms-wrf coupling
https://github.com/jcwarner-usgs/COAWST/issues

maybe there is an issue with the nesting. can you update to my latest coawst distribution and try that?

I do plan to spend some time to compare what Rutgers ROMS-WRF and my COAWST ROMS-WRF but not there yet.
-j

[zhaolv]

I think this person is using COAWST. And yes they should add SST to cover non-Roms areas, and they probably are. We have had this option since the beginning of the coupling. What we do is use the SST from the WRFlow file, and replace that with ROMS data wherever the ocean is. We do that for each roms grid, so that coupling can use the high res data from refined meshes. This also works for moving WRF nests, etc.

I am not sure exactly what is going on here. Can you try it with just the parent WRF grid to make sure the WRF nesting is not causing anything strange. I dont think it is.
Are you using COAWST?
if so maybe this thread should get moved to here to avoid confusion from the rutgers roms-wrf coupling
https://github.com/jcwarner-usgs/COAWST/issues

maybe there is an issue with the nesting. can you update to my latest coawst distribution and try that?

I do plan to spend some time to compare what Rutgers ROMS-WRF and my COAWST ROMS-WRF but not there yet.
-j

Thank you both for your advice
I have recently adjusted the subgrid of wrf to include the subgrid of roms. I also ran roms alone, without the wrf-roms coupling mode, and the results are still similar.
However, when I tried to draw the free surface (zeta), I found that the free surface on land was strange, the free surface height of the subgrid was smaller than the main grid, I don't know why this is the case, but when I looked at the two grib files, I found that I had set the minimum water depth to 5m and found nothing unusual.
I think this may be the reason for my abnormal flow rate, how can I solve this problem?

[jcwarner]

i am not worried about the free surface, if that is all dry anyway. do you have wet dry on? did you set hmin = 5 in both the parent and child?
is this vortex created at the boundary and advected in?
can you do me a favor, i made a change to my version of nesting.F,
Are you using COAWST? if so please do an update and tell me if you get the answer. looks like you can just run roms.

-j

[zhaolv]

i am not worried about the free surface, if that is all dry anyway. do you have wet dry on? did you set hmin = 5 in both the parent and child?
is this vortex created at the boundary and advected in?
can you do me a favor, i made a change to my version of nesting.F,
Are you using COAWST? if so please do an update and tell me if you get the answer. looks like you can just run roms.

-j

Thank you for your reply
I do have the WET_DRY option turned on, and I use hmin=5 for both the main grid and the subgrid when generating the grid file.
The vortex is created at the junction of the main grid and the subgrid, and is not present at the beginning of the simulation, but as the model runs it gradually creates a vortex, so I think it may be caused by some problem with the grid.
I am using coawst and using the method in Manual to generate the predecessor file, I will update coawst and try to run it again and hopefully the results will be better.

[zhaolv]

i am not worried about the free surface, if that is all dry anyway. do you have wet dry on? did you set hmin = 5 in both the parent and child?
is this vortex created at the boundary and advected in?
can you do me a favor, i made a change to my version of nesting.F,
Are you using COAWST? if so please do an update and tell me if you get the answer. looks like you can just run roms.

-j

Hi, I recently re-uploaded your latest version of coawst from githut and it compiled and ran successfully.
There is no significant change in the result without changing the configuration of my previous roms, but I still get a strong vortex. What is wrong with this?

[arango]

We recommended running without nesting, but still, you haven't reported that solution. Unfortunately, there is not much help that we can give you if the suggestions are not followed.

[zhaolv]

We recommended running without nesting, but still, you haven't reported that solution. Unfortunately, there is not much help that we can give you if the suggestions are not followed.

I'm sorry I didn't take note of your suggestion before, but I recently re-ran the coupled model without nesting and it made a big difference.
I have removed the nested grid from the roms and the range of the wrf model remains largely unchanged. The simulation period is still 13 September to 17 September. The results show that the strange vortex disappears when the roms nested grid is not used.
I guess it might be due to some problem with the boundary conditions of the generated subgrid? But I am using the method recommended in the coawst user manual. I'm wondering if you know what the cause is and I'm hoping you can give me some advice.

The simulation area and results are shown below.

roms_mangkhut_1.in

(152.31 KiB) Downloaded 1568 times

[attachment=1]2018-09-15 06-00.png[/attachment

[jcwarner]

looks like the only differences for roms is along the southern boundary.
with nesting, does the vortex start and grow, is it formed during the experiment at the boundary and advect in?
does the child bathy match the parent?
i assume this probably gets deep along that child southern boundary.
-j

[zhaolv]

looks like the only differences for roms is along the southern boundary.
with nesting, does the vortex start and grow, is it formed during the experiment at the boundary and advect in?
does the child bathy match the parent?
i assume this probably gets deep along that child southern boundary.
-j

Yes, in the nested case, the vortices appear gradually over time and only on the southern boundary of the sub-grid and become progressively stronger over time. I have a ratio of 1:3 between the sub-grid and the main grid, which should match.
Below are flow field diagrams for the single-layer grid and the nested mode respectively. I think the error may be in the grid or the primary boundary file, I wonder if you could try this for me and I will attach my grid file.

[jcwarner]

I looked at the grids and they seem ok. the bathy matches well.
the dmde looks large in the parent grid. are you running with curvgrid on?
also the parent has spherical ='T' and the child has spherical = 1. this is probably not an issue.
how did you set the init conditions? are the T/S fields consistent?
if you can put the ini frc and *.h somewhere, i can take a look at this.

-j

[arango]

I mentioned before that your WRF nested grid is ill-conceived. It is inside of ROMS grid. It would be best to think about physics here and what the nesting is doing. You have a solid tropical storm covering the entire area, and there is a horizontal gradient of the wind due to coarse and fine resolution WRF grids. This gradient in the wind, in turn, creates a curl in the wind stress, and then you get vortices in the ocean around the boundaries of the WRF nested grids. It is oceanography 101!

The radius of deformation in the atmosphere is thousands of kilometers, so your coarse grid resolves the tropical cyclone very well. This kind of atmospheric nesting will be appropriate for a tornado, much lower scale, but they are mostly overland.

[zhaolv]

I looked at the grids and they seem ok. the bathy matches well.
the dmde looks large in the parent grid. are you running with curvgrid on?
also the parent has spherical ='T' and the child has spherical = 1. this is probably not an issue.
how did you set the init conditions? are the T/S fields consistent?
if you can put the ini frc and *.h somewhere, i can take a look at this.

-j

I am using the method in the coawst manual directly to generate files such as meshes and initial boundaries. curvgrid is another method? I don't think I have used curvgrid before.
I have placed my ini, bry etc files in the appendix and would appreciate any guidance you can give me.

In response to Mr. arango's question, I have previously modified the roms and wrf child grids so that the wrf child grid area is larger than the roms child grid. The range is shown below.
I have nested the wrf model in the hope of verifying the accuracy of the simulated wind speed. I will then try to remove the nested model from wrf and simulate it again using a single layer grid. Hopefully the results will change.

[arango]

Nested grids resolve smaller scale physics that may or may not be associated with your wind accuracy in the open ocean. For example, high-resolution winds are required next to mountainous coastal areas to resolve thermal fronts, convention, and other physics. In addition, small-scale phenomena like coastal sea breeze are affected by the resolution of the atmosphere, land, and vegetation models. At this latitude, the Rosby radius of deformation is between 80-100 km for the ocean and around 1000 km for synoptic scales (cyclones) in the atmosphere. I think that your coarse grids are resolving those scales. It is not a matter of accuracy but how well you can represent the atmosphere/ocean dynamics of interest in your discrete grids. A nested grid changes the solution because you add additional physics at smaller scales. You cannot put nested grids everywhere because you have such capability, The first thing that you need to ask is what kind of dynamics you want to study and make the decision on your discrete resolution. I don't know if there is some type of leakage from WRF nested grids, you need to plot and overlay the WRF solutions and compute quantities like vorticity. If you have a leakage, you need to ask the WRF community for advice. If you need smaller scale winds, decrease the resolution of the WRF coarse grid. I bet that it will be cheaper than having WRF nested grids.

[jcwarner]

ok i spent some time on this. I think the issue is a bathy mismatch between the child and the parent, especially near the boundary.
At the location of that vortex, the child grid has a bathymetric rise, but the parent grid did not see it. So i recommend that you use average child bathy to replace the parent (where the child is located). i did something quick, you may want to do some thing better, but this seemed to help a lot.
please let us know if this works for you.

this creates a new parent grid, copies the avg child bathy into the new parent grid, and then new contact file.
matlab code:

netcdf_load('Mangkhut_roms_grid_ref3.nc')
lonc=lon_rho;
latc=lat_rho;
hc=h;
netcdf_load('Mangkhut_roms_grid.nc')
lonp=lon_rho;
latp=lat_rho;
hp=h;
%
%make a new h for parent in the region of the child
hpnew=griddata(lonc,latc,hc,lonp,latp); %maybe use a fancier interp here
%make a mask for combining data
maskh=ones(size(h));
maskh(isnan(hpnew))=0;
hpnew(isnan(hpnew))=0;
%
hpnew2=hpnew.*(maskh)+hp.*(1-maskh); %replace child avg into parent h
figure
pcolorjw(lonp,latp,hpnew2);colorbar
colormap('jet')

figure
pcolorjw(lonp,latp,hpnew2-hp);colorbar
colormap('jet')

!copy Mangkhut_roms_grid.nc Mangkhut_roms_grid2.nc
ncwrite('Mangkhut_roms_grid2.nc','h',hpnew2)

Gnames={'Mangkhut_roms_grid2.nc','Mangkhut_roms_grid_ref3.nc'}
[S,G]=contact(Gnames,'Mangkhut_contact_jcw2.nc')

[zhaolv]

ok i spent some time on this. I think the issue is a bathy mismatch between the child and the parent, especially near the boundary.
At the location of that vortex, the child grid has a bathymetric rise, but the parent grid did not see it. So i recommend that you use average child bathy to replace the parent (where the child is located). i did something quick, you may want to do some thing better, but this seemed to help a lot.
please let us know if this works for you.

this creates a new parent grid, copies the avg child bathy into the new parent grid, and then new contact file.
matlab code:

netcdf_load('Mangkhut_roms_grid_ref3.nc')
lonc=lon_rho;
latc=lat_rho;
hc=h;
netcdf_load('Mangkhut_roms_grid.nc')
lonp=lon_rho;
latp=lat_rho;
hp=h;
%
%make a new h for parent in the region of the child
hpnew=griddata(lonc,latc,hc,lonp,latp); %maybe use a fancier interp here
%make a mask for combining data
maskh=ones(size(h));
maskh(isnan(hpnew))=0;
hpnew(isnan(hpnew))=0;
%
hpnew2=hpnew.*(maskh)+hp.*(1-maskh); %replace child avg into parent h
figure
pcolorjw(lonp,latp,hpnew2);colorbar
colormap('jet')

figure
pcolorjw(lonp,latp,hpnew2-hp);colorbar
colormap('jet')

!copy Mangkhut_roms_grid.nc Mangkhut_roms_grid2.nc
ncwrite('Mangkhut_roms_grid2.nc','h',hpnew2)

Gnames={'Mangkhut_roms_grid2.nc','Mangkhut_roms_grid_ref3.nc'}
[S,G]=contact(Gnames,'Mangkhut_contact_jcw2.nc')

I apologize, I used the matlab file you provided to generate a new master mesh file and connection file, and used this file to generate new ini, bdy and clm files and a "forcing" file. However, when I ran it with these files, the model crashed at 58 minutes and I checked the "rst" file and the results were bad. I have placed the new ini etc files below.

Code: Select all

 DIAG speed trouble    20.421145012876391     
 DIAG speed ijk    20.661675608459674              142           2          16           2
 Found Error: 01   Line: 341      Source: ROMS/Nonlinear/main3d.F
 Found Error: 01   Line: 331      Source: ROMS/Drivers/nl_ocean.h, ROMS_run

 Blowing-up: Saving latest model state into  RESTART file
     REASON: MaxSpeed =  2.0E+01

      WRT_RST     - wrote re-start    fields (Index=1,1) in record = 2                     01

 Blowing-up: Saving latest model state into  RESTART file
     REASON: MaxSpeed =  2.0E+01

      WRT_RST     - wrote re-start    fields (Index=1,1) in record = 2   

Also I would like to know how you generate the ini, clm files for the sub-grid, I am using this code below and I am not sure if this will have an effect.
I will make other attempts to see what exactly is going wrong.

Code: Select all

create_roms_child_init( 'Mangkhut_roms_grid2.nc', 'Mangkhut_roms_grid_ref3.nc','Mangkhut_ini.nc','Mangkhut_ini_ref3.nc');
create_roms_child_clm( 'Mangkhut_roms_grid2.nc', 'Mangkhut_roms_grid_ref3.nc','Mangkhut_clm.nc', 'Mangkhut_clm_ref3.nc');

[zhaolv]

I have good news. Based on the master mesh file generated from the matlab file you provided, I created the initial boundary file. Afterwards I applied it to the coupled model of WRF-ROMS and the model can now be run successfully and the results are more than satisfactory! I have placed the results at the end.
As for yesterday's news, I originally used the uncoupled ROMS model and it ran with errors. But I have no problems with the coupled model today, so I think there may be a problem with the Forcing file for the uncoupled model and I will try running it again.
Your method is very useful, thank you very much!

[jcwarner]

glad it is working for you!
-j