[yt-users] Volume rendering - filenames

[Matthew Turk]

Hi Mike,

> I get the error message at the bottom of this email.  It seems that it is
> looking for files ending in .cpu000#  rather than .grid.cpu000#  like the
> default enzo output.  I've tried doing a rename but then I get the same
> error but the other way around.  Making a copy of the file with each
> filename works if I'm just doing a single image, but I'm trying to make a
> movie so doing that for 100 files for 8 cpus each would be a bit tedious.

Here's the quick fix, and then some backstory.  Put this at the top of
your imports:

http://paste.enzotools.org/show/446/

As to the backstory: the history and family tree of Enzo is a
complicated flow, and I'm not even convinced it's acyclic.  There have
been at least three different primary modes of IO: HDF4, HDF5, and
"packed" HDF5.  (This is ignoring for a moment things like AMRLib,
which was also supported at one point, as well as anything that may
have come before.)  There have been two implementations of the
"packed" HDF5 format, where each grid is an HDF5 group output by its
owning processor.  Unfortunately, while the internal naming scheme is
the same, the naming scheme for the files is different.  To my
understanding, this difference in naming scheme -- including ".grid."
and not including ".grid." mostly stems from the implementations from
the East Coast and West Coast, respectively.

When I initially implemented the packed HDF5, yt had no preconceptions
about the naming scheme, and it worked independent of the inclusion of
".grid.", by simply reading the FileName parameters in the .hierarchy.
 However, last Summer and Fall I worked on optimizing the hierarchy
for a much faster instantiation time and to clean up a lot of the
cruft -- which ended up actually including a file name guessing
mechanism.  By then I had actually switched code bases and not even
realizes that the ".grid." difference existed, so I never saw any
problems until I revisited my thesis data a few months ago.  That's
why the change above has been added.

Because there's a substantial amount of data out there that still
includes ".grid." in its filenames, I will see if I can fix this
behavior in the long term; when I initially applied this "hotfix" I
thought it wouldn't be a problem for many or any other people.  I
guess that's not true, as I spoke with some people last week that also
required it.  However, for now I believe it should work for you and
your use case.  Let me know if it does not!

Best,

Matt