NOAA-ORR-ERD / PyGnome

The General NOAA Operational Modeling Environment
https://gnome.orr.noaa.gov/doc/pygnome/index.html
Other
51 stars 43 forks source link

Subsurface spill #127

Open rmogollon opened 1 year ago

rmogollon commented 1 year ago

Hello everyone!

I am wondering if something is missing when running a subsurface oil spill case. I obtained the same solution whether the particles were released at 18 or 100 m depth (or even any depth). Actually, the particles upwelled instantaneously to the surface despite tridimensional currents were provided (Please, check the figure below). 18vs100

In addition, the figure below shows the map of trajectories until two days after the oil spill added with the RiseVelocityMover and Random_Mover_3D. As seen, in the left panel (with surface_is_allowed=True), the same exact path is obtained when compared with the previous figure when these two options weren't enabled. Whereas in the right panel (surface_is_allowed=False), it seems that all particles go upward "bouncing in the air". (btw, vertical_diffusion_coef_above_ml=10) randomwalk3d

Could you please provide me with more details about the situation I have just described?

On the other hand, when I try to include weathering processes I obtained the following warning: "....spreading.py:665: RuntimeWarning: invalid value encountered in double_scalars thickness = (data['bulk_init_volume'][s_mask][0] /" and when I check the .csv output file there are only zero values regarding the quantity evaporated, dispersed, and sedimentation. However, when I use surface_point_line_spill rather than subsurface_plume_spill, it runs smoothly. Any thoughts?

Thank you in advance

Regards

Rodrigo M.

ChrisBarker-NOAA commented 1 year ago

Thanks for testing this! I confess that these features have not had the testing they deserve, but should work.

However, we recently had some updates to the gridded package that may have improved this.

@jay-hennen: was the bug with elements being both subsurface and on the surface fixed in gridded?

So the first step is to make sure you have up to date code: be sure to use the main branch at this point.

Then make sure that you've updated the requirements.

Moving on to the issues:

Actually, the particles upwelled instantaneously to the surface

The only thing that should move them up is the RiseVelocity Mover -- try running with only that, and/or with it turned off, to see where the problem is.

In addition, the figure below shows the map of trajectories until two days after the oil spill added with the RiseVelocityMover and Random_Mover_3D.

so the elements were rising to the surface with only the currents? That's not good. check the units of the vertical velocities if cm/s is being interpreted as m/s that could cause issues. but vertical velocities should be really small in any case....

As seen, in the left panel (with surface_is_allowed=True), the same exact path is obtained when compared with the previous figure when these two options weren't enabled.

If you have massive vertical movement, then you may not see the vertical diffusion at all.

Whereas in the right panel (surface_is_allowed=False), it seems that all particles go upward "bouncing in the air".

They should never leave the surface. and with surface_is_allowed=False, they should reach the surface and then stay there.

(btw, vertical_diffusion_coef_above_ml=10)

That should be reasonable.

What time step are you using?

Suggestions for debugging:

1) try running it with very simple scenarios -- maybe ten particles, so you can see what's going on in detail.

2) post your script(s) here for us to take a look -- and ideally, if you can post a link to your currents files, we can try to see what's going on. (hopefully you can make a current file with a small domain and/or only a few timesteps to keep it small)

rmogollon commented 1 year ago

Dear Chris,

Thank you for your feedback.

I use the main branch (installed about 2 weeks ago) and I have updated all the requirements, as suggested.

The first experiment was turning off all the movers and random walks, including the rise velocity. The particles (n=10) were released at 50 m depth and remain in the same (x,y) spot during the 2-day simulation, as expected, but surprisingly, they all go upward instantaneously, from 50 to 0 m depth, despite no rise velocity was set (see panel a). In a second experiment, I activated only the random walks (with surface_is_allow = True) keeping the movers and rise velocity inactive, resulting in an instantaneous upwelling, such as the first one, but with some horizontal motions at the surface around the (x,y) release point (see panel b). The third experiment was similar to the previous one, but using surface_is_allow = False. In this case, all the particles go directly into the air, bouncing around +50 m in height (see panel c). Finally, panel d shows the solution with random walks and rise velocity activated, maintaining movers off. This solution is exactly the same as the second experiment (panel b), which may suggest that there are some issues with the rise velocity opts (not sure where this massive vertical movement is coming from) and it is not related to the currents (units are ok, in m/s).

s1

The time step is 60 minutes. Later I will post the script and the associated files. Thanks again!

ChrisBarker-NOAA commented 1 year ago

The first experiment was turning off all the movers and random walks, including the rise velocity. The particles (n=10) were released at 50 m depth and remain in the same (x,y) spot during the 2-day simulation, as expected, but surprisingly, they all go upward instantaneously, from 50 to 0 m depth, despite no rise velocity was set (see panel a).

well, that sure seems like a bug! When you post your scripts, we'll take a look.

surface_is_allow = False. In this case, all the particles go directly into the air, bouncing around +50 m in height (see panel c)

and that too :-(

Stay tuned.

rmogollon commented 1 year ago

Hello Chris, Here you have the code and the associated files.

https://drive.google.com/drive/folders/1Q6c_m49_x8ffBbHcEaEdfpyMyIyFY6II?usp=sharing

coconnor8 commented 1 year ago

One issue I noticed is your depth value is negative. The spill depth needs to be positive, which would explain the spill getting moved immediately to the surface.

rmogollon commented 1 year ago

@coconnor8 Thank you for the contribution! Now it makes sense. You were right, I did not notice this small detail about positive depths. untitled @ChrisBarker-NOAA I am sorry for the initial concern.

I have two more doubts about this subsurface spill case. The first one is related to the generation of the folder where the experiment may be saved. When I want to save the scenario (for instance if I want to run it by using WebGnome) I have the following message: AttributeError: 'RiseVelocityMover' object has no attribute 'water_density'... Should I worry about it?

The second doubt is regarding the weathering processes. When I activate them I obtained the following error: "...gnome/weatherers/spreading.py:665: RuntimeWarning: invalid value encountered in double_scalars thickness = (data['bulk_init_volume'][s_mask][0] /" ... Did you encounter this error before?

*The same code and files can be used to try to reproduce them.

Thank you!

coconnor8 commented 1 year ago

The first one looks like a bug on our end. The water density was removed from the class but not from the schema.