New: prevent beaching - I will modify my code

[bhlevca]

The old Gnome had a checkbox for preventLandJumping

In the WebGnome interface I could not find it. I found the setting in PyGnome in a GuiTypeDefs.h structure as a Boolean and referred in Model_c.cpp/h, TModel.cpp.

My question is about where to find the setting in the GUI, or if it is not present how to expose it. I prefer a dynamic solution to hardcoding in the cpp code.

Also, I would be interested where are the settings to modify the adherence to the shore, besides the known culprits dispersal, wind, etc.

I deal with rivers and lakes and the default setting is totally inappropriate. It may work in the open ocean with the occasional shore/island.

Any help will be highly appreciated. Thanks, Bogdan

PS I put it in PyGnome as in Client and API there are no indicators of this variable, which means that the setting is dynamically creating the GUI box

[coconnor8]

WebGnome should always prevent land jumping. There is no longer an algorithm that allows it. Are you seeing land jumping or trying to turn it on?

For adherence to the shoreline you want Refloat Halflife, which is on the Map form. It defaults to 1 hour and can be set lower so particles refloat faster (zero for immediate refloat) or higher so particles stick to the shoreline longer.

[bhlevca]

Perhaps I did not understand well what LandJumping is. I thought it was related to adherence to the shoreline.

I want to prevent beaching / adherence to the shoreline since I have a lot of it on a river.
I think that I set the Refloat Halflife to 1 and even 0, but the adherence to the shoreline was still happening. I have not seen any refloating. My goal is to prevent any adherence that is not so strong for non-oily substances and in a river environment is too extreme.

I am not close to a WebGNOME deployment but I will double-check the settings in the the Map form and get back to you. I could try to start WebGnomeAPI in a debugger and put a breakpoint somewhere useful if you can suggest one. Thanks

[jay-hennen]

If your currents, winds, and horizontal diffusion still result in a net motive force towards the shoreline, you may still experience a lot of adherence to the shoreline. Refloat is simulated by effectively moving the oil a very small amount back the way it came, so if you have say a consistent wind blowing towards a shore, it will result in the oil just ending up on the shore again. Another source of your problem may be river currents that don't fully overlap with the land polygons. This results in an effective dead-zone gap between the simulated river current and simulated shore, where the only motive force on the oil at this point would be winds or horizontal diffusion. When oil enters these dead zones, only random horizontal diffusion or favorable winds may push it back into the river current. Reducing the effect of wind by reducing the oil windage or turning wind off altogether may result in less oil escaping the river current. I would also recommend reducing your simulation timestep to a great degree. For example, our Lower Mississippi location file uses a timestep of 36 seconds. Between 1 and 3 minutes may be low enough. This is often necessary for oil to follow a river current closely enough.

…

