[yt-users] Particles on projections

Matthew Turk matthewturk at gmail.com
Thu Jun 5 16:15:02 PDT 2014


On Jun 5, 2014 6:10 PM, "John ZuHone" <jzuhone at gmail.com> wrote:
>
> Hi Jeremy,
>
> > I also plotted a slice with a thin slab of particles. The cells at the
center of this slice are 0.3 parsec in size. while the slab of particles
seems to have a minimum thickness that is of order 10 pc.
>
> Is there any way you can verify this? I saw you made a visit slab of
particles. Did you make one for both 0.3 pc and 10 pc and compare to the yt
image?
>
> > In an AMR simulation, if it chooses cells in a region intersecting the
slice and finds the particles within those cells, then the slab thickness
would actually vary with the cell size? Or does it choose the largest cell
size and make the slab that thick over the whole plot?
>
> The slab thickness would vary with the cell size. Someone else would have
to verify, but I suspect the reason for this design is 1) cell selection in
yt is pretty fast, probably faster than checking the positions of all the
particles against the bounds you want and 2) it was probably not
anticipated that one would want to often make slabs that are that thin.
However, it would probably be a good idea to revisit this design.

In 3, region selection on particles for flash should go:

Blocks that are inside a slab (or intersect the slab)
Particles in the slab

It should actually select particles in a slab with point based selection. I
believe the block selection should be generous enough to accomplish this as
well.

