SPH Smoothing Formulation?
Hey everyone, Britton, Devin, and I are writing up the Trident method paper, and we wanted to be explicit about how exactly yt deposits SPH field quantities on to an octree for particle-based fields. Are there any formal equations for this written down anywhere? I realize SPH support was added since the first yt method paper, so it isn't in there, and I cannot seem to find anything in the docs. I wonder if anyone has anything written down for this or if I'm missing it somewhere? Thanks! Cameron -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
Hi Cameron, Someone else will be able to answer about the depositing but this is a little tricky since the actual kernel depends on which SPH formulation is used: some use a cubic spline, some a quintic, etc., and some have the “smoothing length” as h while other use h/2. The Springel (2003) paper though is a good place to start; iirc, he has the equation for the cubic spline (along with the definition of h) there. —Molly On September 8, 2016 at 1:43:13 PM, Cameron Hummels (chummels@gmail.com<mailto:chummels@gmail.com>) wrote: Hey everyone, Britton, Devin, and I are writing up the Trident method paper, and we wanted to be explicit about how exactly yt deposits SPH field quantities on to an octree for particle-based fields. Are there any formal equations for this written down anywhere? I realize SPH support was added since the first yt method paper, so it isn't in there, and I cannot seem to find anything in the docs. I wonder if anyone has anything written down for this or if I'm missing it somewhere? Thanks! Cameron -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Cameron, No, and I just checked, it's not in my draft of the 3.0 paper yet. It might be in a YTEP somewhere, but here's the outline. Here's what it does: * Build "mesh" octree from all the particles in a simulation * When requested, a "particle" octree is created for particle searching * Each cell in the mesh octree is iterated over; neighbor leaves in the "particle" octree are identified, and the N nearest particles are found. (This is a "gather" operation, but because the particle octree is not balanced, it is not guaranteed to find enough neighbors.) * Using the chosen SPH kernel (thanks to Bili Dong, we now have cubic, quartic, quintic, wendland2, wendland4, and wendland6), the smoothing is conducted on each cell by looking at all the nearest particles. This is implemented in the process function on the class VolumeWeightedSmooth in yt/geometry/particle_smooth.pyx I should note that Meagan Lang has implemented a particle kD-tree that she's integrating to replace the "particle" octree, which will then ensure a balanced search. She's verified that when using this, there are no longer any zero values, and it's also about the same speed, which is pretty rad. -Matt On Thu, Sep 8, 2016 at 12:42 PM, Cameron Hummels <chummels@gmail.com> wrote:
Hey everyone,
Britton, Devin, and I are writing up the Trident method paper, and we wanted to be explicit about how exactly yt deposits SPH field quantities on to an octree for particle-based fields. Are there any formal equations for this written down anywhere? I realize SPH support was added since the first yt method paper, so it isn't in there, and I cannot seem to find anything in the docs. I wonder if anyone has anything written down for this or if I'm missing it somewhere?
Thanks!
Cameron
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Thanks, Matt and Molly. Very excited to see the kd-tree formulation that Meagan has implemented. A couple additional questions: * Using the chosen SPH kernel (thanks to Bili Dong, we now have cubic,
quartic, quintic, wendland2, wendland4, and wendland6), the smoothing is conducted on each cell by looking at all the nearest particles. This is implemented in the process function on the class VolumeWeightedSmooth in yt/geometry/particle_smooth.pyx
What is the default SPH kernel that is used for deposition? Is it frontend specific (and if so, where is it defined for each frontend), or do we just use a cubic spline as default?
Also, what value is used for the smoothing length of the particle deposition? I believe most codes already have a smoothing_length field defined by the simulation. Looking in VolumeWeightedSmooth, it seems to accept a smoothing_length field for the particles but I don't know if this is the simulation-defined field. I may be wrong, but it seems to me that using the simulation-defined smoothing_length field is only applicable for the "scatter" deposition method. I thought "gather" recalculates new smoothing lengths to address the fact that you may try to sample the fluid quantities a large distance away from the nearest particles, who all may have small smoothing lengths because of their proximity to each other. But I may be mixed up here. Cameron -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
On Thu, Sep 8, 2016 at 1:07 PM, Cameron Hummels <chummels@gmail.com> wrote:
Thanks, Matt and Molly. Very excited to see the kd-tree formulation that Meagan has implemented. A couple additional questions:
* Using the chosen SPH kernel (thanks to Bili Dong, we now have cubic,
quartic, quintic, wendland2, wendland4, and wendland6), the smoothing is conducted on each cell by looking at all the nearest particles. This is implemented in the process function on the class VolumeWeightedSmooth in yt/geometry/particle_smooth.pyx
What is the default SPH kernel that is used for deposition? Is it frontend specific (and if so, where is it defined for each frontend), or do we just use a cubic spline as default?
I believe that unless an individual specifies the kernel in adding their own field, it uses cubic spline. I have not worked on that aspect of the code, but perhaps Bili Dong can say.
Also, what value is used for the smoothing length of the particle deposition? I believe most codes already have a smoothing_length field defined by the simulation. Looking in VolumeWeightedSmooth, it seems to accept a smoothing_length field for the particles but I don't know if this is the simulation-defined field.
If a smoothing length field is not provided by the simulation, it uses the N-th nearest neighbor; you can see this in the setting of hsml to the r2 value of the final particle.
I may be wrong, but it seems to me that using the simulation-defined smoothing_length field is only applicable for the "scatter" deposition method. I thought "gather" recalculates new smoothing lengths to address the fact that you may try to sample the fluid quantities a large distance away from the nearest particles, who all may have small smoothing lengths because of their proximity to each other. But I may be mixed up here.
The SPLASH paper defines the smoothing length to be a minimum computed between the cell and the smoothing length of the particle. This is what yt does, except that we don't use fixed pixel (voxel) sizes, so the min is never needed. If the particles have an inherent smoothing length, this is what is used (for instance, with Gadget datasets). If they do not (for instance, Gasoline), the Nth nearest neighbor is used. A result of this is that if you have a zoom simulation where the particles have smoothing lengths, if you are outside the maximum smoothing length distance from a particle in a region where there are no gas particles, the result is zero, because there are not particles that believe they contribute to that region. With a simulation where the formalism is such that the Nth nearest neighbor defines the smoothing length, the result will not be zero.
Cameron
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Thanks for the info on this, Matt! -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
I've just caught up with the discussion. As I discussed with Cameron today, I'd like to make a PR to make the kernel specifiable at the loading time, such that any smoothed field added to that dataset will default to use the specified kernel. More intelligently we could let each particle frontend provide its own default kernel, which could also be implemented without much difficulty. Bili On Thu, Sep 8, 2016 at 1:34 PM, Cameron Hummels <chummels@gmail.com> wrote:
Thanks for the info on this, Matt!
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I think this is a great idea. +1! On Thu, Sep 8, 2016 at 11:01 PM, Bili Dong - Gmail <qobilidop@gmail.com> wrote:
I've just caught up with the discussion. As I discussed with Cameron today, I'd like to make a PR to make the kernel specifiable at the loading time, such that any smoothed field added to that dataset will default to use the specified kernel. More intelligently we could let each particle frontend provide its own default kernel, which could also be implemented without much difficulty.
Bili
On Thu, Sep 8, 2016 at 1:34 PM, Cameron Hummels <chummels@gmail.com> wrote:
Thanks for the info on this, Matt!
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
participants (4)
-
Bili Dong - Gmail -
Cameron Hummels -
Matthew Turk -
Molly Peeples