[yt-dev] rockstar

Matthew Turk matthewturk at gmail.com
Mon Sep 3 19:27:53 PDT 2012


Hello Stephen,

* Stephen Skory <s at skory.us> [120903 15:28]:
> Hi all (especially Chris & Matt),
> 
> this morning I've spent some time trying to get rockstar to work for
> me, and I've made some progress, I think, but I'm getting answers I
> don't trust, and a crash, besides, so there's more to be done.

I agree -- and I appreciate you taking a look at this.  I am growing
increasingly positive that the only way to make substantive improvement in
projects like yt is to have investments and interest from multiple individuals,
not just as a sanity check but also as a mechanism for encouraging and spurring
development.  So, let's do this.

> 
> What I've done is to pull and merge Chris' current PR for rockstar
> (https://bitbucket.org/yt_analysis/yt/pull-request/247/art-rockstar-camera-updates)
> into a copy of the current tip of yt. Then upon that, I've made the
> following changes (http://paste.yt-project.org/show/2671/). In
> particular, here's the substantive things I've done:

For what it's worth, this pull request is still somewhat in limbo.  Chris has
been traveling for some time, but I hope we can return to it soon.

> 
> - I modified the part of RockstarHaloFinder.__init__ that finds the
> total number of particles to work in parallel (meaning, not all the
> particles are loaded on all processors).

This is what the processor pool does.

> 
> - I am running on only one data output in my time series. I think this
> is why I've had to comment out one of the ProcessorPool() blocks, but
> frankly, I don't really understand the ProcessorPool stuff. If I keep
> both blocks, the second one in the sequence complains that there are
> no workers available.

The processor pool system is to divide into workers and readers.  With Rockstar,
the IO nodes and the computation nodes are separate.  The processor pool
mechanism accomplishes this.

> 
> - My test data does not have the 'particle_type' field, which the
> rockstar wrapper was relying on. I've made a few changes that
> basically assume that if there is no 'particle_type' field, everything
> is a DM particle (which is the case for my test data). This has
> required a few changes in rockstar.py and rockstar_interface.pyx (look
> for the rh.dm_type stuff).
> 
> With these changes, I can get some stuff to run. Here are the most
> interesting lines I see:
> 
> [     0s] Accepting connections...
> [     0s] Accepted all reader / writer connections.
> [     0s] Verified all reader / writer connections.
> [     0s] Reading 1 blocks for snapshot 0...
> (snip)
> reading from particle filename ./inline.0: data0012
> [    21s] Transferring particles to writers...
> [    22s] Analyzing for halos / subhalos...
> [    33s] Constructing merger tree...
> [    33s] [Success] Done with snapshot 0.
> 
> Immediately after this I see some unhelpful crash error messages.

That does sound unhelpful.

> 
> I do get a "halos_0.0.ascii" file (and some other stuff) in my
> xxx_rockstar directory, but the centers of mass for the halos are very
> fishy (and likely everything else). I think this might be related to
> the fact that I'm getting a crash. I think that the centers are fishy
> because, for example, the largest halo in the rockstar text file is no
> where near the largest that HOP finds, although they do have a similar
> number of particles.
> 
> There was a bit of momentum on rockstar a couple weeks ago, and I'm
> hoping that we can try to get this thing working. I can share the
> dataset I'm using for my tests, if anyone wants it (it's similar to
> one of the compendium datasets, if not identical), and my script as
> well.

I'd be very keen to push forward on the Rockstar stuff, or at the very minimum,
walk through every line of code in it, describe how it interfaces with Rockstar,
and give suggestions and code review for how to go forward.  Unfortunately my
time is otherwise occupied until at least the middle of next week and I cannot
dedicate time to actively developing it until then.

The items you have described all sound to me like genuine issues with the
Rockstar interface.  I am somewhat confused as to why the original, pre-PR
interface did not work for you, and I'm even more confused why the particle
number would remain the same while the values calculated for the halo differ.

I have an outstanding fork with changes to Rockstar that require patching the
Rockstar source.  Peter suggested we add Rockstar to the download script, which
means we can also apply a handful of patches.

On Wednesday I should be able to talk to you about this in detail in IRC.  Would
you be available around 3PM Eastern?  Anyone else interested can hang out in #yt
as well.

-Matt

> 
> Thanks!
> 
> -- 
> 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



More information about the yt-dev mailing list