Hi all, I've attached a cool merger tree I just made up while doing some testing of the Merger Tree code. This is the tree for the most massive halo at z=0 for a recent simulation. Time goes forward from top to bottom, and you can see the redshift in the small black boxes on the right of each row. The colors of the boxes are from green to red, smallest to largest at each snapshot (so color doesn't always mean the same mass). The arrows show the parent-child relationship, and the percentages next to the arrow is how much mass of the parent went to the child. The halo info is inside each box, with the particle mass (Msol) as calculated by the halo finder and the CoM position. If you look carefully, you can see cases where a halo took more than one pass to fully integrate into the most massive halo. _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
Stephen, this is very cool. I would like to run this on one of our simulations. Is it ready to run out of the box now as described in your previous email? Or have there been changes? Thanks Eric On Mar 30, 2010, at 5:46 PM, Stephen Skory wrote:
Hi all,
I've attached a cool merger tree I just made up while doing some testing of the Merger Tree code. This is the tree for the most massive halo at z=0 for a recent simulation. Time goes forward from top to bottom, and you can see the redshift in the small black boxes on the right of each row. The colors of the boxes are from green to red, smallest to largest at each snapshot (so color doesn't always mean the same mass). The arrows show the parent-child relationship, and the percentages next to the arrow is how much mass of the parent went to the child. The halo info is inside each box, with the particle mass (Msol) as calculated by the halo finder and the CoM position. If you look carefully, you can see cases where a halo took more than one pass to fully integrate into the most massive halo.
_______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________ <0.pdf>_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Eric Hallman Google Voice: (774) 469-0278 hallman13@gmail.com
Eric,
this is very cool. I would like to run this on one of our simulations. Is it ready to run out of the box now as described in your previous email? Or have there been changes?
It hasn't given me any problems, except for a memory leak issue that appears to be particleIO related. I've been pretty good about keeping the documentation for it in the hg yt-doc up to date, so I'd recommend reading that. I think the script I sent earlier is still usable, but there are examples in the doc of how to get started. I just pushed a few changes so make sure you're up to date in the devel and doc repos. I find that if you can store the database on a real disk while it's being created things go much more quickly. If you cannot, try storing it in a folder you've striped to 0, or whatever it takes such that there isn't distributed copies of the database on the parallel disk. Depending on how many datasets you are doing, you may run out of memory during halo finding. In that case, I have just deleted the database file, and restarted the script. It will re-load already completed work into the database fairly quickly and then start back where it left off. Let me know how it goes! _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
Hi all,
It hasn't given me any problems, except for a memory leak issue that appears to be particleIO related.
I think this is fixed as of changeset f2e555c03efe in hg. The issue was that I originally designed the particle io to be a proper data object, which was a mistake. I have now modified it to simply be a reader, and this now avoids reference count cycles that required the garbage collector to be called. I think in the slightly-longer term future I'll just get rid of the particle io *object* completely. That layer is no longer necessary. If this causes other problems I didn't see when testing, well, then we have a problem -- let me know. -Matt
Hi all, I just pushed a change to the merger tree that makes things significantly faster during the halo membership comparison. It also can now deal with situations when no halos are found. It uses the fortran kd tree now, so you'll have to have that built before trying this. _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
participants (3)
-
Eric Hallman -
Matthew Turk -
Stephen Skory