Choose between u = r/h or q = r / (N*h)

[LudwigBoess]

As discussed in #11 we should decide how to proceed with the kernel definition.

Currently the package follows the convention of for example Gadget, which is uncommon compared to other SPH codes.
( For a discussion on this see e.g. Dehnen & Aly (2012), Section 2. )

This convention has the advantage of making the switch between kernels easier, for example in the neighbour search (to my knowledge, feel free to prove me wrong!).

[AhmedSalih3d]

Hi again

I do not intend to comment more on this now as agreed in #11, but I want to highlight the Dehnen & Aly link is not working for me:

Your session has timed out. Please go back to the article page and click the PDF link again.

And I would like to read it :)

You have a valid point that for the neighbour search algorithm, having a unified kernel formulation would make that easier. Perhaps we should make a pro and cons list in a few weeks from now (to allow space for thoughts to form)

Kind regards

[LudwigBoess]

Oh, sorry about the link and thanks for letting me know! :)

This one should work: Dehnen & Aly (2012)

[OndrejKincl]

Hi, I just wanted to say that I also prefer the convention of Gadget, so you are not alone. (Only that I don't call h smoothing length but support radius to avoid confusion. ) I authored SmoothedParticles.jl package where I put into documentation that the package is compatible with SPHkernels.jl. I would not be very happy if the convention suddenly changed. Of course, it would be totally fine as a backward-compatible optional variant.

[LudwigBoess]

I'm closing this issue for now, let's stick to the Gadget convention until major arguments against it come up.