Water Level for One-Way Nesting is Wrong but Two-Way Nesting Works

[yuchengzhang]

Hello everyone,
I'm constructing a nested model for Florida Bay area. The water level calculation is wrong for one-way nesting, but two-way nesting doesn't have the problem. The only thing I changed was the cpp option.

Here are plots of daily average water level for one-way nesting:

day 1:

day 14:

day 30:

day 30 plot for two way nesting:

It's weird that ubar and vbar calculations are correct for one-way nesting, the vbar plots are attached below:
day 1:

day 14:

day 30:

Could anyone provide me with any ideas what might be causing this? Thanks in advance.

The header files, input file, and output log for the one-way nesting model are attached below:

floridabay.in

(178.24 KiB) Downloaded 300 times

fb_nest.h

(2.11 KiB) Downloaded 298 times

FB_6.log

(58.08 MiB) Downloaded 429 times

[arango]

Yes, this makes a lot of sense to me. In such an active region, the nesting should always be two-way! The issue is that the finer, high-resolution nested grid resolves the smaller-scale processes, and there is no feedback from fine-to-coarse, so the two coarser and finer grid solutions are diverging. The coarse grid imposes boundary fluxes that don't have the memory of the finer grid solution.

You need to think more about it and understand the dynamics between one- and two-way nesting strategies.

[philip]

I am a ROMS beginner but have experience with other models and I agree about needing two-way coupling with such a grid. I think the main problem is the corner of the one-way model in the Gulf Stream. Keep in mind the subgrid (child) has only the information given to it in the BCs and responds the the large water level gradient with its own internal dynamics, likely spreading erroneously high waters into the subgrid.

If you wanted to have a one-way coupled model, it would need to be angled or otherwise altered to never include the Gulf Stream. But I expect it is always better tonuse two-way coupled model.

But here’s one other thought — Does anyone feel the two-way model could be improved if the grid avoided including a corner in the GS? It seems like potentially a bad idea to have a corner there. Just a hunch….

[arango]

Indeed, how you design your nested grid application and locate the telescoping domains is essential. That's where experience comes to play a role in successful nested applications. We want a smooth transition of bathymetry and dynamics. For example, a canyon or a significant ocean current a the boundary of a nested grid should be avoided. The same rules of regional single-grid modeling apply to nesting.

[yuchengzhang]

Thanks arango and philip for the reply and I hope everyone here had a happy Christmas and New Year. I apologize for the late response, I was on a break last week.

My background is in applied math (numerical pdes and math modeling) and I'm relatively new to ocean modeling. I'm ignorant on some of the concepts in the ocean modeling community so I might ask somethings here that are very obvious to you guys, but answering them would help me a great deal,

1. I understand that for the one-way nesting, the two models (coarse and fine) will diverge. Shouldn't the divergence start inside the domain because of different masking, refined resolution, etc? I don't understand why my model starts to diverge on the boundary (as philip said, bot right GS corner behaved the worst) since we are using interpolations from the parent for the contact points. Maybe I misunderstood how nesting work, is the parent imposing fluxes on the child, and the fluxes are calculated only based on the parent without the consideration of the child boundary points?

2. Why ubar and vbar behaved a lot better than zeta for my one-way nesting model?

3. About the bot right corner being in the GS, it seems hard to find the ideal child domain ('smooth transition of bathymetry and dynamics' as mentioned by arango) if I want to include Florida Bay and Florida Keys, there are always some give and take. Based on your suggestions, I think a child domain with curvilinear coordinate transformation that follows the Florida Keys/Gulf Stream would worth a try. I'm validating the current two-way nesting model, it's an improvement when compared to the non-nested parent only model based on my current results. I might redesign the child domain later and compare the results. Please let me know if you have any other advice on this.

4. What do you think is the best way for me to learn ROMS and the relevant ocean modeling ideas? I read most of the WikiROMS and the ROMS Mannual, but they don't explain the intricacies. For example, I don't fully understand the idea of mode-splitting. I'm reading Shchepetkin and McWilliams (2005), I'm also reading the ROMS code after compilation in my model's build folder.

Thank you.

[wilkin]

Is the bathymetry continuous at the nest perimeter? If not, it's not possible to match velocity ubar,vbar with transport ubar*h,vbar*h and volume will not be conserved. Two-way nesting compensates for this by establishing a pressure gradient that will drive flow into the nest to rebalance the sea level.

[philip]

I noticed there is another modeler from several years ago with questions on nesting Florida Bay and having a grid boundary in the Florida Current. You might reach out to them about what their experience was and solutions -- viewtopic.php?t=3215

For the experts: Zhang mentioned creating a curvilinear grid, presumably implying it would bend to fit the Keys. I'm curious whether you can create a curved child grid of Florida Bay in this situation or whether the curvature would be too large to have accurate results (I don't understand the numerics and what limits there are on curvature). It would obviously be nice to have the child grid meet the parent in the (curving) area of constant depth water just south of the Keys.

[yuchengzhang]

Thanks John. I think that is the problem, the volume is not conserved on the bot right boundary. I averaged h for the child grid file, and subtracted the parent h on the child domain. The plot shows the differences

I will fix the bathymetry and see if one-way nesting works.

Thanks Phillip for the link, I will reach out.