>
> Someone please correct me if I've missed something.
>
> Best,
>
> John
>
>
> > -Jeremy
> >
> >
> >> On Jun 5, 2014, at 5:29 PM, John ZuHone wrote:
> >>
> >> Hi Jeremy,
> >>
> >> I'm not sure I understand what you're getting at.
> >>
> >> Imagine you have a slice that is perpendicular to some axis of the
simulation domain, at some coordinate along that axis. It has infinitesimal
width, but it cuts through cells of finite width (which may be different in
different places according to the AMR level) across the entire plane. The
collection of these cells which the slice cuts through are the "region"
that yt gets from pf.h.periodic_region, and the particles within these
cells are the ones which end up getting plotted.
> >>
> >> Now imagine that you have a slab that has some width, centered at the
same coordinate, but that width is still much smaller than the width of any
cell. It essentially behaves exactly like the slice. You pick up the same
region, so long as the slab width is smaller than the width of the smallest
cell.
> >>
> >> So, it is actually not true that "the region containing cells for a
slice would affect particles which are not associated with the cells". The
only particles that are included are the ones within the cells that are
intersected by your slice or thin slab.
> >>
> >> So, I'm actually not clear--it sounded like at first you wanted to
make a slab the width of the entire domain. Did you want to make a very
thin slab instead?
> >>
> >> Best,
> >>
> >> John
> >>
> >>> On Jun 5, 2014, at 6:19 PM, Jeremy Ritter <jritter at astro.as.utexas.edu>
wrote:
> >>>
> >>> Hi John,
> >>>
> >>> Yes, thank you. That explanation makes things more clear. There may
very well be less refined cells at the boundary which are affecting the
size of the region. Would it then not be possible to plot fewer particles
in a narrower slab when these cells are present? Or would I need to modify
the code to use a different kind of region? It is not immediately clear to
me why the region containing cells for a slice would affect particles which
are not associated with the cells, unless that is just the way the code
happens to define the regions.
> >>>
> >>> Cheers,
> >>> -Jeremy
> >>>
> >>>> On Jun 5, 2014, at 3:17 PM, John ZuHone wrote:
> >>>>
> >>>> Hi Jeremy,
> >>>>
> >>>> Indeed, 1.0 code_length = 1.0 cm for FLASH data. So the values of
0.5, 1.0, and 2000.0 are all lengths that are far smaller than the width of
the smallest cell size.
> >>>>
> >>>> As far as why you're getting a 10pc slab, if we look at the
_get_region method in plot_modifications.py, lines 1135-1136:
> >>>>
> >>>>     self.region = data.pf.h.periodic_region(
> >>>>         data.center, LE, RE)
> >>>>
> >>>> This call will grab all of the cells that this region crosses.
Essentially, you have a very thin slab, a slice really, and regardless of
what you set that very small width to, you will always catch the individual
cells that the slice passes through. In any case, all of the cells within
these zones will be plotted, despite the fact that they may not even be
within the width of the very small slab.
> >>>>
> >>>> For FLASH data, if you want a slab the width of the domain, you
should put 2*3.0856e21 as the width in the call to annotate_particles.
> >>>>
> >>>> I agree with Nathan that the docs need to be more clear, and in yt
3.0 we should probably fix this call to annotate_particles up so that you
can specify something like (2.0,"kpc") as the width.
> >>>>
> >>>> Best,
> >>>>
> >>>> John
> >>>>
> >>>>> On Jun 5, 2014, at 3:42 PM, Jeremy Ritter <
jritter at astro.as.utexas.edu> wrote:
> >>>>>
> >>>>> Hi Nathan,
> >>>>>
> >>>>> This is FLASH data using the stable version of YT. If it's cgs
units as in the data file, then a 1.0 should show nothing rather than a
10pc slab. It seems that lowering the width doesn't have any effect either.
For slices, we are trying to plot fewer particles than the 10pc slab.
Values of 0.5, 1.0 and 2000.0 all give the same number of particles.
> >>>>>
> >>>>> I've even modified the code directly to use 1/10 of the specified
width
> >>>>>
> >>>>>    LE[zax] = data.center[zax] - self.width*0.05
> >>>>>    RE[zax] = data.center[zax] + self.width*0.05
> >>>>>
> >>>>> instead of
> >>>>>
> >>>>>    LE[zax] = data.center[zax] - self.width*0.5
> >>>>>    RE[zax] = data.center[zax] + self.width*0.5
> >>>>>
> >>>>> and they both seem to plot the exact same number of particles as
well. Is there some sort of minimum slab thickness imposed elsewhere? The
maximum grid resolution is less than 1 parsec, so that should not be a
limiting factor.
> >>>>>
> >>>>> Thanks!
> >>>>> -Jeremy
> >>>>>
> >>>>>> On Jun 5, 2014, at 1:30 PM, Nathan Goldbaum wrote:
> >>>>>>
> >>>>>> Hi Jeremy,
> >>>>>>
> >>>>>> I haven't tested this, but I think the issue is due to unit
conversions and possibly some misleading text in the docs. From my reading
of the code, I think width is in code units rather than normalized units as
the docs seem to indicate.
> >>>>>>
> >>>>>> I'm not sure which simulation code you're using, but if it uses
CGS units then the width you're specifying would be 1.0 cm.  The docs page
you link to uses an Enzo simulation - in Enzo 1.0 code length units
corresponds to the entire domain.
> >>>>>>
> >>>>>> -Nathan
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jun 5, 2014 at 10:47 AM, Jeremy Ritter <
jritter at astro.as.utexas.edu> wrote:
> >>>>>> Hello YT,
> >>>>>>
> >>>>>> When using annotate_particles() on a ProjectionPlot, it does not
seem to respect the width field. I get a very thin slab when plotting a
2kpc x 2kpc image. The cookbook implies that a width of 1.0 would
correspond to the entire 2kpc line-of-sight domain (e.g.
http://yt-project.org/docs/2.6/cookbook/complex_plots.html#plotting-particles-over-fluids
). It is definitately only a thin slab (about 10pc wide) regardless of
whether I use width=1.0 or width=2000.0. The slab thickness seems to be the
same as in a slice plot. What would be the correct way to plot the entire
2kpc cube of particles in projection?
> >>>>>>
> >>>>>> Here are some comparison plots from YT (metallicity projection and
slice) and VisIt (metallicity slice).
> >>>>>>
> >>>>>> YT Projection (Width 2kpc):
> >>>>>>
http://grapenut.org/code/yt/paper/project/project_particles_175300_Projection_z_Metallicity_Density.png
> >>>>>>
> >>>>>> YT Slice:
> >>>>>>
http://grapenut.org/code/yt/paper/slice/slice_particles_175300_Slice_z_Metallicity.png
> >>>>>>
> >>>>>> Visit (10pc slab on 2kpc x 2kpc slice):
> >>>>>> http://grapenut.org/code/yt/paper/particle_slab_0000.png
> >>>>>>
> >>>>>> YT example source:
> >>>>>> plot = ProjectionPlot(pf, 'z', nfield, center=star_center,
width=star_width, axes_unit=axunit, weight_field='Density', fontsize=32)
> >>>>>> plot.annotate_particles(1.0, ptype=1.0, col='white')
> >>>>>>
> >>>>>> Cheers,
> >>>>>> -Jeremy
> >>>>>> _______________________________________________
> >>>>>> yt-users mailing list
> >>>>>> yt-users at lists.spacepope.org
> >>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> yt-users mailing list
> >>>>>> yt-users at lists.spacepope.org
> >>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>>>
> >>>>> _______________________________________________
> >>>>> yt-users mailing list
> >>>>> yt-users at lists.spacepope.org
> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>>
> >>>> _______________________________________________
> >>>> yt-users mailing list
> >>>> yt-users at lists.spacepope.org
> >>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>
> >> _______________________________________________
> >> yt-users mailing list
> >> yt-users at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20140605/9ec326ec/attachment.html>


More information about the yt-users mailing list