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.
On Tue, May 10, 2011 at 6:16 PM, <email@example.com> wrote:
> Thanks for the suggestions Stephen and Matt,
> * 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?
> 1) I just put the calculation in the subsection of AMREllipsoidBase and
> deleted the _InEllipsoid derived field.
Okay. Let's keep an eye on this and see if we can, in the future,
> * 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.
reduce the over-determination of the object.
Leave it for now, but again, let's revisit this in a little while. My
> * 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...?
feeling is that likely the generation of ellipsoids from halo objects
will be the primary entry point for the foreseeable future.
I'll fix this after we merge the code.
> A few questions:
> after defining the ellipsoid "ell"
> works fine, but when I change CellMassMsun to ParticleMassMsun, I get the
> following errors, Traceback pasted to
> Is that a bug in my code? I am not quite sure how to fix it.
I'll defer to someone else on this. The way stars are differentiated
> 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?
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
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.
>> Hi Geoffrey,
>> Other than Stephen's issue, I have two suggestions then I am +1 for
>> 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.
>> On Tue, May 10, 2011 at 2:54 PM, Stephen Skory <firstname.lastname@example.org> wrote:
>>>> To get the ellipsoid changeset you can visit:
>>> 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
>>> +++ b/yt/data_objects/universal_fields.py Tue May 10 15:52:39 2011
>>> @@ -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,dim,dim])
>>> 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
>>> 510.621.3687 (google voice)
>>> Yt-dev mailing list
>> Yt-dev mailing list
> Yt-dev mailing list
Yt-dev mailing list