[Yt-dev] AMR3D

Thu May 5 17:37:18 PDT 2011

Thanks for the help Matt and Britton,

I think I understand the cut mask thing now, and the stumbling block I was
having is due to the fact that when I did the checking, I made another
array instead of operating on grid, so although I had the same number of
elements, I either lose/gain some elements or ended up with a different
shape, so I changed it to the way RadiusCode was calculated and now it
works!

However, I was comparing my ellipsoid to the sphere object, and if I
define an ellipsoid the same size/shape/location as the sphere, in my 64
cube run
SP=pf.h.sphere((0.5,0.5,0.5),0.1)
sp=pf.h.ellipsoid(
array([0.5,0.5,0.5]), \
(1,0,0), \
(0,1,0), \
(0,0,1), \
0.1, 0.1, 0.1)
gave me two objects, both of which have 1088 cells, but out of those 1088
about 230 of the cells are shifted by 1 cell over, I'm wondering if that's
something I should be worried about.

Another separate question
sp.quantities["TotalQuantity"]("CellVolumeCode")[0] works just fine, along
with other fields such as "Density", "HI_Density", "Temperature", but I am
not sure why "ParticleMassMsun" isn't working, can someone show me how
that is working for the sphere so I can learn from that?

If anyone is bored and want to try the 3D ellipsoid object out:
http://paste.enzotools.org/show/1614/
You just have to copy the first portion and paste it in data_containers.py
paste the second portion into universal_fields.py
in src/yt-hg/ directory run >python setup.py install

I guess eventually I'll want to make this into a change set (if there are
ppl that wants this functionality), but not before I test it out with some
other data first.

From
G.S.

> Hi Geoffrey,
>
> Thanks for the writeup.  An ellipsoidal region would be very useful.
>
> On Thu, May 5, 2011 at 2:31 AM,  <gso at physics.ucsd.edu> wrote:
>> Hi all,
>> I've been trying to develop an ellipsoid container for YT to wrap around
>> the particles from the halo profiler as an object.  I think I am stuck
>> because I don't quite understand parts of the code.
>
> From reading your email and the code, I'm not really sure that this is
> true.  ;-)  You seem to get most/all of it.
>
> As a quick sidenote, when writing stuff like this, it's often helpful
> to use pdb or IPython to drop yourself into the code to inspect it.
> You can use either:
>
> import pdb;pdb.set_trace()
>
> or
>
> insert_ipython() # a yt-specific command
>
> to get more detailed looks at code.
>
>>
>> I'll try walk through sections of AMRSphereBase describing my
>> understanding of the code.  I have the corresponding portion for the
>> ellipsoid I wrote up at this URL to compare with the sphere:
>> http://paste.enzotools.org/show/1611/
>>
>> So please correct my misunderstanding of each section
>>
>> in _get_list_of_grids(self, field = None):
>> -This section is trying to get a list of root grid tiles that may have
>> data within the sphere.
>
> Nope, ALL grid tiles.
>
>> - It determines the grids with find_sphere_grids().
>
> Yup.
>
>> - It changes them to a list.
>
> Yes, but I can't remember why.
>
>> - It sorts them by level then x y z.
>> - It returns the list as an array.
>
> Yes, this sounds right.  Sorting by level is not strictly necessary.
>
>>
>> in _is_fully_enclosed(self, grid):
>> -This section is to see if the grids have all corners inside the sphere.
>> - It finds the absolute displacement of each component of the corner
>> from
>> center.
>> - It finds the shortest path considering periodic BC.
>> - It finds the distance in 3D of the corner from the center of sphere.
>> - It returns true if all corners are within sphere, false if not.
>
> Yes.
>
>>
>> in _get_cut_mask(self, grid, field=None):
>> I have a conceptual question here, what does cut mask mean? My
>> impression
>> from the code is that if the cell is part of the object it becomes part
>> of
>> the cut mask(cm=cutmask)?
>> -This section is the place that determines if each individual cells
>> within
>> the possible grids is inside the sphere.  (I have a feeling I'm
>> completely
>> wrong on this point)
>> - It returns True if the grid is fully enclosed, skip checking for child
>> mask.
>> - It check if grid is not the same type as FakeGridForParticles,
>> GridChildMaskWrapper (which means it hasn't been cached yet) and if grid
>> is already part of the cut mask, if so return the cut mask as is.
>> - Check which of the cells in grids are part of the sphere as well as
>> child mask and assign it to cut mask
>> - Last, after cut mask is calculated, it check if it hasn't been cached
>> yet, if not, cache it to self._cut_mask[grid.id]
>> - Returns the cut mask
>
> Sounds about right; Britton's email (which just showed up, but I'm
> already mostly through mine! :) has more info about this.
>
>>
>> To emulate what's done by calling "RadiusCode", at first I thought of
>> trying to define another derived quantity call it "EllipseIn" and
>> calculate the eqn of the ellipsoid (<1 in, >1 out) at another place, but
>> in the end I thought I might as well just do the calculation on the
>> spot.
>> Unfortunately, I ran into some trouble with the dimension of the x,y,z.
>
> I think you made the right decision with this.  RadiusCode was a
> convenience issue.  One could work with EllipsoidA, EllipsoidB,
> EllipsoidC, but I don't think it's necessary.  (On that note, I would
> suggest you manually ensure that A,B,C are in decreasing order of
> value, to ensure your axes are correctly ordered.
>
>>
>> I am still kind of fuzzy on how _get_cut_mask iterates through the cells
>> in the grid and flag them as part of the object.  It seem
>> self._cut_mask=cm where cm are just a bunch of True and False won't give
>> information on which cell is being considered.  That's why I was
>> concerned
>> that maybe this isn't the place sphere check for cells either.
>
> The actual *usage* of the cut masks is elsewhere; to define a new
> datatype, we don't have to alter the underlying machinery of how
> datatypes work.  You just need to implement the spec.
>
> Good luck, and let us know if you run into other issues!
>
> -Matt
>
>>
>> Any expert help on AMR3D is greatly appreciated.
>>
>> From
>> G.S.
>>
>>
>> _______________________________________________
>> Yt-dev mailing list
>> Yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>