Adding option for kernel renormalization?

[AhmedSalih3d]

In some cases when dealing with simulation, where particles can end up not being as closely packed as initially or at edges of a numerical point domain, the default kernel_value will start to give errorneous results. This can be corrected by a kernel renormalization (called Sheppard-filtering in SPH):

http://www.gpusph.org/documentation/theory-guide/

In this case it is used for the density estimation, if one wants to get it for the "raw kernel", set mb = 1 (unitless).

Would this make sense to include at some point?

Are you using something similar to this? I see correction for tensile instability, but does not seem to be exactly the same thing.

Kind regards

[LudwigBoess]

Hi Ahmed,

thanks for bringing this up, I'm aware of Sheppard filtering, but I have not used it yet. My background is in computational astrophysics where we mainly use periodic boundary conditions, or set the boundaries so far outside the interesting systems that this is not very relevant.

I've been thinking a lot about this kind of functionality (also what we discussed in #18 ) in the current package and I'd be very interested in your opinion on the following:

I'd like to take a step back with all of this and keep this package as a pure Kernel package. All the functionality we talked about is leaning more towards implementing an actual SPH loop, which I think should be done in a separate package. If we implement this here I think we're being a little inconsistent with the goal of this package.

I've played around with a single-core SPH loop using NearestNeighbors.jl in a package that is currently still private (since it's still a huge mess). This will of course need to be extended to work with shared memory parallelism, to make it scalable. PhysicalTrees.jl could be a starting point here, or some self-written tree that could potentially also run on a GPU. But that will require a lot of work I really can't put into something like this at the moment. I'd be happy to clean up what I have and share it with you though!

Ultimately I'd like to have a small separate package that contains the neighbor finding based on some tree method and calculates hydro accelerations based on an SPH loop. That package then uses kernels from SPHKernels.jl and does the gradient, divergence and curl calculations, together with any corrections in its own convention. This could then be combined with any numerical integration scheme to run an actual simulation. I'd also like to use it as a basis for a Julia implementation of WVTICs which is explained in a paper I got to contribute to.

So there's definitely more than enough work to do, I'm just not sure this package is the right place to do it. What do you think?

[AhmedSalih3d]

Hi again! Always nice reading your comments

I see, interesting to hear about your background!

I agree that we can keep this package as being bare-bones SPH kernels and that would make great sense. Then some packages dependent on it could spring out, like line or plane interpolations of data sets if you get my point. And also as you mention some other interesting stuff you are working on.

I think that gradient, div, curl. laplacian (heat transfer) etc. should be present in this package still though, to keep everything connected - but no more than that.

Have you heard about CellListMap.jl? It does pretty much what you want and is in Julia too!

It works pretty smart too, that it will calculate values as neighbours are being computed, which means no storing of indices etc. I think this is what you want - my experience with NearestNeighbours is that it works, but suboptimal for fast loops etc.

I think we pretty much agree then though? SPH Kernels and math operations, no filtering etc. in this package.

Kind regards Ahmed