Best practices for ROMS bathymetric values

[lcbernardo]

Dear all,

I'm now investigating some frequent blowing up in a model I've been running. It used to work without too much difficulty before, but after activating ALBEDO_CLOUD, for some reason it ends up blowing up after a few simulation days. Investigating the log file hasn't been helpful as the last values that appear at the point of the blowup are all NANs. I've tried some of the usual ways to solve this, such as decreasing my time step using DT and NDTFAST. The last settings I tried were DT=10, and NTDFAST=40, which I think are already more than enough as I am using a relatively coarse 1.5 km grid resolution.

And this has led me to look more closely at the bathymetry to check for any issues. I remember reading in this forum a while back that even values masked as land should have some relatively reasonable values, but in my grids, cells masked as land have been set to -100 to clearly differentiate them from non-masked cells. I'd just like to know if this might lead to any problems which can cause the model to blowup, and what the best practice would be for values in cells masked as land. I'd also like to mention that I am using the ROMS version which is part of the COAWST modelling system, and that in my models, WET_DRY is activated. Any help and advice would be appreciated.

Thanks,
Lawrence

[kate]

Are all those depths of -100 always dry? Fully masked? Then they shouldn't be causing any trouble.

If it all behaved before you used ALBEDO_CLOUD, maybe you should check that out. I tend not to use it and it might have bugs. Have you looked at your surface fluxes, before and after the change?

[lcbernardo]

Thanks for the reply Kate. I think they are indeed always dry, so I guess that the -100 values are most likely unrelated to the blowup.

Actually, ALBEDO_CLOUD did have bugs, relating to fortran syntax. I reported it to Dr. Warner through email, and also was able to fix it. And the fix seemed to work as it improved the temperature reconstruction in some of my other modelling runs, and also the runs of some of my work colleagues. It just wouldn't work for this one particular modelling setup, which led me to think that bathymetry may be related to the issue. But as you suggested, I guess it would help to check the surface fluxes.

I've also attached my log file, in case I missed some important detail that more experienced users may be able to point out.

CRSE1_CWST2019St6.log

(1012.23 KiB) Downloaded 321 times

[kate]

Really, you should be looking at the fields as it goes bad. Now that you know it goes bad quickly, I would set ninfo to one to catch it going bad ASAP.

Also, did you mean to have ANA_SSFLUX? Bulk_flux should provide salt fluxes based on precipitation.

[nacholibre]

Lawrence, I would change the -100 m value on the masked cells to make sure they don't contribute to the a problem. This may not be the source of your blow-up issue, but it is also not the best practice in my opinion. Values in dry cells shouldn't be a concern, but...
Because of the way that ROMS solution technique works, the land boundary is implemented by setting values to zero after every time step. For example no-flux condition at the dry cell face is fulfilled by setting velocity to zero. However, masked values can be used for calculating horizontal diffusion terms at the neighboring wet cells. This is corrected by setting first derivative of the surface elevation at the dry cell boundary to zero, but that is after the fact that some error has been introduced. The magnitude of this error depends on the difference between the bathymetry of two neighboring cells, and in your case it is likely to be much larger than what it would be for a smoothed bathymetry.
Kate, please correct me if my thinking is flawed...
Zafer

[kate]

I don't think those points that are MASKED should cause trouble. I know wet-dry points are very problematic in say coastal fjords with one point at -1 m and the next point at 30 m depth. This is in the same domain with tidal flats with a much more gradual bottom depth. It's all about resolving the features that need resolving. But again, unless you watch what is going bad in *your* domain, how can we help?

[hpd14thu]

You don't mention the point or the place model blows up, maybe it helps.

And if you activate WET_DRY. If -100m palce always be dry, or sometimes be wet?

[lcbernardo]

Dear Kate, Zafer, and hpd14thu,

Thank you for your additional suggestions and my apologies for the delayed response. I went into the New Year vacation and then had to work on something else these past two weeks. Anyway, going back to this issue...

