[Yt-dev] Forked depo

Britton Smith brittonsmith at gmail.com
Tue May 10 19:26:31 PDT 2011 

I want to reiterate Matt's point about the amount of information needed to
describe the ellipsoidal object.  I think we really need to make sure that
we are not requiring the user to enter more information than is necessary to
describe a 3D object.  Asking for redundant information creates additional
points of failure where there need not be.  Currently, other than the center
of the object, it looks like the ellipsoidal object requires 12 pieces of
information: the x, y, z components for all three axes of the ellipsoid, as
well as the A, B, and C.  Unless I am mistaken, only 6 pieces of information
are actually necessary: the x, y, z components of the vector for the
semimajor axis, the roll angle about that vector, and the values of B and C.

Maybe, as Matt said, you should go with it as it stands for now, but I
really think that fixing this should be a high priority.

Britton

On Tue, May 10, 2011 at 9:53 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Dear Geoffrey,
>
> On Tue, May 10, 2011 at 6:16 PM,  <gso at physics.ucsd.edu> wrote:
> > Thanks for the suggestions Stephen and Matt,
> >
> > Stephen,
> > * I fixed up the dim so that it now take into account the possibility of
> > different root grid tile dimensions, in cases when it is not a cube.
> > * Edited/added more comments.
> > * I tried my scatter3D.py and it works on my laptop with python 2.7, has
> > anyone else tried?
> >
> > Matt,
> > 1) I just put the calculation in the subsection of AMREllipsoidBase and
> > deleted the _InEllipsoid derived field.
>
> Cool!
>
> > 2)
> > * I think I would leave it as the e1,2,3 basis vectors for now, because
> > the way I am doing the Ellipsoid profiling from the Halo profiles, I
> don't
> > use rotations of any kind, so everything is done vector wise, and the
> > results from that will be fed into the ellipsoid object, so at least it
> > would be easier for me to use e1,2,3.
>
> Okay.  Let's keep an eye on this and see if we can, in the future,
> reduce the over-determination of the object.
>
> > * For an arbitrarily aligned orthogonal basis vector set, I think you'll
> > need 3 rotations to align it to another generic orthogonal basis vector
> > set, so only Phi and Theta would be insufficient.
> > * However, I would only need to record e1, and e2, and just calculate e3
> > (e1 cross e2) on the fly at the start of the calculation.  Should I just
> > record e1 and e2 or leave it in the file, saves some space...?
>
> Leave it for now, but again, let's revisit this in a little while.  My
> feeling is that likely the generation of ellipsoids from halo objects
> will be the primary entry point for the foreseeable future.
>
> >
> >
> > A few questions:
> >
> > after defining the ellipsoid "ell"
> > ell.quantities["TotalQuantity"]("CellMassMsun")
> > works fine, but when I change CellMassMsun to ParticleMassMsun, I get the
> > following errors, Traceback pasted to
> > http://paste.enzotools.org/show/iZ1Ww36ZLFob49xWBfU1
> > Is that a bug in my code?  I am not quite sure how to fix it.
>
> I'll fix this after we merge the code.
>
> >
> > Ultimately I'd want to analyze the DM and star particles in the ellipsoid
> > separately, do I just use the derived field and particle ages to do that
> > once the previous problem is solved?
>
> I'll defer to someone else on this.  The way stars are differentiated
> in Enzo -- although other codes seem to have gotten this right -- bugs
> me in its inconsistencies.  (i.e., ages versus ParticleType.  Not a
> fault of enzo, really, just inconsistent conventions for running
> simulations.  :)
>
> Nice work, Geoffrey.  Stephen, once you and Geoffrey have adapted the
> changes above, I am +1 on merging, so feel free to do so unless
> someone else here objects.
>
> -Matt
>
> >
> > From
> > G.S.
> >
> >
> >
> >
> >> Hi Geoffrey,
> >>
> >> Other than Stephen's issue, I have two suggestions then I am +1 for
> >> merging.
> >>
> >> 1) Remove the InEllipsoid field and put that code directly into the
> >> masking routine.
> >> 2) Minimally define the Ellipse -- right now it's a bit over-defined,
> >> in that you have all three unit vectors and all three axis lengths.
> >> Maybe A,B,C,theta,phi?
> >>
> >> This will be a great addition.  And, I don't think I've said this yet,
> >> but congrats on your first commit to yt!  Thanks very much.
> >>
> >> -Matt
> >>
> >> On Tue, May 10, 2011 at 2:54 PM, Stephen Skory <s at skory.us> wrote:
> >>> Geoffrey,
> >>>
> >>>> To get the ellipsoid changeset you can visit:
> >>>> https://bitbucket.org/gsiisg/yt/compare/default..yt_analysis/yt
> >>>
> >>> I scanned this and I didn't see anything glaringly wrong. You might
> >>> want to change the comment block below class
> >>> AMREllipsoidBase(AMR3DData) to match an ellipsoid ;). Anyway, very
> >>> good work!
> >>>
> >>> I did run your scripts, and I ran into a couple issues. First, in
> >>> _InEllipsoid, I had to make this change to avoid a crash:
> >>>
> >>> diff -r 676c7f17fb97 yt/data_objects/universal_fields.py
> >>> --- a/yt/data_objects/universal_fields.py       Mon May 09 20:46:16
> 2011
> >>> -0700
> >>> +++ b/yt/data_objects/universal_fields.py       Tue May 10 15:52:39
> 2011
> >>> -0600
> >>> @@ -944,7 +944,7 @@
> >>>         # allocate array to be filled with results from eqn of
> ellipsoid
> >>>         Inside = na.zeros(data["x"].shape, dtype='float64')
> >>>         # find the dimension length of the grid
> >>> -        dim = shape(data["x"])
> >>> +        dim = data["x"].shape
> >>>         # allocate array for the dot product with the 3 e_vectors
> >>>         # need to take into account different grid side sizes
> >>>         dot_evec = na.zeros([3,dim[0],dim[1],dim[2]])
> >>>
> >>> Second, I didn't see anything in the test3D.png image... I haven't
> >>> looked into why, but the 2D image looked encouraging!
> >>>
> >>> Again, good work!
> >>>
> >>>
> >>> --
> >>> Stephen Skory
> >>> s at skory.us
> >>> http://stephenskory.com/
> >>> 510.621.3687 (google voice)
> >>> _______________________________________________
> >>> 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
> >
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110510/07bf523f/attachment.htm>

More information about the yt-dev mailing list