search

LudwigBoess / SPHKernels.jl

Julia implementation of some common SPH kernels
MIT License
10 stars 0 forks source link

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

Closed LudwigBoess closed 1 year ago

LudwigBoess commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

This one should work: Dehnen & Aly (2012)

OndrejKincl commented 1 year ago

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 commented 1 year ago

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