After checking more closely, I found that the blowup occurred at a time very close to when a typhoon passed my study area. In my initial simulation, the blowup occurred just a few days after my start time, during which the approaching typhoon already seemed to be influencing the conditions in my domain. I then adjusted the start time and set it back 5 days prior to what I initially set, and the model ran for a longer period, but blew up at pretty much the same time as my initial simulation. I think I remember reading in some old posts that this may be an expected result, and that perhaps decreasing the time step is the most straightforward solution. But I can only decrease the time step so much so as not to put a strain on computational resources.

As I mentioned, this blowup occurred after activating ALBEDO_CLOUD in the header file. I'm now trying to check if conditions related to the typhoon passage are somehow causing problems in the activated functions.

Lawrence

[lcbernardo]

After checking more closely, I found that the blowup occurred at a time very close to when a typhoon passed my study area. In my initial simulation, the blowup occurred just a few days after my start time, during which the approaching typhoon already seemed to be influencing the conditions in my domain. I then adjusted the start time and set it back 5 days prior to what I initially set, and the model ran for a longer period, but blew up at pretty much the same time as my initial simulation. I think I remember reading in some old posts that this may be an expected result, and that perhaps decreasing the time step is the most straightforward solution. But I can only decrease the time step so much so as not to put a strain on computational resources.

I apologize as I have confirmed I was mistaken. It was my initial impression that a typhoon was passing close to my domain at the time of the blowup as I was looking at the wind data in my met files, but typhoon databases do not support this. Rather, the blowup seemed to occur at a time of abruptly transitioning winds. But then again, maybe I'm reading too much into it in trying to explain the blowup as the wind speeds involved aren't really that large. I have to dig in deeper.

[hpd14thu]

After checking more closely, I found that the blowup occurred at a time very close to when a typhoon passed my study area. In my initial simulation, the blowup occurred just a few days after my start time, during which the approaching typhoon already seemed to be influencing the conditions in my domain. I then adjusted the start time and set it back 5 days prior to what I initially set, and the model ran for a longer period, but blew up at pretty much the same time as my initial simulation. I think I remember reading in some old posts that this may be an expected result, and that perhaps decreasing the time step is the most straightforward solution. But I can only decrease the time step so much so as not to put a strain on computational resources.

I apologize as I have confirmed I was mistaken. It was my initial impression that a typhoon was passing close to my domain at the time of the blowup as I was looking at the wind data in my met files, but typhoon databases do not support this. Rather, the blowup seemed to occur at a time of abruptly transitioning winds. But then again, maybe I'm reading too much into it in trying to explain the blowup as the wind speeds involved aren't really that large. I have to dig in deeper.

I remember that ROMS have some problems when dealing with wind large than 30 m/s, you can read the bulk_flux.F code and change the coeffidence of wind to stress.

[lcbernardo]

I have somehow "resolved" my blowing up problem, but since I still haven't fully confirmed the main cause, I will continue to look into it. But to properly close this topic, I'd like to share what did and didn't work.

Firstly, I attempted to decrease the time step DT and NTDFAST to the recommended levels. My model has an approximately 1.5 km grid cell size, and ended up going as far as setting DT=10 and NTDFAST=40, but the model continued to blow up at the same point.

Secondly, following the theme of this topic, I actually tried to set all masked bathymetric values to -3.0 m instead of the original -100.0 m. But as Kate and Zafer suspected, this didn't turn out to be the cause of the blowup.

And next, I tried adjusting the start time of the model. As mentioned in my previous post, I tried to set the start time a few days earlier, but the model blew up at the same point. I then tried setting the start time to sometime AFTER the blowup point, and though I wasn't expecting much, the model ended up running properly to the end of the simulation period I set. I then relaxed my time step settings to a larger time step closer to what I was originally using, and it also ran without any problems.

So one of my guesses is that perhaps there was some problem in one of my input netcdf files. I couldn't find anything after an initial search for the data around the time of the blowup point, but maybe it's a subtle problem and easy to miss.

I actually also have a modified version of my original bathymetry, adjusting the points near the grid cell specified when the model was blowing up, which I haven't been able to test. But my original query was regarding the bathymetric values in masked areas, and it turned out that it was not the likely cause of the issue I was having. Thank you everyone for all your comments and suggestions.