[yt-users] Ramses plot issues

[Matthew Turk]

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