[FLASH-USERS] Particle defaults

Mark L Richardson Mark.L.Richardson at asu.edu
Wed Apr 25 14:33:37 EDT 2012


Hi Sean,
  I began working with Paul last summer to get a better version of the
particle mapper working. First, it allows for a particle to be mapped to a
lower resolution in the event that the particle count in that region is
very diffuse. Essentially, this lets you have high resolution gas with a
still diffuse dark matter field. At first the third law was still being
violated.

This has all been coded, but we're still doing a few tests, and there's
still an issue between grid resolutions. Essentially the noise is high at a
boundary, although Newton's 3rd is now respected.

The easiest way to avoid all of this is to do a refine on particle count,
as John pointed out. Unfortunately this means you can't have high
resolution in diffuse regions. If instead you want to look in to the
particle mapping that I was working on, we can plan to discuss that more.

Cheers,
  -Mark

On Wed, Apr 25, 2012 at 11:09 AM, John ZuHone <
jzuhone at milkyway.gsfc.nasa.gov> wrote:

> Hi Sean,
>
> > I'd like to know how Flash handles jumps in refinement when calculating
> the acceleration between two particles?
>
> Unfortunately, at this time the public version of FLASH really doesn't
> "handle" it. I am guessing that you are referring to the violation of
> Newton's Third Law that occurs when particles interacting across a
> refinement boundary have their forces interpolated and their masses mapped
> according to a kernel with a width equal to the cell size on each
> particle's refinement level. Right now the public version of FLASH doesn't
> account for this, and so you will get some violations of the 3rd Law at
> refinement boundaries. In practice, these are typically very small when
> compared to the mean field when you have lots of particles, but this is not
> true for all applications.
>
> Paul Ricker has written some code to handle this, but I don't know if it's
> public. You can reach him at pmricker at illinois.edu. Paul, I wonder if
> it's time to get this into the main code?
>
> > Also, how does the runtime parameter 'refine_on_particle_count' work and
> how does it differ from setting 'refine_var_n' equal to "pden".
>
> Since the "refine_var_n" runtime parameters turn on the second derivative
> refinement criteria for the given variable, setting it to "pden" will mean
> that whenever "pden" is fairly discontinuous (which is usually just about
> everywhere) you will refine. This is probably not the behavior you are
> looking for.
>
> refine_on_particle_count is probably your best bet, since it will turn on
> refining and derefining for certain numbers of particles per block that you
> can specify, the relevant parameters being max_particles_per_blk and
> min_particles_per_blk.
>
> Best,
>
> John ZuHone




-- 
Mark Richardson,
Mark.L.Richardson at asu.edu
Ph.D. Candidate: Astrophysics
PSF 271
School of Earth and Space Exploration
Arizona State University
480 318-4449
www.public.asu.edu/~mlricha4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20120425/9aaa4eae/attachment.htm>


More information about the flash-users mailing list