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
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 matthewturk@gmail.com 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,
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.comwrote:
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 matthewturk@gmail.comwrote:
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
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 atmyers@berkeley.edu 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 caseywstark@gmail.com 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 matthewturk@gmail.com 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
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 matthewturk@gmail.com 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 atmyers@berkeley.edu 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 caseywstark@gmail.com 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 matthewturk@gmail.com 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
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" caseywstark@gmail.com 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 matthewturk@gmail.comwrote:
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 atmyers@berkeley.edu 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 caseywstark@gmail.com 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 matthewturk@gmail.com 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.
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 matthewturk@gmail.comwrote:
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" caseywstark@gmail.com 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 matthewturk@gmail.comwrote:
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 atmyers@berkeley.edu 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 <caseywstark@gmail.com
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 matthewturk@gmail.com 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
Hey Matt.
I updated and projections work. All's good.
- Casey
On Wed, Sep 26, 2012 at 10:05 AM, Casey W. Stark caseywstark@gmail.comwrote:
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 matthewturk@gmail.comwrote:
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" caseywstark@gmail.com 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 matthewturk@gmail.comwrote:
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 atmyers@berkeley.edu 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 <
caseywstark@gmail.com>
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 <matthewturk@gmail.com
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
participants (3)
-
Andrew Myers -
Casey W. Stark -
Matthew Turk