[yt-users] hierarchy file for light cone simulation

Matthew Turk matthewturk at gmail.com
Tue Mar 15 13:27:19 PDT 2011


Hi Rick,

I think we can all agree that you had the best of intentions.  And
hopefully in future versions Enzo will have improved semantics for the
hierarchy, similar to what you were aiming for; this is definitely a
conversation that's worth having!

-Matt

On Tue, Mar 15, 2011 at 1:08 PM, Rick Wagner <rpwagner at sdsc.edu> wrote:
> Hi Britton,
> This is completely my fault, and left over from when packed-AMR was first
> introduced, and I had the bright idea to improve the semantics of the file.
> The best solution is definitely to parse the file into the standard format
> (as I have done many times myself).
> --Rick
> On Mar 15, 2011, at 1:01 PM, Britton Smith wrote:
>
> Sam's script worked perfectly.  I think this is probably the best solution
> since my understanding is that nothing new is being run with this format.
>
> Thanks again, Sam!
>
> Britton
>
> On Tue, Mar 15, 2011 at 3:49 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi Britton,
>>
>> On Tue, Mar 15, 2011 at 12:35 PM, Britton Smith <brittonsmith at gmail.com>
>> wrote:
>> > Hi everyone,
>> >
>> > I'm trying to make some projections of the data from the Santa Fe Light
>> > Cone
>> > simulation, but it's getting hung trying to parse the hierarchy file.
>> > After
>> > looking around, I noticed that the one dataset that I had success with
>> > has a
>> > different format for the hierarchy file than the ones that aren't
>> > working.
>> > The ones that are working have hierarchy files that look like this:
>> >
>> > Grid = 1
>> > GridRank          = 3
>> > GridDimension     = 134 70 70
>> > GridStartIndex    = 3 3 3
>> > GridEndIndex      = 130 66 66
>> > GridLeftEdge      = 0 0 0
>> > GridRightEdge     = 0.25 0.125 0.125
>> > Time              = 101.45398694554
>> > SubgridsAreStatic = 0
>> > NumberOfBaryonFields = 7
>> > FieldType = 0 1 2 4 5 6 22
>> > BaryonFileName =
>> > /dsgpfs/projects/enzo/ux453739/GC512_L7_New/RD0009/RD0009.cpu0000
>> > CourantSafetyNumber    = 0.400000
>> > PPMFlatteningParameter = 0
>> > PPMDiffusionParameter  = 0
>> > PPMSteepeningParameter = 0
>> > NumberOfParticles   = 445435
>> > ParticleFileName =
>> > /dsgpfs/projects/enzo/ux453739/GC512_L7_New/RD0009/RD0009.cpu0000
>> > GravityBoundaryType = 0
>> > Pointer: Grid[1]->NextGridThisLevel = 2
>> >
>> > The ones that aren't working have formats like this:
>> >
>> > Grid = 1
>> > GridRank          = 3
>> > GridDimension     = 134 70 70
>> > GridStartIndex    = 3 3 3
>> > GridEndIndex      = 130 66 66
>> > GridLeftEdge      = 0 0 0
>> > GridRightEdge     = 0.25 0.125 0.125
>> > Time              = 128.98486432526
>> > SubgridsAreStatic = 0
>> > FileName       = RD0012.cpu0000
>> > GroupName      = /Grid00000001
>> > NumberOfBaryonFields = 7
>> > FieldType = 0 1 2 4 5 6 22
>> > CourantSafetyNumber    = 0.400000
>> > PPMFlatteningParameter = 0
>> > PPMDiffusionParameter  = 0
>> > PPMSteepeningParameter = 0
>> > NumberOfParticles   = 408561
>> > GravityBoundaryType = 0
>> > Pointer: Grid[1]->NextGridThisLevel = 2
>> >
>> > The first type seems to be the standard.  Is there anything I can do to
>> > make
>> > this nonstandard hierarchy format work with YT?
>> >
>>
>> Okay, I have seen some of this before.  My understanding is that this
>> hierarchy format is basically broken.  It worked with one version of
>> Enzo, but will not restart (cleanly) with any current version of Enzo
>> -- in particular, the problem seems to be not just in the ordering of
>> the lines in each grid entry, but in the actual content of the lines
>> themselves.
>>
>> Additionally, not only is it broken for all current and most past
>> versions of Enzo, but it doesn't also doesn't have its own
>> VersionNumber value in the parameter file, so there's no easy way to
>> switch between mechanisms for parsing the hierarchy without actually
>> parsing the hierarchy.
>>
>> One could theoretically write a whole bunch of conditionals that
>> switch between methods, but I believe supporting this hierarchy format
>> would add substantial performance hits to the hierarchy parser, which
>> as of right now actually takes up a substantial amount of time anyway
>> in the instantiation of light cone-size datasets.  Because it's a
>> broken hierarchy format, it's not supported anymore by any Enzo
>> versions and supporting it would incur either a substantial
>> performance hit or some additional largely-unused code to be included
>> as an alternate, I'm not sure I can really justify supporting it as an
>> additional mechanism.
>>
>> Maybe try pre-processing it to make it look like a standard hierachy?
>>
>> -Matt
>>
>> > Thanks,
>> > Britton
>> >
>> > _______________________________________________
>> > 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
>
> _______________________________________________
> 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
>
>



More information about the yt-users mailing list