-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Choose between u = r/h or q = r / (N*h) #13
Comments
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:
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 |
Oh, sorry about the link and thanks for letting me know! :) This one should work: Dehnen & Aly (2012) |
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. |
I'm closing this issue for now, let's stick to the Gadget convention until major arguments against it come up. |
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!).
The text was updated successfully, but these errors were encountered: