[Yt-dev] AMR3D

Thu May 5 20:21:54 PDT 2011

Hi Geoffrey,

It might be easier if you forked the repository on BitBucket and
committed your changes, so that we don't have to copy paste, but we
can still edit the code.

I would also suggest that you develop a small test that uses "assert"
to determine whether or not the behavior is correct.  For instance,
this test could verify that the cells included in an ellipse that's
definedi dentically to a sphere have the same included cells; you
could also try rotating the ellipse vectors but retaining the same
axial lengths.  This way, we can run the test and see if it passes.
This will be much easier and less prone to error than manual
inspection, and we can also use it on AMR datasets as well.

So please feel free to fork the repository, add your code, and
pastebin your test script and we can have at it.

Also, my feeling is that the InEllipsoid field is likely not
necessary; I think we can get around it during the masking phase in a
similar way as is done in the cylinder -- just by calculating the mask
right then and there.  The utility of an all-new field is likely not
high outside of the Ellipsoid.  :)

Good work, and let us know,

Matt

On Thu, May 5, 2011 at 5:37 PM,  <gso at physics.ucsd.edu> wrote:
> 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
>>
>
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>