enzo Projection Tool Redesign

Currently there are three projection tools for enzo data: the built in capability, Brian's enzoproj, and kodachrome from the mpi_analysis tools. Rather than rebuild either of the standalone tools, it's time for the built in function to get reworked a little. And for now, just write a wrapper script to enzo that handles the commandline arguments specific to projections. This may require a separate make serial-tools target if people are going to use this is a serial program. But, this method could easily be easily repeated for the extraction tool.

Goals

• Scalable, especially in memory usage.
• Standalone and inline.
• HDF5 file and/or PNGs using IDL colormaps.
• Selection of projection quantities.
• Arbitrarily large images.

I'm not sure we can do the last one, but I really want to have images coming out at the maximum resolution. And, looking to the future, and thinking of the next big simulation (1024 cubed with 7 levels), that's 128 GB per field.

>>> grid = 1024
>>> maxrefine = 7
>>> pixels = (grid * 2**maxrefine)**2
>>> bytesperpixel = 8
>>> GB = 1024.**3
>>> size = pixels * bytesperpixel / GB
>>> print "%d GB" % size
128 GB
>>> 

Which means we can't store a complete field on every task, let alone every node. In fact, we probably can't store it on a single task to write it out. And don't forgot, we're going to need extractions at some point.

Implementation

The tricky part about this may be the reduction. Eventually, all the data has to be in one place to be written to disk, whether that's done by a single enzo task, or the parallel HDF5 layer--and there is no parallel PNG layer. But, as the previous example shows, we may not have enough space to hold everything on the root process.

Tiling the Projection

During runtime, tile the projection the same as the root grid.