blowing up due to NaN when coupling ROMS-WRF

[almacarolina]

Hi all, I have been able to successfully run individually a WRF and a ROMS simulation in the NW Atlantic. When I want to run the coupled version with those two models I get the following error.

WRF grid 1 sent data to ROMS grid 1

    30 2004-01-01 12:30:00.00           NaN           NaN           NaN           NaN
                (1210,264,40)  6.549011E-03  5.357524E-03  5.398450E-02  9.201387E-01

Found Error: 01 Line: 345 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: KEchar = NaN, PEchar = NaN

If I understand correctly there are some NaN values being sent to the ROMS grid that blow up the ocean model. I am not really sure what this means since are no Nan Files on my files and the WRF and ROMS simulations don't produce errors when run by themselves. Any advice on how to debug the problem appreciated. nes_couple.log

Thanks and I attach my full log file. Alma

[jcwarner-usgs]

not sure. you will have to look at the rst file, see if the sustr or svstr is high for some reason, and see what is going on. look over near ijk 1210 264 40 ( i assume 40 is the top layer).

[almacarolina]

Hi John, Thank you for your quick response. Sustr and svstr seem to have normal values in the ROMS file but the wrfoutfile has all 0 in the fluxes. The model was blowing up at the point where the Gulf Stream was strong. See attached image (top star). I did a first test where I changed the initial condition in ROMS o have u and v as zero but it is still blowing up at the bottom boundary where the Gulf Stream is entering the domain (bottom star in image). I have a suspicion my grids are not ideal. See the image below where the blue square shows the WRF grid limits and the red square shows the ROMS grid limits. I did this so I did not have to add SST from another product in areas where there is WRF and no ROMS. Let me know if you think these grids are not ideal.

[jcwarner-usgs]

ok. 1 thing at a time. i would suggest to not start roms with u=v=0 and then have the gulf stream push into the domain. that would be bad go back to having the roms with a real init and lets just try to figure out why roms blow up at top green star. when you ran roms by itself, did it work ok? so the only diff is now wrf is giving surf heat and momentum fluxes?

[almacarolina]

Ok. Yes, roms by itself works correct. So the only difference is wrf giving surf, heat, and momentum fluxes. Thanks .

[jcwarner-usgs]

are you using the same roms dt? can you save the his every 5 steps and see what happens?

[almacarolina]

Yes, I am using the same ROMS time step I was using before (dt=60s). I save the his file every 5 steps and indeed I found really bad values before it blows up at 15 min. I believe it could be related to my terrible choice of grids. Let me know what you think.

[jcwarner-usgs]

it looks like roms is not happy along the open boundaries. it is creating an offset in zeta that is propagating into the domain. I would think that along the roms boundary where there is no wrf, the surface heat fluxes or wind stresses would be 0. can you see what the sustr and svstr are? are you using atn2ocn_fluxes?

[almacarolina]

Yes, I am using atn2ocn_fluxes.

At the boundary where there is no wrf the wind stresses are 0 but shflux is ~-400 (even at t=0). I should point out that in the wrfout the heatfluxes are 0 everywhere.

And these are my cpp options regarding surface forcing define ATM2OCN_FLUXES
undef BULK_FLUXES define SOLAR_SOURCE
define EMINUSP

define ATM_PRESS

[jcwarner-usgs]

well the problem is that ROMS needs information at those bounding cells. The fact that the Patm is probably 0 at the perimeter, and then 1020 (or whatever) at 1 grid cell in, is creating a large pressure gradient that is driving a flow, that is probably why zeta comes in with a mini tsunami.

-There are ways for roms to have data from a netcdf file and also from the coupling, but i have not tried it. -I know that we can have wrf get data from wrflow file and get data from roms, and combine them both. So if the wrf grid was larger that would work. We distribute the Sandy case to work that way. But you have roms grid larger, and i have not tried that. How hard is it for you to make the wrf grid larger than roms? and go thru those steps to get sst data to wrf? i know that works. -or make both grids the same coverage over the ocn. the wrf grid can extend further west over land, roms will not care.
those are some of the options i can think of right now.

[almacarolina]

Hi John. It is not a problem to have a wrf grid larger than roms. I just thought that at the bounding cells where SST is provided by another product and SST is provided by ROMS some weird things could also happen. I think the best is to have both grids, have the same coverage as the ocean but, because I created, (probably not a great idea), first the ocn grid, it was hard to make a WRF grid exactly like the ocean just using the namelist.wps. Do you have any suggestions on how to make a WRF grid from the ROMS grid, maybe there is already a code somewhere so I will look for it in the forums too.

Thanks a lot! Really useful discussion.

[jcwarner-usgs]

we distribute Tools/mfiles/mtools/wrf2roms_mw.m

function wrf2roms_mw(theWRFFile, theROMSFile) you can modify that to just pick a subset of the wrf grid and not use the entire XLONG and XLAT. just pick XLONG(istart:iend,jstr:jend) and XLAT of the same.

[almacarolina]

Great! Thanks!

[almacarolina]

My coupled simulation is working now! Thanks again John.