OpenDrift / opendrift

Open source framework for ocean trajectory modelling
https://opendrift.github.io
GNU General Public License v2.0
249 stars 120 forks source link

ROMS landmask #639

Closed John-Luick closed 2 years ago

John-Luick commented 3 years ago

I just tried doing an opendrift simulation using directly the output from ROMS (a roms_his.nc file). This ROMS grid is a bit unusual because it is only encompassing a small dredged area located in a vast mudflat, so there are no coastal boundaries, but I have masked off the area surrounding the wet (dredged) area. I assumed that opendrift would recognise the landmask in the roms_his.nc file (the mask_rho variable), but that does not seem to be the case, as the tracers try to travel beyond the dredged area (where currents are available). What am I missing?

knutfrode commented 3 years ago

First, you could check that the reader really detects the landmask with >>> print(reader) Secondly, the default, GSHHG landmask has to be disabled by

>>> o.set_config('general:use_auto_landmask', False)

See this example for a demonstration: https://opendrift.github.io/gallery/example_model_landmask.html

John-Luick commented 3 years ago

Thanks very much, that solved the problem immediately. I didn't reply immediately because I then had another problem. I just got around to solving that problem, but I don't know why my solution works. It just does. Here it is: When I used the following form: o.seed_elements(53.8148, 24.2567, z=-1, radius=20, number=Nseed, time=seed_time) all the values of z in the output file are -1e36, even though the tracer trajectories are reasonable. But when I changed to the form: o.seed_elements(53.8148, 24.2567, z=-1, radius=20, number=Nseed, time=ocean_reader.start_time) the values of z are correct! Note that the value of seed_time is defined by seed_start=datetime(2021,4,11,0,0,0) seed_duration=timedelta(hours=1) #Make seed_duration <= run_duration seed_end=seed_start+seed_duration seed_time=[seed_start, seed_end] Where the first time in the ROMS input data file is 2021,4,11, so the two start times should be the same. But what I find odd is that it should affect the z that is written on output, even though the trajectories plotted by OpenDrift are the same. Generally speaking, I find OpenDrift incredibly flexible and powerful, but I seem to have found something it does not like.

knutfrode commented 3 years ago

Values of -1e36 sounds like masked values in the netCDF-file, which should not be read. OpenDrift will mask this automatically when importing, but this might not happen if you import it with your own code (e.g. directly with netCDF library).

So when you seed over the interval [start_time, end_time], many of the elements will not yet have been seeded, and may have values like that in the raw netCDF file. But elements that have been seeded, should have -1.

Could this be the case?

John-Luick commented 3 years ago

I am just using the roms_native reader. Also, just looked at the roms "history" file, and the fill values used are 10e36 in variables that have a fill value. Of course, the mask itself is all 1s and 0s. It could be that some variable does return a value of -1e36 at a masked point. For now, I will just use the approach of a single scalar seed start time plus a seed duration, rather than the [seed_start seed_end] approach. If I get any further clues I will relay them (although by then this thread may be closed). Thanks, John.

gauteh commented 2 years ago

Closing for now, let us know if the issue persists.