Particles seeded in Ocean are being treated as being seeded on Land

[brucelaughlin]

Hello,

Please see the included image. I am using ROMS output and the associated reader. I am seeding particles at the first ocean rho points offshore of the coast in my domain. I noticed that the first locations stored in the Opendrift output files for some of my particles were not where I'd tried to seed them (in the image, you'll see lines connecting intended seed points (dark blue) with the first stored locations (cyan or green)). In my log files, I see that these particles were determined to have been seeded on land, and were then "moved offshore" before timestepping began.

In the figure, I've plotted mask_rho as the land mask, which I believe is what the Opendrift reader loads as the land mask when we set 'general:use_auto_landmask': False. Unless mask_psi is being used for some reason...

Thanks for your attention,
Bruce

P.S.
In the logs, it looked like the "nearest" integration method was used to determine if any seeded points are on land (let's call this step 0), and then "linearNDFast" is used for particle tracking. As an experiment, I tried modifying the base reader, line 35, to say "interpolation = 'nearest'" (rather than "interpolation = 'linearNDFast'"), to see if "nearest" had somehow not been used for step 0. But, this did not fix the issue.

[brucelaughlin]

UPDATE: Please see the new included plots. It's looking like there's a "one-off" issue with the loading of the user-inputted land mask. I'm using reader_ROMS_native.py as my reader, and I saved data from within __init__.py in models/basemodel/, specifically from within the closest_ocean_points() method.

White crosses indicate the Opendrift land points in the grid made within Opendrift (derived from the user-inputted rho mask), black crosses are ocean points, red dots are intended seed locations, cyan dots are actual seed locations (after Opendrift moves points or leaves them unchanged), magenta lines connect intended with shifted points. Purple/yellow are land/ocean in mask_rho directly from a ROMS grid.

Note that there seems to be a "one-off" problem in both the X and Y dimensions (compare Yellow/Purple (ROMS mask_rho) with White/Black crosses (Opendrift internal grid)

P.S. Sorry for the blue "halos" around all of the "intended" seed locations; I plotted dark blue dots at INPUT seed coordinates, ie before any Opendrift processing. So, if you see a cyan dot within a dark blue dot, that means no shifting happened. A red dot within a dark blue dot should be connected by a magenta line to a cyan dot, indicating a shift.

[knutfrode]

Nice analysis and figures!
However, it is not completely clear what is the problem here, i.e. what you are expecting and what is (not) happening?

Note that there is no "internal OpenDrift grid", as elements can have any locations, in contrast to the "ROMS grid" which is discrete and given from ROMS.
Note also that ROMS fields are staggered, and the ROMS reader does not apply a proper de-staggering, thus you might find shifts of half-a-pixel, which is negligible for many/most applications.

[brucelaughlin]

Hi! You're back!

So, the issue that I was trying to highlight in the figures above is this:

I have an application in which I'm actually trying to seed ONLY from the center of ROMS ocean grid cells which are closest to shore! So, already, I might be inviting some problems!

Anyway, Opendrift was alerting me that a number of these particles had been seeded on land, and that Opendrift was moving them offshore. That's what the magenta line segments in the figures represent - original seed location and shifted location from Opendrift.

The other thing that was confusing was that, though it's true that ROMS grids are staggered, the white crosses (representing a "higher resolution" landmask that's used internally by opendrift to shift particles (I hacked into the code and saved this data for printing)) suggest that there's an "irregular" staggering going on. Maybe that's poorly worded, but take a look at the different figures - the white crosses aren't offset by half a grid cell in one or both directions consistently. The offset isn't consistent, in magnitude or direction... that's why it seemed as though this wasn't an issue with an offset, but rather perhaps a projection issue...

Please let me know if I'm still not describing the issue well enough!

Thank you,
Bruce

[knutfrode]

The ROMS native reader actually accepts both mask_rho and mask_psi as landmask:
https://github.com/OpenDrift/opendrift/blob/master/opendrift/readers/reader_ROMS_native.py#L99

The reason is that some ROMS files (I believe some CROCO versions) do not output mask_rho, for some reason.
I guess this could be the reason for the offset you are seeing, if you are expecting mask_rho to be the landmask.
But you may try to change this by commenting out the line
'mask_psi': 'land_binary_mask'

As mentioned, the ROMS native reader does not perform a strictly correct de-staggering, again the reason being that the reader tries to be compliant with many different versions of ROMS and CROCO etc.
I guess interpolating (de-staggering) all fields to rho-points would be the ideal in practice. I might have a go on this soon, perhaps at the cost of not accepting all versions of ROMS output.

The mentioned (now removed) warning about fakeproj was about accuracy on a completely different level (geodesy, ~centimeters), and thus irrelevant for all practical OpenDrift applications. But the staggering-issue may give offsets of half-a-pixel, which may not be negligible for all applications.