[yt-dev] rockstar

Mon Sep 3 21:54:12 PDT 2012

Hi everyone,
As Matt said, I'm still traveling and won't be able to look at this until
at least September 9. The issues you brought up are worrisome, and I'm
 sorry to leave this in an unfinished state! At any rate, I'll look at this
when I'm back.

chris

On Tuesday, September 4, 2012, Matthew Turk wrote:

> Hello Stephen,
>
> * Stephen Skory <s at skory.us <javascript:;>> [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 <javascript:;>
> > http://stephenskory.com/
> > 510.621.3687 (google voice)
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org <javascript:;>
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org <javascript:;>
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120904/f8b51b66/attachment.html>