<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Britton,<div><br></div><div>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).</div><div><br></div><div>--Rick</div><div><br><div><div>On Mar 15, 2011, at 1:01 PM, Britton Smith wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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.<br><br>Thanks again, Sam!<br><br>Britton<br><br><div class="gmail_quote">
On Tue, Mar 15, 2011 at 3:49 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Britton,<br>
<div><div></div><div class="h5"><br>
On Tue, Mar 15, 2011 at 12:35 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
> I'm trying to make some projections of the data from the Santa Fe Light Cone<br>
> simulation, but it's getting hung trying to parse the hierarchy file. After<br>
> looking around, I noticed that the one dataset that I had success with has a<br>
> different format for the hierarchy file than the ones that aren't working.<br>
> The ones that are working have hierarchy files that look like this:<br>
><br>
> Grid = 1<br>
> GridRank = 3<br>
> GridDimension = 134 70 70<br>
> GridStartIndex = 3 3 3<br>
> GridEndIndex = 130 66 66<br>
> GridLeftEdge = 0 0 0<br>
> GridRightEdge = 0.25 0.125 0.125<br>
> Time = 101.45398694554<br>
> SubgridsAreStatic = 0<br>
> NumberOfBaryonFields = 7<br>
> FieldType = 0 1 2 4 5 6 22<br>
> BaryonFileName =<br>
> /dsgpfs/projects/enzo/ux453739/GC512_L7_New/RD0009/RD0009.cpu0000<br>
> CourantSafetyNumber = 0.400000<br>
> PPMFlatteningParameter = 0<br>
> PPMDiffusionParameter = 0<br>
> PPMSteepeningParameter = 0<br>
> NumberOfParticles = 445435<br>
> ParticleFileName =<br>
> /dsgpfs/projects/enzo/ux453739/GC512_L7_New/RD0009/RD0009.cpu0000<br>
> GravityBoundaryType = 0<br>
> Pointer: Grid[1]->NextGridThisLevel = 2<br>
><br>
> The ones that aren't working have formats like this:<br>
><br>
> Grid = 1<br>
> GridRank = 3<br>
> GridDimension = 134 70 70<br>
> GridStartIndex = 3 3 3<br>
> GridEndIndex = 130 66 66<br>
> GridLeftEdge = 0 0 0<br>
> GridRightEdge = 0.25 0.125 0.125<br>
> Time = 128.98486432526<br>
> SubgridsAreStatic = 0<br>
> FileName = RD0012.cpu0000<br>
> GroupName = /Grid00000001<br>
> NumberOfBaryonFields = 7<br>
> FieldType = 0 1 2 4 5 6 22<br>
> CourantSafetyNumber = 0.400000<br>
> PPMFlatteningParameter = 0<br>
> PPMDiffusionParameter = 0<br>
> PPMSteepeningParameter = 0<br>
> NumberOfParticles = 408561<br>
> GravityBoundaryType = 0<br>
> Pointer: Grid[1]->NextGridThisLevel = 2<br>
><br>
> The first type seems to be the standard. Is there anything I can do to make<br>
> this nonstandard hierarchy format work with YT?<br>
><br>
<br>
</div></div>Okay, I have seen some of this before. My understanding is that this<br>
hierarchy format is basically broken. It worked with one version of<br>
Enzo, but will not restart (cleanly) with any current version of Enzo<br>
-- in particular, the problem seems to be not just in the ordering of<br>
the lines in each grid entry, but in the actual content of the lines<br>
themselves.<br>
<br>
Additionally, not only is it broken for all current and most past<br>
versions of Enzo, but it doesn't also doesn't have its own<br>
VersionNumber value in the parameter file, so there's no easy way to<br>
switch between mechanisms for parsing the hierarchy without actually<br>
parsing the hierarchy.<br>
<br>
One could theoretically write a whole bunch of conditionals that<br>
switch between methods, but I believe supporting this hierarchy format<br>
would add substantial performance hits to the hierarchy parser, which<br>
as of right now actually takes up a substantial amount of time anyway<br>
in the instantiation of light cone-size datasets. Because it's a<br>
broken hierarchy format, it's not supported anymore by any Enzo<br>
versions and supporting it would incur either a substantial<br>
performance hit or some additional largely-unused code to be included<br>
as an alternate, I'm not sure I can really justify supporting it as an<br>
additional mechanism.<br>
<br>
Maybe try pre-processing it to make it look like a standard hierachy?<br>
<br>
-Matt<br>
<div><div></div><div class="h5"><br>
> Thanks,<br>
> Britton<br>
><br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br>
_______________________________________________<br>yt-users mailing list<br><a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br><a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br></blockquote></div><br></div></body></html>