On Wed, Mar 12, 2025 at 11:33 AM Bogdan Hlevca ***@***.***> wrote: Perhaps I did not understand well what LandJumping is. I thought it was related to adherence to the shoreline. I want to prevent beaching / adherence to the shoreline since I have a lot of it on a river. I think that I set the Refloat Halflife to 1 and even 0, but the adherence to the shoreline was still happening. I have not seen any refloating. My goal is to prevent any adherence that is not so strong for non-oily substances and in a river environment is too extreme. I am not close to a WebGNOME deployment but I will double-check the settings in the the Map form and get back to you. I could try to start WebGnomeAPI in a debugger and put a breakpoint somewhere useful if you can suggest one. Thanks — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRH7DOHHZIA2SFKFWR45UD2UB4V5AVCNFSM6AAAAABY2F526SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJYG43DOMBVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: bhlevca]*bhlevca* left a comment (NOAA-ORR-ERD/PyGnome#181) <#181 (comment)> Perhaps I did not understand well what LandJumping is. I thought it was related to adherence to the shoreline. I want to prevent beaching / adherence to the shoreline since I have a lot of it on a river. I think that I set the Refloat Halflife to 1 and even 0, but the adherence to the shoreline was still happening. I have not seen any refloating. My goal is to prevent any adherence that is not so strong for non-oily substances and in a river environment is too extreme. I am not close to a WebGNOME deployment but I will double-check the settings in the the Map form and get back to you. I could try to start WebGnomeAPI in a debugger and put a breakpoint somewhere useful if you can suggest one. Thanks — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRH7DOHHZIA2SFKFWR45UD2UB4V5AVCNFSM6AAAAABY2F526SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJYG43DOMBVGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ChrisBarker-NOAA]

Thanks @jay-hennen -- that's all correct.

One note: there is not way (currently) to have elements ""bounce" off the shoreline -- that is, never stick at all.

If you set the refloat half-life to zero, then all elements should be refloated at the next timestep.

So:

1. if. the combination of winds, currents, and diffusion move an elements onto land, it will be "beached" at the end of the timestep.
2. at the beginning of the new timestep, it will be moved back into the water, near the shoreline, according to the refloat half-life. If that's set to zero then all elements should be refloated at the next timestep.
3. the element is moved -- if the forcing hasn't changed, then it will likely be moved back to the land, and the process begins again.

NOTE: diffusion is troublesome for this, as even if set to a small value, it will tend to push about half of the elements back onto the shoreline.

As @jay-hennen says -- there are a lot of limitations due to the resolution of the map and the currents, etc -- but a short timestep can help.

[bhlevca]

Thank you for your suggestions I will try them all.
I don't think that I have a land polygon issue, but I am going to verify as I have the hydrodynamic mesh and boundaries (bna) that should match perfectly as they were derived from the same polygons.

We changed WebGNOME (fork from yours) a bit to accommodate a hydrodynamic model (currents) as a mover. We use MIKE 3 by DHI to provide hydrodynamics. It is done in an integrated fashion with WebGNOME. We have a set of scripts that download meteo and tributaries data that are triggered periodically by tasks(windows)/cron (Linux). The web interface got a button to start the HD model and the results were converted to a NFC file and uploaded to the mover section. We also added a concentration module that converts the lagrangian particles into a volumetric concentration.

Also, we added a bar on the main page for the timeline for the HD model stacked with the other timelines.

Ideally, I would completely disable the adherence to the shore as it is not helping with my type of simulations.
I will try your suggestions, but I have the feeling that it will not be enough for a river environment.
If it is possible at all I would appreciate it if you could give me some ideas (file/function ) where the adherence could be disabled.

Also because mike3 python package is available only in PIP I converted all the dependencies to use PIP. The hardest to change was py_gd but works. I sent you a pull request at the time for your consideration NOAA-ORR-ERD/py_gd#27 . it required creating a project.toml and few other small changes

Thanks

[bhlevca]

Hi, I managed to fix all my problems regarding the volumetric concentrations and other issues. I also changed the subject of the issue as beaching was what I had in mind and not Land Jumping, which for some reason thought is the same thing.

However, there is one more issue that I need your help in solving. Here are the facts:

• Even if Refloat is set to zero I have areas on the river that will never be passed.
• It is not about the wind as @jay-hennen suggested. It happens even if the wind is zero
• because the currents change direction in a meandering river
• even if I set diffusion at a low value it still happens see the attached figures
  
  

I need some help to chase down the beaching code and disable it for my purpose or find a way to disable it with a switch from the GUI that is passed down to the server.

This is the only remaining problem before having the code ready for going live.
I would appreciate some suggestions about what files and methods that could be tweaked to disable beaching.
Thank you!

[coconnor8]

The model calls beach_elements which is in maps/map.py, RasterMap class. You might just want to have on_land (also in map.py) return false. You'll need to be careful that your time step is small enough so the particles don't move off the currents' grid and get stuck, or get moved across land by wind or diffusion. You could start by just removing the map altogether to see if the particles move along the grid as expected using only the current.

[dylanrighi]

Coming late to this discussion, so I apologize in advance if this has already been considered.

But I think I had a similar problem when working with a river scenario recently. The problem turned out to be that the land mask raster was too coarse and created a spot on the river where particles had no pathway through and would always beach. The problem spots were where the river got skinny and turned - similar to your blockages.

The problem comes up because, while your .bna may exactly match your hydro model polygons, pygnome uses a bitmap to define land. In the map window on WebGNOME, try turning on the Land Mask layer under the Layers/Model Map tab on the right and check if the mask is obstructing your river. (there's a known issue that could cause this layer to be offset...Jay tells me it's got to do with the projection Cesium uses?)

Possible solutions are to use a smaller map domain (smaller range making the raster resolution better), or to increase the LandMaskRasterSize value in the Map edit window.

[bhlevca]

I appreciate all this feedback. I will try Dylan's suggestions first, and if the problem persists, I will be radical with eliminating beaching. I am going to report back as soon as I find the cause. Thanks

[bhlevca]

The problem comes up because, while your .bna may exactly match your hydro model polygons, pygnome uses a bitmap to define land. In the map window on WebGNOME, try turning on the Land Mask layer under the Layers/Model Map tab on the right and check if the mask is obstructing your river. (there's a known issue that could cause this layer to be offset...Jay tells me it's got to do with the projection Cesium uses?)

My BNA is very accurate and as you said it matches exactly the HD model polygon.
I did turn the Land Mask Layer and indeed it is offset as shown below.

What can I do to avoid this offset? Can we change the projection? My map is Lat/Long and it does not and it should not be projected. However, the particles may be different.

1. Should I use something else?
2. Can you point me to the code that generates this map see if I can modify the shift?

Possible solutions are to use a smaller map domain (smaller range making the raster resolution better), or to increase the LandMaskRasterSize value in the Map edit window.

I increased the the map raster size from 16 MB to 64 MB and the particles go through but still there is a lot of beaching and therefore, there is a delay duet to time step skipping when jumps back and forth. I will try to remove the beaching altogether.

My goals are 2 now:

1. Correction of the mask projection I think that it is important to fix. Can this Cesium software be tweaked somehow or replaced? For example I see below transformations occur. Where is the code that creates the raster mask? I can start looking there

• in maps/map.py ```
  def approximate_raster_interval(self):
          orig, diag = self.projection.to_lonlat(np.array([(0, 0), (1, 1)]))
          orig = np.r_[orig, 0] # make (lat, lon) into (lat, lon, z)
          diag = np.r_[diag, 0]
          diff = self.projection.lonlat_to_meters(orig - diag, orig)
          return np.average(np.abs(diff))

2. remove beaching or make it less aggressive (perhaps with a Raster Mask correction there will be fewer occurrences) I will try to make `on_land()` return false and see what happens

Thank for all your help so far, at least I understand what is happening. If you can give me further guidance for the 2 items I listed above and I can solve them I will have the product I need.  

[jay-hennen]

The Land Mask layer offset you see is purely a graphics bug. In the simulation, the mask and the coastlines are aligned. To be honest it has been a low priority issue for a long time. It was added as a diagnostic tool and hasn't had much use aside from that.

If you are working with the web client source, the code that fetches the raster is js/model/map/bna.js:38. The code that generates the Cesium representation is the next function down on line 108.

The code that handles the checkbox in the layers panel is js/views/cesium/layers.js:675

[bhlevca]

Thanks @jay-hennen. That was helpful, in particular the size of the raster map helped. Now I get through as per the image below

• But why is it limited to 128 MB? what is the limitation for a more accurate raster map? Computer these days have 64 -128 GB of RAM. JavaScript? data transfer speeds.
• I found the code that limits it, but I need to understand the implications and dependencies if I modify it.

As regarding the beaching I am still unable to prevent it as seen in the attached image.
My code is a bit behind yours as it is a fork from last year, but the RasterMap on_land() is only called once at the beginning of the particle simulation and beaching still happens. Other classes on_land() are not called at all.

1. My goal 1 to go through with particles in narrow rivers is achieved
   2. My second goal to completely remove beaching is not there yet. I am wondering if you have other ideas about how to prevent beaching.

Please help! Thank you! After solving that I will have a modernized emergency spill response system for internal lakes and rivers.

On another subject, I hear that NOAA will have funding restrictions. Are you guys affected? I hope not, you do a wonderful job and we rely on data from you.

[ChrisBarker-NOAA]

A few comments:

But why is it limited to 128 MB? what is the limitation for a more accurate raster map? Computer these days have 64 -128 GB of RAM.

An arbitrary limit -- it's all in memory on the server side, so you are correct that with modern computers, it could be a lot larger -- but i think there would be little benefit.

I found the code that limits it, but I need to understand the implications and dependencies if I modify it.

Give a try to extending that limit, and see if makes any difference to you issue. I suspect it won't.

Note that the Python "Renderer" outputter includes a way to draw the raster map, so you can see what it looks like without the projection issues of looking at it in WebGNOME.

You can see how to use it by looking at the test_renderer.py in the test code -- here's the simple test:

def test_draw_raster_map(output_dir):
    """
    tests drawing the raster map

    Note: you need to look at the output to know if it did it right...

    """
    import gnome

    r = Renderer(bna_sample, image_size=(1000, 1000))
    r.viewport = ((-127.47, 48.10), (-127.22, 48.24))

    r.draw_background()

    # make a raster map out of the BNA:
    r.raster_map = gnome.map.MapFromBNA(bna_sample,
                                        raster_size=10000)

    r.raster_map_outline = True
    r.draw_raster_map()

    r.save_background(os.path.join(output_dir, 'raster_map_render.png'))

As regarding the beaching I am still unable to prevent it as seen in the attached image.
My code is a bit behind yours as it is a fork from last year

this code hasn't changed in ages anyway :-) But you may want to update to more recent version for other reasons -- git should make that not-too-hard.

, but the RasterMap on_land() is only called once at the beginning of the particle simulation and beaching still happens. Other classes on_land() are not called at all.

on_land is a utility function used primarily to make sure that a spill isn't on land when initialized. The actual beaching code is in the beach_elements() method (that's because the code needs to follow the path of the particle as it moves to see if it hits land -- otherwise, it could "jump over" a narrow isthmus.

At least for testing, the way to definitively turn of beaching is to simiply put no map there at all, and see what happens.

2. My second goal to completely remove beaching is not there yet. I am wondering if you have other ideas about how to prevent beaching.

You could "monkey patch" the Map, by redefining "beach_elements" to do nothing. but that would turn off beaching for the whole map, so maybe not useful -- but good for testing.

I suspect your issue is not actually beaching per se. One trick with circulation models is that the flow direction in narrow channels may not be exactly correct -- the boundary conditions should force the flow to be parallel to the shore, but it may not be exactly parallel. And then combine that with having to interpolation the velocities within the grid, and the particles can get moved outside the channel -- off the grid. Then then will be beached, or won't move at all, unless moved by wind or diffusion.

If you turn on the current vectors in WebGNOME, you might see what's going on. And / or see what happens without a map.

NOTE: looking quickly at the images you posted, i think this is exactly the issue :-(

What to do about that? That is a challenge! It's been on our list of possible improvement for ages.

One option is to update the current mover (or make a subclass), that checks if the particle was moved off the grid, through a land boundary, and if so, puts it back on -- but there are multiple edges cases to work out on that ....

Meanwhile, a smaller time step may help.

On another subject, I hear that NOAA will have funding restrictions. Are you guys affected?

I'm afraid so -- all of NOAA (indeed the entire US federal government) is affected.

But so far the GNOME development group has been only moderately impacted -- but the final outcome is not clear -- but we do hope to continue to maintain it, and it will be available as Open Source on gitHub in any case.

[bhlevca]

Thanks for the detailed response Chris

I found the code that limits it, but I need to understand the implications and dependencies if I modify it.

Give a try to extending that limit, and see if makes any difference to you issue. I suspect it won't.

So far works with 128 MB, but I'm going to give it a shot to see what happens with larger memory.

Note that the Python "Renderer" outputter includes a way to draw the raster map, so you can see what it looks like without the projection issues of looking at it in WebGNOME.

You can see how to use it by looking at the test_renderer.py in the test code -- here's the simple test:

Thanks for pointing it out. I will use it if I will have doubts about blockages, but so far the flow goes through, my remining problem is beaching. Setting the Reflow Halflife to 0 improves dramatically the outcome, but still according to my calibration data the arrival of the plume is substantially delayed on those narrow channels due to the beaching-wait on time step-refloat cycle.

on_land is a utility function used primarily to make sure that a spill isn't on land when initialized. The actual beaching code is in the beach_elements() method (that's because the code needs to follow the path of the particle as it moves to see if it hits land -- otherwise, it could "jump over" a narrow isthmus.

I was suspecting so since it is called only once at the beginning.

At least for testing, the way to definitively turn of beaching is to simiply put no map there at all, and see what happens.

Unfortunately, this will not work, the dispersion will spread the particles all over the place instead staying confined in the river or lake. I already tried this as it was suggested before.

2. My second goal to completely remove beaching is not there yet. I am wondering if you have other ideas about how to prevent beaching.
   11
   You could "monkey patch" the Map, by redefining "beach_elements" to do nothing. but that would turn off beaching for the whole map, so maybe not useful -- but good for testing.

I will try this to see if it will work better than removing the Map.

I suspect your issue is not actually beaching per se. One trick with circulation models is that the flow direction in narrow channels may not be exactly correct -- the boundary conditions should force the flow to be parallel to the shore, but it may not be exactly parallel. And then combine that with having to interpolation the velocities within the grid, and the particles can get moved outside the channel -- off the grid. Then then will be beached, or won't move at all, unless moved by wind or diffusion.

you can see the vectors in one for the postings above. They are parallel to the shore. When there is a turn obviously some vectors bay intersect the shore but only because they were displayed enlarged for visibility. I think that I am OK with the currents.

If you turn on the current vectors in WebGNOME, you might see what's going on. And / or see what happens without a map.

NOTE: looking quickly at the images you posted, i think this is exactly the issue :-(

I think that I am OK with the currents, they intersect just because I have drawn them bigger for visibility. they are parallel.

What to do about that? That is a challenge! It's been on our list of possible improvement for ages.

One option is to update the current mover (or make a subclass), that checks if the particle was moved off the grid, through a land boundary, and if so, puts it back on -- but there are multiple edges cases to work out on that ....

This is a good idea. I may just do that if the beach_elements() will work.

Meanwhile, a smaller time step may help.

That definitely helps, I already do time steps between 3 to 5 minutes. Otherwise, the delay due to beaching is even worse.

But so far the GNOME development group has been only moderately impacted -- but the final outcome is not clear -- but we do hope to continue to maintain it, and it will be available as Open Source on gitHub in any case.

I'm sorry to hear that some people have been impacted. GitHub is great, perhaps more people could contribute.

On that line, I submitted sometime ago a pull request for py_gd . It contains changes that allows py_gd to be compiled and installed with pip (https://github.com/bhlevca/py_gd). We integrated the Mike3D hydrodynamic workflow in the WebGNOME framework and the Python packages that control MIKE exist only in the form of pip packages, so I modified everything to be installed with pip (on the other hand I also hate conda). MIKE got a button in the main panel and we start the hydrodynamics and when ready the output is converted to a .nc file. We have a system of scripts that pull every 2 hours historical and forecast data that feed into the HD model. All is automated, if I fix the beaching issue I have a fully automated spill response system.

Thanks for your help and i hope that some of my contributions could be helpful to others.