Efficient code for computing particle densities about parcels HOT 10 CLOSED

Ok, I believe this is similar to the diagnostic fields that @Jacketless requires to model predator-prey interactions. The idea here is to generate a field (numpy array) that sums the total amount of a variable quantity stored on the particles in each cell and then normalises this by cell volume. To get a particle density the value each particle "deposits" is then 1, but for a "prey" particle this might be some measure of biomass, which in turn allows the "predator" particle to sample the local population and adjust its behaviour accordingly.

In terms of implementation it is important to note that no tree is required here, since our particles always know where they are in the grid. The syntax I would propose for the "depositing" action would probably be something like grid.DiagFieldA << particle.varA, which would be interpreted in parcels.Kernels accordingly.

from parcels.

The benefit to the tree is aggregation of particles for computational
efficiency. This essentially helps with problems requiring accounting for
lumped effects of particles far away, especially for problems like
gravitation. I agree, @mlange05, you can probably do something like binning
based on position instead for densities, but may find trees useful for
other applications.

from parcels.

I'm now at the point where I would soon like to begin comparing particle densities at certain points with corresponding variables from a Eulerian model.
This is something I can do "offline" from the particle output .nc file in the manner @mlange05 suggests (binning and counting), but do we want to open a branch that does these calculations and writes to a field as a first step to on-the-fly particle density calculation?

from parcels.

Did PR #81 fix this issue now? Or do we still need to keep it open?

from parcels.

No, PR #81 was orthogonal to this.

from parcels.

PR #67 has made an attempt at density calculation within the main execution loop, but is not passing tests. A more considered design of adaptive execution loops was mentioned in #78 and so I have held off any further development on this issue. #67 contains enough functionality for me at the moment, but happy to discuss how to fix and get it into the master branch.

This is really the last piece of PARCELS functionality I require for the initial tuna milestones.

from parcels.

Two points on this old Issue:

• Related to calculating densities is also the computation of streamfunctions (like what Ariane does). This would be a great feature to have, as it is one of the most-used diagnostics in Ariane. We could look at their implementation and mimic that
• An additional difficulty in computing fields of particle densities (or streamfunctions) during runtime is that in C we can presently not write to Fields (we can only read Fields). So there is no easy way to change values of a field within the JIT-execution. Not sure how to easily fix this

from parcels.

Fixed in #255

from parcels.

Hi, I was wondering if there was any development on the computation of streamfunctions, as mentioned above. Thanks!

from parcels.

We haven't developed code for this in Utrecht yet, but I think that @ignasivalles may have previously computed streamfunctions from particles. Maybe he can help?

from parcels.