[yt-dev] Boxlib changes: RFT

Casey W. Stark caseywstark at gmail.com
Wed Sep 26 13:58:37 PDT 2012


Hey Matt.

I updated and projections work. All's good.

- Casey


On Wed, Sep 26, 2012 at 10:05 AM, Casey W. Stark <caseywstark at gmail.com>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 <matthewturk at gmail.com>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" <caseywstark at 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 at 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 at 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 at 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 at 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-generating-correctly
>>>> >>>
>>>> >>> which he's put in this PR:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-each-grid-from-the
>>>> >>>
>>>> >>> 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 at lists.spacepope.org
>>>> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> yt-dev mailing list
>>>> >> yt-dev at lists.spacepope.org
>>>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > yt-dev mailing list
>>>> > yt-dev at lists.spacepope.org
>>>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>> >
>>>> _______________________________________________
>>>> yt-dev mailing list
>>>> yt-dev at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> 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/20120926/d919c21d/attachment.htm>


More information about the yt-dev mailing list