[yt-users] Ramses plot issues

Matthew Turk matthewturk at gmail.com
Wed Dec 19 04:21:47 PST 2012


Hi Sam,

I think I figured it out, and in befae3c21101 I pushed a change to fix
it.  I believe that calculating the index of the root mesh into which
an oct should be inserted was somewhat off, resulting in memory
overruns.  Let me know if that doesn't fix it for you!

Best,

Matt

On Tue, Dec 18, 2012 at 6:11 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Sam,
>
> I was able to reproduce the error.  I can isolate the first memory
> corruption to during the octree parsing.  I suspect it is related to
> an off-by-one error somewhere, as I am finding four more Octs than yt
> expects to find.  Following that memory error, arrays become
> corrupted.  My guess is that there is an additional case for IO in
> RAMSES I was not correctly supporting.  I'll write back when I have
> narrowed it down for a fix.
>
> -Matt
>
> On Tue, Dec 18, 2012 at 2:43 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>> Hi Sam and Nathan,
>>
>> Nathan, thanks for verifying! What a weird backtrack. Speaks to funny
>> business with array memory.
>>
>> When I say the fields are in a particular order, I mean that the actual
>> fields in the file are likely different. To my understanding ramses doesn't
>> provide a way to say, "this output has density, energy, metallicity,
>> magnetic field" etc right in the output file, but instead requires the
>> person reading the file in know this in advance. We can try applying
>> heuristics, but I am uncertain how well these would work. As it stands, the
>> field list is currently hard coded although intended to be changed. It's in
>> a tuple inside the ramses code.
>>
>> Additionally, it's also possible that this data file includes precision that
>> I had not expected - modifying the float/int bit width may be necessary for
>> this particular datatype.
>>
>> My recommendation is to check the fields in the file. They may differ from
>> what yt expects, causing a memory overrun.
>>
>> What we should do is accept them as a constructor argument. Unfortunately I
>> won't be able to provide feedback on this immediately but it should be
>> straightforward to implement.
>>
>> Matt
>>
>> On Dec 18, 2012 1:13 PM, "Sam Leitner" <sam.leitner at gmail.com> wrote:
>>>
>>> The output is not mine, it's an isolated disk run by Oscar Agertz. I can
>>> double check with him, but I very much doubt the corruption is on the data
>>> side.
>>>
>>>
>>> On Tue, Dec 18, 2012 at 2:03 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>>> wrote:
>>>>
>>>> Hi Sam and Matt,
>>>>
>>>> I'm able to reproduce Sam's crash on my laptop (OS X 10.7, yt-3.0
>>>> 6fb278bef80f).
>>>>
>>>> I was able to run python inside gdb but the backtrace isn't very helpful
>>>> (at least to my eyes): http://paste.yt-project.org/show/3002/
>>>>
>>>> One possibly useful hint is that it appears to be crashing inside CPython
>>>> proper rather than _ramses_reader.so.
>>>>
>>>> I also tried in yt-2.5 dev ( 4174ccdee99d) and don't see crashes,
>>>> although looking at the plots I get back, I see some corruption:
>>>> http://i.imgur.com/PrQyO.png
>>>>
>>>> It's not clear if this is an issue on the yt side or if the data file Sam
>>>> supplied is somehow corrupted.  I'm guessing that Sam can independently
>>>> verify that the data is free or errors.
>>>>
>>>> -Nathan
>>>>
>>>>
>>>> On 12/18/12 10:13 AM, Sam Leitner wrote:
>>>>>
>>>>> Hi Matt,
>>>>> Hmm, we are indeed both on the same change set (6fb278bef80f). The
>>>>> Ramses files I'm running on are here (if you get a chance to give them a
>>>>> try):
>>>>> http://kicp.uchicago.edu/~agertz/sam/
>>>>> <http://kicp.uchicago.edu/%7Eagertz/sam/>
>>>>>
>>>>> Thanks for your help!
>>>>> Sam
>>>>>
>>>>> On Tue, Dec 18, 2012 at 12:52 PM, Matthew Turk <matthewturk at gmail.com
>>>>> <mailto:matthewturk at gmail.com>> wrote:
>>>>>
>>>>>     6fb278bef80f
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yt-users mailing list
>>>>> yt-users at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>>
>>>
>>>
>>> --
>>> Sent from a mobile device.
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>



More information about the yt-users mailing list