search

DOI-USGS / COAWST

COAWST modeling system git repository
Other
105 stars 49 forks source link

ROMS_SWAN (4nest) forecast water level is much higher than actual values, any methods to fine tune #324

Open IvanPris opened 2 weeks ago

IvanPris commented 2 weeks ago

I have tried to run ROMS_SWAN 4nest (one way coupled with nesting of 4 domains) However, the forecast water level is much higher than the actual values recorded (please see the image below, the black line is the actual value, blue line is the forecast value from ROMS_SWAN 4 nest) image

May I know are there any ways to "tune" this, thank you very much

Please see the attachments below for my input files: https://github.com/user-attachments/files/17093646/ocean.in.3.txt https://github.com/user-attachments/files/17093647/sandy_ivan.h.2.txt log (2).txt

IvanPris commented 1 week ago

Just some remarks:

I will be grateful if anyone could share their views on this matter if they have encountered this issue before

Thanks a lot!

jcwarner-usgs commented 1 week ago

i think you should work on the two way nesting, to understand why it is blowing up. Does it blowup with just ROMS, or was it blowing up when coupled? If it is blowing up with just ROMS, then you can post a message on the roms forum.

IvanPris commented 1 week ago

@jcwarner-usgs I am very sorry for my late reply.

Actually, i have conducted quite some testing regarding this matter (which i have posted in the forum here before: https://github.com/DOI-USGS/COAWST/issues/320). (sorry it is quite long, i am going to do a bit summary:)

Summary of the findings:

My ROMS_SWAN (4 nest): I have 4 nested domains in my project with ROMS coupled to SWAN

  1. The u and v values in some spots (all along the boundary of the second largest grid ) keep increasing/decreasing, leading to blow-up eventually (with zeta values also keep in/decreasing). One thing to note is that those spots also appear in their corresponding parent coarser grid (that is the largest grid). I have tried to smoothen the bathymetry, add sponge layers in the boundaries and tried to mask those spots but all blow-up still occurs eventually.

image (This is one of the snapshots of my second-largest domain. As you can see, there is a "red spot" near the boundary, actually there are also other "potential" points emerging in the upper edge. All of these spots share similarities: they are located near the boundary.)

  1. When i separately run the ROMS and SWAN models, they run smoothly without blow-up. However, when i coupled them, it results in blow-up in those points above.

  2. I found that when i #define ONE_WAY (one way nesting) in sandy.h and then recompile to run again, surprisingly, it successful runs without blow-up. However, the water level (zeta values) forecasted are too high (almost one meter higher than the actual values, black line is the actual values and blue line is the model output in the diagram below) image. I have done quite some research online. It appears that one way nesting fails to make accurate forecasts on the water level when compared to two way nesting (https://www.myroms.org/forum/viewtopic.php?t=6233#:~:text=The%20water%20level%20calculation%20is%20wrong%20for%20one-way%20nesting). Therefore, i tried to find more about 2-way nesting and read another forum (https://www.myroms.org/forum/viewtopic.php?t=5732#:~:text=I%20have%20done%20two%20experiments%20using%20one-way%20and%20two-way). It appears that problem lies in the feedback of information from the child grid to the parent grid (the extra step that is unique to two-way nesting). I noticed that this issue has already been resolved by John Warner after revising the treatment of fine-to-coarse information exchange in nesting.F (https://www.myroms.org/projects/src/ticket/887). Therefore, i tried to update my ROMS/Nonlinear/nesting.F with the new version (as my original nesting.F code is the 2020 version). However, the blow-up s till occurs.

Again, sorry for my long passage above, i would like to ask a question:

A. May I know if one-way nesting fails to make accurate forecast in water level (when compared with two-way nesting) so that my one-way nesting ROMS_SWAN 4nest forecasted water level is much higher than actual values? If that is the case, are there any other methods to "tune" it so that the water levels predicted are more accurate? If there isn't way to do this tuning, does it mean that i have to use two-way nesting instead? However, i still fail to cope with the blow-up issue in the two-way nesting case.

Thank you very much for spending time to read my lengthy passage. I would be grateful if anyone could give me some hints or guidance.

Please see the attachments below for my input files: https://github.com/user-attachments/files/17093646/ocean.in.3.txt https://github.com/user-attachments/files/17093647/sandy_ivan.h.2.txt log (2).txt