Open zhazorken opened 3 months ago
What grid are you using? Is it Flat
in all directions? You've omitted this from your script.
This may be a bug for triply-flat grids, not sure.
I realized I can see from the error message that the grid is Bounded
in all directions.
I've never used this feature but I think you aren't specifying the tracked fields correctly. It needs to be something like
# Define tracked fields as a NamedTuple
tracked_fields = (; T=tracers.T)
In other words, the values of the NamedTuple are themselves fields. So you have to build tracers
before constructing the model. Something like this may work:
tracers = (T=CenterField(grid), S=CenterField(grid))
# Define tracked fields as a NamedTuple
tracked_fields = (; T=tracers.T)
model = NonhydrostaticModel(; grid, tracers, ...)
This feature could use an example in the docs. It would also be convenient if users did not have to build structs like tracers
or velocities
manually in order to use this.
Ah perfect, thanks @glwagner, just confirmed that this worked.
This feature could use an example in the docs. It would also be convenient if users did not have to build structs like
tracers
orvelocities
manually in order to use this.
Agreed! I am also curious how to specify particle "dynamics"... (is it possible to add e.g., buoyant particles currently?)
dynamics
is just a function called with this signature:
I found that just by reading the source code. It's all contained in three files here:
https://github.com/CliMA/Oceananigans.jl/tree/main/src/Models/LagrangianParticleTracking
For buoyant particles I think you want to add a velocity increment to the particle position. But it'd be nice if users didn't have to do this manually, ie if we could add additional advecting velocities. I think there's a PR about that floating around...
Unfortunately since docs are pretty spare I think you're going to have to be reading the source code. Documentation PRs definitely welcome!
Another thought about the error in this issue: I think it would make sense to validate the tracked_fields
. For example each property should be AbstractField
with a proper location(field)
, otherwise the error in the post is received (the location was evaluated to nothing, nothing, nothing
)
Great! This is very helpful advice/background, I will take a look.
Should I open a separate thread about Lagrangian particle tracking on immersed boundaries ((2) at the top)?
I thought we'd made this change a while ago, but users should probably just be able to specify tracked fields by name and then we could just change: https://github.com/CliMA/Oceananigans.jl/blob/9b67d4d106c905918866e0edb527def0edcc367f/src/Models/LagrangianParticleTracking/update_lagrangian_particle_properties.jl#L24-L33
to e.g.:
for name in particles.tracked_fields
field = getproperty(fields(model), name)
...
or if we still want the particles to be able to have their own externally defined fields (I'm not sure why we would?), then we could do something a bit more complicated.
I remember having similar issues when I started using particles too.
I thought we'd made this change a while ago, but users should probably just be able to specify tracked fields by name and then we could just change:
to e.g.:
for name in particles.tracked_fields field = getproperty(fields(model), name) ...
or if we still want the particles to be able to have their own externally defined fields (I'm not sure why we would?), then we could do something a bit more complicated.
I remember having similar issues when I started using particles too.
This seems much better.
Aren't there plenty of applications for tracking fields that aren't in fields(model)
? For example, density, buoyancy, vorticity, speed, light availability.
Supporting those cases may require a little redesign of the particles functionality though, so I think the change @jagoosw suggests is still moving in a good direction. It's pretty primitive and hasn't seen a whole lot of love since it was first hastily thrown together many years ago.
One way to keep the current functionality (though syntax would change) is to allow a tuple of tracked_fields
, which can either be Symbol
(which must be a name in fields(model)
) or a Symbol => Field
pair. It's still annoying to build those Field
prior to model construction but at least it leaves open the possibility.
Hi all! I've been testing the Lagrangian particles method (ideally on GPUs, but I'm including the error messages for CPU compilation for simplicity) and am running into two issues: (1) tracking dynamical fields, and using (2) Lagrangian particles with immersed boundary active. Would love to hear what is working/isn't available w.r.t. this method or if I'm making a mistake somewhere ... or any other suggestions!
(1) (solved, see comment below) Tracking dynamical fields I'm testing here is the LagrangianParticles for temperature/salinity (version below testing for CPUs). I tested Lagrangian particle tracking for saving x,y,z locations first, which works. However, once I add in T as a tracked field:
I get the following error:
(2) I also ran (x,y,z) position tracking only while immersed boundary was active. There was a method error relating to cpu__advect_particle >>advect_lagrangian_particles: