Mailman 3 rockstar - yt-dev

rockstar

Stephen Skory

3 Sep 2012 3 Sep '12

3:28 p.m.

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. 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-up...) 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: - 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). - 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. - 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. 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. Thanks! -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)

Show replies by date

Stephen Skory

3 Sep 3 Sep

3:32 p.m.

Hi again, I realized that I never actually properly stated a question, although it's strongly implied. Is there anything that I'm doing obviously wrong? Also - if you're willing to help out, let me know and we can see if you can replicate the crash. This is on Mac OS X, and I seem to remember something about it working on Linux for Chris & Matt, but I see no reason why it shouldn't work on Mac, too. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)

Geoffrey So

6:48 p.m.

Hi Stephen, I am very interested in using Rockstar within YT once it's in production, but I'm not sure how much help I can provide. I can certainly test things out your mods on my test datasets, which, like your datasets also do not have the particle_type field. I'm currently running on an old OS X 10.7.4 Lion installation on my laptop, so not the latest (have you upgraded to Mt. Lion?). Do I just download and install a new yt dev and pull the changes from your first email to get all the changes? Can you also paste the script somewhere so I can try it quickly, see if I get the same error? From G.S. On Mon, Sep 3, 2012 at 12:32 PM, Stephen Skory wrote:

...

Hi again,

I realized that I never actually properly stated a question, although it's strongly implied. Is there anything that I'm doing obviously wrong? Also - if you're willing to help out, let me know and we can see if you can replicate the crash. This is on Mac OS X, and I seem to remember something about it working on Linux for Chris & Matt, but I see no reason why it shouldn't work on Mac, too.

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

Matthew Turk

10:27 p.m.

Hello Stephen, * Stephen Skory [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-up...) 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@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

Christopher Moody

4 Sep 4 Sep

12:54 a.m.

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 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-up... )

...
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@skory.us javascript:; http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Stephen Skory

5 Sep 5 Sep

9:13 a.m.

Hi Matt,

...

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.

Sorry about forgetting to reply to this question. Yes, I'll be on IRC this afternoon. But if you have more pressing matters, and because Chris isn't readily available, we can do it another time. I'm easy! -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)

Matthew Turk

1:35 p.m.

Hi Stephen, On Wed, Sep 5, 2012 at 9:13 AM, Stephen Skory wrote:

...

Hi Matt,

...
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.

Sorry about forgetting to reply to this question. Yes, I'll be on IRC this afternoon. But if you have more pressing matters, and because Chris isn't readily available, we can do it another time. I'm easy!

Okay, let's hold off until Chris gets back, and let's allow a bit of leeway for his jet lag. Chris, would you be up for maybe a hangout on Wednesday or Thursday next week? I will prepare an agenda if so. -Matt

...

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

Christopher Moody

4:25 p.m.

Hi Matt & Stephen, Wednesday's already chock full of meetings. How about Thursday of next week? chris On Thursday, September 6, 2012, Matthew Turk wrote:

...

Hi Stephen,

On Wed, Sep 5, 2012 at 9:13 AM, Stephen Skory javascript:;> wrote:

...
Hi Matt,

...
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.

Sorry about forgetting to reply to this question. Yes, I'll be on IRC this afternoon. But if you have more pressing matters, and because Chris isn't readily available, we can do it another time. I'm easy!

Okay, let's hold off until Chris gets back, and let's allow a bit of leeway for his jet lag. Chris, would you be up for maybe a hangout on Wednesday or Thursday next week? I will prepare an agenda if so.

-Matt

...
-- Stephen Skory s@skory.us javascript:; http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

4:27 p.m.

Sounds good to me. Thursday, 5:30PM Eastern work for everyone? -Matt On Wed, Sep 5, 2012 at 4:25 PM, Christopher Moody wrote:

...

Hi Matt & Stephen, Wednesday's already chock full of meetings. How about Thursday of next week?

chris

On Thursday, September 6, 2012, Matthew Turk wrote:

...
Hi Stephen,

On Wed, Sep 5, 2012 at 9:13 AM, Stephen Skory wrote:

...
Hi Matt,

...
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.

Sorry about forgetting to reply to this question. Yes, I'll be on IRC this afternoon. But if you have more pressing matters, and because Chris isn't readily available, we can do it another time. I'm easy!

Okay, let's hold off until Chris gets back, and let's allow a bit of leeway for his jet lag. Chris, would you be up for maybe a hangout on Wednesday or Thursday next week? I will prepare an agenda if so.

-Matt

...
-- 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

Stephen Skory

4:59 p.m.

...

Sounds good to me. Thursday, 5:30PM Eastern work for everyone?

For me, yes. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)

Christopher Moody

6 Sep 6 Sep

12:29 a.m.

Yep, 2:30pst works for me! Chris On Thursday, September 6, 2012, Stephen Skory wrote:

...

...
Sounds good to me. Thursday, 5:30PM Eastern work for everyone?

For me, yes.

-- Stephen Skory s@skory.us javascript:; http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

4247

Age (days ago)

4250

Last active (days ago)

List overview

Download

10 comments

4 participants

participants (4)

Christopher Moody
Geoffrey So
Matthew Turk
Stephen Skory

rockstar

Stephen Skory

Stephen Skory

Geoffrey So

Matthew Turk

Christopher Moody

Stephen Skory

Matthew Turk

Christopher Moody

Matthew Turk

Stephen Skory

Christopher Moody

tags

participants (4)