Hi everyone,
I've completed the AMR3D object "ellipsoid", and I think it is ready for others to test/play with. I've forked a yt repo and followed the steps on
http://yt.enzotools.org/doc/advanced/developing.html under section "How To Submit Changes"
however, after I put in the changes, hg commit hg push went to notify the developer at http://hg.enzotools.org/yt/pull
Matt suggested that I notify people on the developer list as well, and I'm stuck on how to let others pull the changes I've made to my bitbucket repo. This is probably a hg/bitbucket question, but I'm new to this and thought you guys are probably pro at this.
How do I let others access or pull a specific changeset (676c7f17fb97) off of the repo I just forked?
Once that is setup, I'll post some scripts to plot the ellipsoid cells in 2D, 3D so people can make sure that it working.
From G.S.
Hi Geoffrey,
(Two copies of your message arrived in my inbox. Did you mean to send it twice?)
On Mon, May 9, 2011 at 11:47 PM, gso@physics.ucsd.edu wrote:
Hi everyone,
I've completed the AMR3D object "ellipsoid", and I think it is ready for others to test/play with. I've forked a yt repo and followed the steps on
http://yt.enzotools.org/doc/advanced/developing.html under section "How To Submit Changes"
however, after I put in the changes, hg commit hg push went to notify the developer at http://hg.enzotools.org/yt/pull
Matt suggested that I notify people on the developer list as well, and I'm stuck on how to let others pull the changes I've made to my bitbucket repo. This is probably a hg/bitbucket question, but I'm new to this and thought you guys are probably pro at this.
It's already all set. Your repo is public, so we can access it.
The latest version of the bootstrap method ("yt bootstrap_dev") will add a command called "addsource" to hg. This allows people to do, for instance:
hg addsource gso bb://gsiisg/yt
and then they will have the path "gso" pointing to your bitbucket repo (user gsiisg with reponame yt). Then the operation:
hg pull gso
will get all your unsynced changes.
How do I let others access or pull a specific changeset (676c7f17fb97) off of the repo I just forked?
It's already done, and just telling us where the repo is is sufficient. You can see more if you look here:
https://bitbucket.org/gsiisg/yt/compare/default..yt_analysis/yt
This includes your changeset, how to merge, and a graphical view of the diffs.
Once that is setup, I'll post some scripts to plot the ellipsoid cells in 2D, 3D so people can make sure that it working.
Please feel free to use the pastebin for this. Scripts can be downloaded programmatically from the pastebin:
yt_lodgeit.py --download=...
so it's easier on the command line for us to test things out.
Longer term, these scripts -- and others like them -- should probably have a home somewhere in the main repo.
Did you have a chance to construct success/failure of the ellipsoid scripts, or to think about some of the things that came up in the other thread?
Thanks, Geoffrey!
-Matt
From G.S.
Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi again, here's an update:
To get the ellipsoid changeset you can visit: https://bitbucket.org/gsiisg/yt/compare/default..yt_analysis/yt
two scripts, one that plots the ellipsoid in 2D xy projection http://paste.enzotools.org/show/1619/ output will be named "test.png"
and 3D http://paste.enzotools.org/show/1620/ output will be named "test3D.png"
I'm not a matplotlib expert so I haven't figured out a way to make the aspect ratio the same, if anyone found out how I'll update the scripts. Right now the script plots an ellipsoid with
center=na.array([0.9,0.9,0.9]) e1 = (1/na.sqrt(2),1/na.sqrt(2),0) e2 =(-1/na.sqrt(2),1/na.sqrt(2),0) e3 = (0,0,1) A = 0.3, B = 0.1, C = 0.05
I purposefully have the ellipsoid extend beyond the boundary to test and see if my periodic BC check is working, and I made e3=z axis so that I can make x y projections easier, but you're more than welcome to mess with those parameters... it should work for all cases (fingers crossed). If anyone finds a bug please let me know! And if anyone has any idea on how to make the code run faster I'm all ears.
From G.S.
Hi Geoffrey,
(Two copies of your message arrived in my inbox. Did you mean to send it twice?)
On Mon, May 9, 2011 at 11:47 PM, gso@physics.ucsd.edu wrote:
Hi everyone,
I've completed the AMR3D object "ellipsoid", and I think it is ready for others to test/play with. I've forked a yt repo and followed the steps on
http://yt.enzotools.org/doc/advanced/developing.html under section "How To Submit Changes"
however, after I put in the changes, hg commit hg push went to notify the developer at http://hg.enzotools.org/yt/pull
Matt suggested that I notify people on the developer list as well, and I'm stuck on how to let others pull the changes I've made to my bitbucket repo. This is probably a hg/bitbucket question, but I'm new to this and thought you guys are probably pro at this.
It's already all set. Your repo is public, so we can access it.
The latest version of the bootstrap method ("yt bootstrap_dev") will add a command called "addsource" to hg. This allows people to do, for instance:
hg addsource gso bb://gsiisg/yt
and then they will have the path "gso" pointing to your bitbucket repo (user gsiisg with reponame yt). Then the operation:
hg pull gso
will get all your unsynced changes.
How do I let others access or pull a specific changeset (676c7f17fb97) off of the repo I just forked?
It's already done, and just telling us where the repo is is sufficient. You can see more if you look here:
https://bitbucket.org/gsiisg/yt/compare/default..yt_analysis/yt
This includes your changeset, how to merge, and a graphical view of the diffs.
Once that is setup, I'll post some scripts to plot the ellipsoid cells in 2D, 3D so people can make sure that it working.
Please feel free to use the pastebin for this. Scripts can be downloaded programmatically from the pastebin:
yt_lodgeit.py --download=...
so it's easier on the command line for us to test things out.
Longer term, these scripts -- and others like them -- should probably have a home somewhere in the main repo.
Did you have a chance to construct success/failure of the ellipsoid scripts, or to think about some of the things that came up in the other thread?
Thanks, Geoffrey!
-Matt
From G.S.
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
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!
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@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
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. 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. * 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...?
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.
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?
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
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. 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. * 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...?
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.
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?
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
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
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
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@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
Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
(quoting GSO)
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.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
(Quoting GSO)
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?
(Quoting Matt's response)
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. :)
I agree with Matt on this confusion bit. But to answer your question, Geoffrey, yeah, you'll just do something like:
ct = Ell['creation_time'] select_stars = (ct > 0) star_masses = Ell['ParticleMassMsun'][select_stars]
or similarly with 'particle_type' in the first line.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
I think I want to make the changes soon, but I'm not sure if we should discuss some details off list on how to best integrate this stuff into YT. I was envisioning that the ellipsoid profiling, constructing the ellipsoid object can be integrated with your Halo profiling some how.
I'll be available again later in the afternoon after group meeting
From G.S.
Hi all,
(quoting GSO)
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.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
(Quoting GSO)
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?
(Quoting Matt's response)
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. Â :)
I agree with Matt on this confusion bit. But to answer your question, Geoffrey, yeah, you'll just do something like:
ct = Ell['creation_time'] select_stars = (ct > 0) star_masses = Ell['ParticleMassMsun'][select_stars]
or similarly with 'particle_type' in the first line.
-- 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
Hi Stephen,
(I'll just talk here until people tell me to take it off list)
The main reason why I developed the ellipsoid object is to analyze Halo statistics. I want to know how much baryon, dark matter, star particles are in each halo, without using the sphere object, because it often encloses too much extra volume.
The sphere would be a good first order approximation, but I want to go to a more accurate, more representative object ... an ellipsoid. The ellipsoids are of course not perfect, one of the big draw back is the way I construct it (not doing any N^2 operations), it also encloses some open space beyond where the particles are found (especially in the longest axis), but I think it's usually quite a bit smaller than a sphere. I'll have to run it on a big halo dataset to back the previous statement and make it convincing of course.
Ultimately I want to make the scatter plot of SFR vs the ratio of baryon_gas/DM. From preliminary results Pascal shown there's a clear correlation about how much gas there is to the amount of DM, to how much stars are forming. However, his halo region are made of rectangular boxes in IDL, not even spheres. So I want to do the same analysis in YT with the ellipsoids.
My ellipsoid profiling is done in python script form, as posted on the YT dev in a pastebin, and I probably need help to make it into a native TY function like your halo profiler. Currently: - It reads your halo profiler output object - It gets the center and x,y,z of the particles - It figures out the A, B, C, e1, 2, 3 based on those information - Then it prints all that into another file, in the same order of Haloes as your profiler output has them listed, which is sorted by mass.
Then I would feed the ellipsoid info into the ellipsoid 3D object that you've helped me look over.
How do you think I should integrate this? Should the ellipsoid profiling be done alongside the saving of the halo object as an optional thing the user can turn on, or leave it as a separate thing? If together, I'd say the information should be stored in the binary file instead of the ascii output (or else it'll be a **** TON of columns, it already has tons). If separate, then when the user wants to construct the ellipsoid objects, they would have to read in the halo object's information, set center, r_max=A, and then from the output of the ellipsoid profiler read in B, C, e1, e2, and e3 can be calculated on the fly.
Currently the user has to input center, A,B,C, e1,e2,e3 all separately, which is a lot of data. So I see cutting out center, A, e3 as a nice reduction. But maybe Britton's idea of using a rotation angle (single piece of info) in place of e2 (xyz 3 pieces of info) may be viable as well, as long as we know where to start counting and take degenerate case into account.
Which way do you think is the best way of integration, or any better ideas?
From G.S.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
I think I want to make the changes soon, but I'm not sure if we should discuss some details off list on how to best integrate this stuff into YT. I was envisioning that the ellipsoid profiling, constructing the ellipsoid object can be integrated with your Halo profiling some how.
I'll be available again later in the afternoon after group meeting
From G.S.
Hi all,
(quoting GSO)
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.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
(Quoting GSO)
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?
(Quoting Matt's response)
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. Â :)
I agree with Matt on this confusion bit. But to answer your question, Geoffrey, yeah, you'll just do something like:
ct = Ell['creation_time'] select_stars = (ct > 0) star_masses = Ell['ParticleMassMsun'][select_stars]
or similarly with 'particle_type' in the first line.
-- 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
Geoffrey,
(I'll just talk here until people tell me to take it off list)
Nah, yt development belongs on yt-dev!
How do you think I should integrate this? Should the ellipsoid profiling be done alongside the saving of the halo object as an optional thing the user can turn on, or leave it as a separate thing? If together, I'd say the information should be stored in the binary file instead of the ascii output (or else it'll be a **** TON of columns, it already has tons). If separate, then when the user wants to construct the ellipsoid objects, they would have to read in the halo object's information, set center, r_max=A, and then from the output of the ellipsoid profiler read in B, C, e1, e2, and e3 can be calculated on the fly.
There are several issues of integration discussed here. I'll do them separately:
1. Ellipsoid data storage. I agree that the ellipsoid data probably shouldn't be added to the HopAnalysis.out file by default. Most people don't want it and it would add a bunch of new columns. However, I think that if a user does want to save the ellipsoid data, it should go in the HopAnalysis.out file as added columns for each halo. And adding as many columns as necessary is fine. I think we want to avoid adding new input/output files for halos. We already have three, which is plenty by my count. This will not be terribly difficult to integrate.
2. Ellipsoid data retrieval. There are three ways that halo data is pulled off disk in yt, presently. a. In halo_objects.py, with LoadHaloes. This would not be terribly difficult to modify to support ellipsoid data columns. No problem. b. In the halo_profiler. This would also not be terribly difficult, but it raises some issues I discuss below (4). c. Halo merger tree. The ellipsoid data has no bearing on the merger tree because the merger tree doesn't care about halo shape, only particle membership.
3. Ellipsoid in halo analysis. There are several places in halo_objects.py that assumes the halo is a sphere. It won't be terribly difficult to add a switch that the user can specify that the ellipsoid should be used for analysis or data retrieval. No problem.
4. Halo profiling. If you want to profile halos using the ellipsoid container, you're going to have to think a bit about how you think it should be done. Currently, the halo profiler works using concentric spheres, binning quantities based on radius. Do you want to bin your profiles based on radius? Or concentric ellipsoid shell? If it's the latter, that's also new code that has to be written, I think.
Which way do you think is the best way of integration, or any better ideas?
I'm willing to help you with 1,2a, and 3. What I need from you is your most up to date code for defining an ellipsoid from the particles in a halo, or you can point it to me in your fork of yt. halo_objects.py is now a pretty big beast that I think I only understand fully, so I'll do the integration there. But if your ellipsoid derivation code is similar to what I saw a few weeks ago (but improved and vectorized, I hope!) in function, these three tasks won't be hard for me to do.
Task 4 I think requires you to think about how you want to analyze the halos. It sounds like you might only care about total quantities inside the halo ellipsoid, and if so, you don't need to worry about the halo profiler. But my bet is that someday someone's gonna ask for a halo profile and then you'll have to decide how you want to do that.
In summary, tl;dr, here's how I think you should do things:
1. See about implementing Britton's idea of reducing the number of parameters. You know more about this than anyone else. You can decide if it's practical or not. 2. Once that's settled, give me what I need to do steps 1,2a, and 3, above. 3. At the same time we'll merge in your ellipsoid data container.
Any other issues like bug fixes and halo profiler improvements can come later. How does this sound, Geoffrey? Any other comments from the peanut gallery?
Thanks Stephen, all of that sounds great.
I've actually never thought of plotting the profile, I guess when I wrote earlier I meant profiling as getting the attributes, not in the radial profile sense. I don't see myself needed that capability immediately, but it is possible that I may need it in the future.
If I'm going to plot a ellipsoid profile I see the intuitive thing to do is not concentric circles but concentric ellipsoids. Which means I'll plot (some quantity) vs. Normalized R, where Normalized R is just 0 to 1 on the 3 principal axes.
Should I just put it off until later or do you think it'll be a lot easier to implement it now while we're doing 1,2,3 anyway? How much "new code" is involved? If it is a lot, and since I'm lazy, I'd vote for putting it off for later :-)
From G.S.
Geoffrey,
(I'll just talk here until people tell me to take it off list)
Nah, yt development belongs on yt-dev!
How do you think I should integrate this? Â Should the ellipsoid profiling be done alongside the saving of the halo object as an optional thing the user can turn on, or leave it as a separate thing? Â If together, I'd say the information should be stored in the binary file instead of the ascii output (or else it'll be a **** TON of columns, it already has tons). Â If separate, then when the user wants to construct the ellipsoid objects, they would have to read in the halo object's information, set center, r_max=A, and then from the output of the ellipsoid profiler read in B, C, e1, e2, and e3 can be calculated on the fly.
There are several issues of integration discussed here. I'll do them separately:
- Ellipsoid data storage. I agree that the ellipsoid data probably
shouldn't be added to the HopAnalysis.out file by default. Most people don't want it and it would add a bunch of new columns. However, I think that if a user does want to save the ellipsoid data, it should go in the HopAnalysis.out file as added columns for each halo. And adding as many columns as necessary is fine. I think we want to avoid adding new input/output files for halos. We already have three, which is plenty by my count. This will not be terribly difficult to integrate.
- Ellipsoid data retrieval. There are three ways that halo data is
pulled off disk in yt, presently. a. In halo_objects.py, with LoadHaloes. This would not be terribly difficult to modify to support ellipsoid data columns. No problem. b. In the halo_profiler. This would also not be terribly difficult, but it raises some issues I discuss below (4). c. Halo merger tree. The ellipsoid data has no bearing on the merger tree because the merger tree doesn't care about halo shape, only particle membership.
- Ellipsoid in halo analysis. There are several places in
halo_objects.py that assumes the halo is a sphere. It won't be terribly difficult to add a switch that the user can specify that the ellipsoid should be used for analysis or data retrieval. No problem.
- Halo profiling. If you want to profile halos using the ellipsoid
container, you're going to have to think a bit about how you think it should be done. Currently, the halo profiler works using concentric spheres, binning quantities based on radius. Do you want to bin your profiles based on radius? Or concentric ellipsoid shell? If it's the latter, that's also new code that has to be written, I think.
Which way do you think is the best way of integration, or any better ideas?
I'm willing to help you with 1,2a, and 3. What I need from you is your most up to date code for defining an ellipsoid from the particles in a halo, or you can point it to me in your fork of yt. halo_objects.py is now a pretty big beast that I think I only understand fully, so I'll do the integration there. But if your ellipsoid derivation code is similar to what I saw a few weeks ago (but improved and vectorized, I hope!) in function, these three tasks won't be hard for me to do.
Task 4 I think requires you to think about how you want to analyze the halos. It sounds like you might only care about total quantities inside the halo ellipsoid, and if so, you don't need to worry about the halo profiler. But my bet is that someday someone's gonna ask for a halo profile and then you'll have to decide how you want to do that.
In summary, tl;dr, here's how I think you should do things:
- See about implementing Britton's idea of reducing the number of
parameters. You know more about this than anyone else. You can decide if it's practical or not. 2. Once that's settled, give me what I need to do steps 1,2a, and 3, above. 3. At the same time we'll merge in your ellipsoid data container.
Any other issues like bug fixes and halo profiler improvements can come later. How does this sound, Geoffrey? Any other comments from the peanut gallery?
-- 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
Geoffrey,
Should I just put it off until later or do you think it'll be a lot easier to implement it now while we're doing 1,2,3 anyway? How much "new code" is involved? If it is a lot, and since I'm lazy, I'd vote for putting it off for later :-)
It sounds like you don't need it, so you can put off indefinitely the idea of ellipsoidal halo profiles. So, I think you should see about minimizing the number of ellipsoid parameters. Once that's settled (one way or another) we can merge and get it out the door.
Hi Geoffrey,
Sorry for the late reply.
On Wed, May 11, 2011 at 6:42 PM, gso@physics.ucsd.edu wrote:
Hi Stephen,
(I'll just talk here until people tell me to take it off list)
The main reason why I developed the ellipsoid object is to analyze Halo statistics. I want to know how much baryon, dark matter, star particles are in each halo, without using the sphere object, because it often encloses too much extra volume.
The sphere would be a good first order approximation, but I want to go to a more accurate, more representative object ... an ellipsoid. The ellipsoids are of course not perfect, one of the big draw back is the way I construct it (not doing any N^2 operations), it also encloses some open space beyond where the particles are found (especially in the longest axis), but I think it's usually quite a bit smaller than a sphere. I'll have to run it on a big halo dataset to back the previous statement and make it convincing of course.
I think that improving the fit to the data will be dependent on how well you fit the ellipsoid to the data. If your axes are incorrectly specified, you could end up enclosing far too much mass.
A good starting point might be this paper:
http://adsabs.harvard.edu/abs/2007ApJ...671.1135K
(Kuhlen et al 2007)
which describes a method for identifying the best ellipsoidal fit to a dark matter (sub)halo.
-Matt
Ultimately I want to make the scatter plot of SFR vs the ratio of baryon_gas/DM. From preliminary results Pascal shown there's a clear correlation about how much gas there is to the amount of DM, to how much stars are forming. However, his halo region are made of rectangular boxes in IDL, not even spheres. So I want to do the same analysis in YT with the ellipsoids.
My ellipsoid profiling is done in python script form, as posted on the YT dev in a pastebin, and I probably need help to make it into a native TY function like your halo profiler. Currently:
- It reads your halo profiler output object
- It gets the center and x,y,z of the particles
- It figures out the A, B, C, e1, 2, 3 based on those information
- Then it prints all that into another file, in the same order of Haloes
as your profiler output has them listed, which is sorted by mass.
Then I would feed the ellipsoid info into the ellipsoid 3D object that you've helped me look over.
How do you think I should integrate this? Should the ellipsoid profiling be done alongside the saving of the halo object as an optional thing the user can turn on, or leave it as a separate thing? If together, I'd say the information should be stored in the binary file instead of the ascii output (or else it'll be a **** TON of columns, it already has tons). If separate, then when the user wants to construct the ellipsoid objects, they would have to read in the halo object's information, set center, r_max=A, and then from the output of the ellipsoid profiler read in B, C, e1, e2, and e3 can be calculated on the fly.
Currently the user has to input center, A,B,C, e1,e2,e3 all separately, which is a lot of data. So I see cutting out center, A, e3 as a nice reduction. But maybe Britton's idea of using a rotation angle (single piece of info) in place of e2 (xyz 3 pieces of info) may be viable as well, as long as we know where to start counting and take degenerate case into account.
Which way do you think is the best way of integration, or any better ideas?
From G.S.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
I think I want to make the changes soon, but I'm not sure if we should discuss some details off list on how to best integrate this stuff into YT. I was envisioning that the ellipsoid profiling, constructing the ellipsoid object can be integrated with your Halo profiling some how.
I'll be available again later in the afternoon after group meeting
From G.S.
Hi all,
(quoting GSO)
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.
So, where does this leave us, Geoffrey, in your opinion? Are you going to make changes soon, later, or never? Shall we merge now, or wait for changes from you?
(Quoting GSO)
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?
(Quoting Matt's response)
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. Â :)
I agree with Matt on this confusion bit. But to answer your question, Geoffrey, yeah, you'll just do something like:
ct = Ell['creation_time'] select_stars = (ct > 0) star_masses = Ell['ParticleMassMsun'][select_stars]
or similarly with 'particle_type' in the first line.
-- 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
-
Britton Smith -
gso＠physics.ucsd.edu -
Matthew Turk -
Stephen Skory