Hey Matt. The changes in the Nyx frontend look good to me, but you're right that I'll have to test it. Is it sufficient to compare multilevel slices before and after the changes? - Casey On Thu, Sep 20, 2012 at 8:30 AM, Matthew Turk wrote:

Hi all (but especially Casey and Tom Robitaille if he's still subscribed :),

Andrew Myers found a very nice solution to issue #414:

https://bitbucket.org/yt_analysis/yt/issue/414/orion-ghot-zones-not-generati...

which he's put in this PR:

https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-eac...

I have only limited access to Nyx / Orion data with subgrids, so I can't test this appropriately. I think the changes look good, however, so if I can get from any other boxlib user that they still produce good results, I will accept them. This is also a good time to mention that going forward I hope to consolidate the various boxlib readers.

Best,

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

Hi Casey, I think your and Andrew's intutions are correct. Another good sanity check would be to check the before/after values of calculating: dd = pf.h.all_data() dd.quantities["TotalQuantity"]("CellVolume") I think as long as this is the sae, and the slices are all set, it should be all good. The changes I think are quite good and should only change (by helping) at the level of just above roundoff error. -Matt On Thu, Sep 20, 2012 at 6:49 PM, Andrew Myers wrote:

Hi Casey,

Someone more knowledgeable than myself should confirm, but I would guess that if I screwed up something with the 'dx' fields it would be fairly blatant, such that a multi-level slice or projection would catch it. I've been working with Orion data sets for about a week with this change, and it seems fine, so I think we just need a basic sanity check for the other frontends.

-Andrew Myers

On Thu, Sep 20, 2012 at 3:13 PM, Casey W. Stark wrote:

...

Hey Matt.

The changes in the Nyx frontend look good to me, but you're right that I'll have to test it. Is it sufficient to compare multilevel slices before and after the changes?

- Casey

On Thu, Sep 20, 2012 at 8:30 AM, Matthew Turk wrote:

...

Hi all (but especially Casey and Tom Robitaille if he's still subscribed :),

Andrew Myers found a very nice solution to issue #414:

https://bitbucket.org/yt_analysis/yt/issue/414/orion-ghot-zones-not-generati...

which he's put in this PR:

https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-eac...

I have only limited access to Nyx / Orion data with subgrids, so I can't test this appropriately. I think the changes look good, however, so if I can get from any other boxlib user that they still produce good results, I will accept them. This is also a good time to mention that going forward I hope to consolidate the various boxlib readers.

Best,

Matt _______________________________________________ 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 Casey, Ah, I saw this the other day when we were IO stress testing on EC2. It's a super simple fix of switching from int to int64 in the Cython IO code; I will push it today. For some reason I thought I already had! Thanks for the heads up. Matt On Sep 26, 2012 12:24 PM, "Casey W. Stark" wrote:

Hey Matt.

I installed yt-dev on Hopper and updated to Andrew's changes. The cellvolume test looks good, so the changes are good.

However, this brought up another issue with the Nyx reader. When I tried projecting in a 2.4 install and the fresh install, I got "OverflowError: value too large to convert to int" from calling read_and_seek. We should sort this out, but because it's in both versions, I don't think it has to do with these changes.

- Casey

On Thu, Sep 20, 2012 at 4:00 PM, Matthew Turk wrote:

...

Hi Casey,

I think your and Andrew's intutions are correct. Another good sanity check would be to check the before/after values of calculating:

dd = pf.h.all_data() dd.quantities["TotalQuantity"]("CellVolume")

I think as long as this is the sae, and the slices are all set, it should be all good. The changes I think are quite good and should only change (by helping) at the level of just above roundoff error.

-Matt

On Thu, Sep 20, 2012 at 6:49 PM, Andrew Myers wrote:

...

Hi Casey,

Someone more knowledgeable than myself should confirm, but I would guess that if I screwed up something with the 'dx' fields it would be fairly blatant, such that a multi-level slice or projection would catch it. I've been working with Orion data sets for about a week with this change, and it seems fine, so I think we just need a basic sanity check for the other frontends.

-Andrew Myers

On Thu, Sep 20, 2012 at 3:13 PM, Casey W. Stark wrote:

...

Hey Matt.

The changes in the Nyx frontend look good to me, but you're right that I'll have to test it. Is it sufficient to compare multilevel slices

before

...

and after the changes?

- Casey

On Thu, Sep 20, 2012 at 8:30 AM, Matthew Turk wrote:

...

Hi all (but especially Casey and Tom Robitaille if he's still

subscribed

...

:),

Andrew Myers found a very nice solution to issue #414:

https://bitbucket.org/yt_analysis/yt/issue/414/orion-ghot-zones-not-generati...

...

which he's put in this PR:

https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-eac...

...

I have only limited access to Nyx / Orion data with subgrids, so I can't test this appropriately. I think the changes look good, however, so if I can get from any other boxlib user that they still produce good results, I will accept them. This is also a good time to mention that going forward I hope to consolidate the various boxlib readers.

Best,

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

Hey Matt. I updated and projections work. All's good. - Casey On Wed, Sep 26, 2012 at 10:05 AM, Casey W. Stark wrote:

Hey Matt.

Really glad it's such a simple fix! I will try again with the update.

- Casey

On Wed, Sep 26, 2012 at 10:04 AM, Matthew Turk wrote:

...

Hi Casey,

Ah, I saw this the other day when we were IO stress testing on EC2. It's a super simple fix of switching from int to int64 in the Cython IO code; I will push it today. For some reason I thought I already had! Thanks for the heads up.

Matt On Sep 26, 2012 12:24 PM, "Casey W. Stark" wrote:

...

Hey Matt.

I installed yt-dev on Hopper and updated to Andrew's changes. The cellvolume test looks good, so the changes are good.

However, this brought up another issue with the Nyx reader. When I tried projecting in a 2.4 install and the fresh install, I got "OverflowError: value too large to convert to int" from calling read_and_seek. We should sort this out, but because it's in both versions, I don't think it has to do with these changes.

- Casey

On Thu, Sep 20, 2012 at 4:00 PM, Matthew Turk wrote:

...

Hi Casey,

I think your and Andrew's intutions are correct. Another good sanity check would be to check the before/after values of calculating:

dd = pf.h.all_data() dd.quantities["TotalQuantity"]("CellVolume")

I think as long as this is the sae, and the slices are all set, it should be all good. The changes I think are quite good and should only change (by helping) at the level of just above roundoff error.

-Matt

...

Hi Casey,

Someone more knowledgeable than myself should confirm, but I would guess that if I screwed up something with the 'dx' fields it would be fairly blatant, such that a multi-level slice or projection would catch it. I've been working with Orion data sets for about a week with this change, and it seems fine, so I think we just need a basic sanity check for the other frontends.

-Andrew Myers

On Thu, Sep 20, 2012 at 3:13 PM, Casey W. Stark < caseywstark@gmail.com> wrote:

...

Hey Matt.

The changes in the Nyx frontend look good to me, but you're right

On Thu, Sep 20, 2012 at 6:49 PM, Andrew Myers wrote: that

...

...

I'll have to test it. Is it sufficient to compare multilevel slices before and after the changes?

- Casey

On Thu, Sep 20, 2012 at 8:30 AM, Matthew Turk

...

wrote: > > Hi all (but especially Casey and Tom Robitaille if he's still subscribed > :), > > Andrew Myers found a very nice solution to issue #414: > > > https://bitbucket.org/yt_analysis/yt/issue/414/orion-ghot-zones-not-generati... > > which he's put in this PR: > > > https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-eac... > > I have only limited access to Nyx / Orion data with subgrids, so I > can't test this appropriately. I think the changes look good, > however, so if I can get from any other boxlib user that they still > produce good results, I will accept them. This is also a good time to > mention that going forward I hope to consolidate the various boxlib > readers. > > Best, > > Matt > _______________________________________________ > 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

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