Hi Josh, Yes, the Petkova method is now implemented by default for interpolation to 2D and 3D meshes (i.e. when using splash to grid).
Happy to report that the column density version is also now implemented, but it is a bit slower (~10s of seconds) so only enabled when the “use exact rendering” option is set from r)ender/use normalised interpolations (there’s an extra prompt). The basic improvement is that the interpolation now conserves mass to high accuracy. Main optimisation I made was to only do the exact interpolation when a particle contributes to a small number of pixels. This also means it scales very well with pixel number. Low pixel numbers are cheap anyway, and high pixel numbers do not need exact interpolation. With a bit more optimisation I’m hoping to make the exact rendering default. Best wishes, Daniel > On 6 Feb 2020, at 8:53 pm, BORROW, JOSHUA J. <[email protected]> > wrote: > > Hi Daniel, > > Interesting idea about the max(h, 0.5 * dx); currently what I do is if a > particle has H = gamma * h < 0.5 * dx I simply add on the mass of this > particle to the pixel that it lives within; this helps conserve the mass much > better at the high density end. > > Have you had any more success with the Petkova+ overlaps? > > Cheers, > Josh > > P.S. Sorry for my slow response... > >> On 4 Dec 2019, at 00:41, Daniel Price <[email protected]> wrote: >> >> Hi Josh, >> >> Good question! Since splash is a visualisation tool I am happy with this >> level of approximation. When it becomes tricky is when the particles are >> unresolved by the pixels. Here we do something simple, just take >> max(h,0.5*dx) as the smoothing length. This is quick but does *not* conserve >> mass. >> >> A simple (and cheap) solution is to use more pixels. The *right* way to do >> it is to use the analytic integrals for the kernel overlap, e.g. following >> Maya Petkova’s work >> >> http://adsabs.harvard.edu/abs/2018JCoPh.353..300P >> >> We have been working to incorporate this in splash (currently in 2D and for >> 3D grids, but not yet for column densities), but it is a lot slower (~20x) >> than the default method. >> >> Best wishes, >> >> Daniel >> >> >>> On 9 Nov 2019, at 3:09 am, BORROW, JOSHUA J. <[email protected]> >>> wrote: >>> >>> Hi Daniel, >>> >>> Hope you're well! >>> >>> I have a quick question about the SPH rendering that you do in SPLASH. >>> We're currently trying to fix some problems in our home-grown renderers, >>> and we've come across some interesting behaviour. >>> >>> When splattering a kernel, the outermost wings do not (for us) contribute >>> to the pixels that they live within (fig. 7 of >>> https://www.cambridge.org/core/services/aop-cambridge-core/content/view/20C22A93AB1CD3ADC1F5B8439B639A24/S1323358000003672a.pdf/splash_an_interactive_visualisation_tool_for_smoothed_particle_hydrodynamics_simulations.pdf); >>> see attached - the pink areas do not actually contribute to those pixels. >>> >>> What we do is loop over all relevant pixels, and find the kernel W(r, h) >>> where r is the distance between the particle and the pixel centre. Then, >>> for the outer-most pixels, we always find W = 0, even though there is >>> overlap between the kernel and this pixel. This becomes a problem when the >>> sizes of pixels are roughly similar to the smoothing lengths, as in that >>> case you can loose quite significant contributions - we've seen errors of >>> ~25% in tests. >>> >>> What I'm wondering is if you have some way of including these contributions >>> in a computationally efficient way? I tried to read SPLASH's source code >>> but I must admit that I am no FORTRAN programmer... >>> >>> Cheers, >>> Josh >>> >>> >>> <Screenshot 2019-11-08 at 16.06.38.png> >> >> <Screenshot 2019-11-08 at 16.06.38.png> > -- You received this message because you are subscribed to the Google Groups "SPLASH users forum" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/splash-users/2CEB7EED-2141-4B87-B5BC-0033AAC8A17F%40monash.edu.
