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@gmail.com wrote:
Dear Geoffrey,
On Tue, May 10, 2011 at 6:16 PM, gso@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,
- I just put the calculation in the subsection of AMREllipsoidBase and
deleted the _InEllipsoid derived field.
Cool!
- 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.
- 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@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@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org