[Yt-dev] Forked depo

gso at physics.ucsd.edu gso at physics.ucsd.edu
Tue May 10 19:53:42 PDT 2011 

I think you're 90% right there Britton, even I had to copy and paste the
info from the ellipsoid profiler output to a another text editor window to
work with it in YT, it is definitely trouble some.

If we assume that the user has to input all the information, then he will
have to give at least
center (x,y,z): 3 pieces
A: 1 piece
B: 1 piece
C: 1 piece
e1 (x,y,z): 3 pieces
e2 (x,y,z): 3 pieces

for a total of 12

If however, we take the information from the HaloProfiler output then feed
it to the ellipsoid, then you don't need center and A for a total of 8
(assuming the output of the halo and ellipsoids are listed in the same
order), but this would read from two files unless ellipsoid profiling is
done alongside hallo profiling and outputted to the same file.

I think when you said "roll angle about that vector" you had a "north" in
mind, or else there's no way to start counting for the angle of rotation,
hence I suggested having at least e1 and e2.  I'm guessing the simplest
way is that we can make it a convention to always use z axis as north, but
we run into the degenerate case if the axis pointed to z (0,0,1) already. 
Maybe have the count default to start at Y axis if the major axis is
(0,0,1)?...

So I think it is best to have e1 and e2.  Having e3 calculated on the fly
will save 3 columns off of the data file, and if we don't store the center
and A that's another 4 columns.  And if we go with the rotation angle idea
it will save another 2 out of 3 columns, replacing 3 e2 components with 1
angle.

From
G.S.

> 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
>>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>

More information about the yt-dev mailing list