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 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 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-particle... ). 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_Projectio...

YT Slice: http://grapenut.org/code/yt/paper/slice/slice_particles_175300_Slice_z_Metal...

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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

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 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 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 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-particle... ). 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_Projectio...

YT Slice: http://grapenut.org/code/yt/paper/slice/slice_particles_175300_Slice_z_Metal...

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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

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. 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 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 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 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-particle... ). 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_Projectio...

YT Slice: http://grapenut.org/code/yt/paper/slice/slice_particles_175300_Slice_z_Metal...

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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Unless I am mistaken, I think he is using 2.x. John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com

On Jun 5, 2014, at 7:15 PM, Matthew Turk wrote:

On Jun 5, 2014 6:10 PM, "John ZuHone" 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 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 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 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-particle... ). 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_Projectio... >> >> YT Slice: >> http://grapenut.org/code/yt/paper/slice/slice_particles_175300_Slice_z_Metal... >> >> 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@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> >> _______________________________________________ >> yt-users mailing list >> yt-users@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

---

yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org