Plans/ytOrion

Orion/BoxLib? 2.5 Data

This is now historical, as Orion support is included in the main trunk'''

We are working on generalizing yt to be a reader/plotter/slicer/dicer for Cartesian AMR beyond Enzo. The first step in this process is to add support for  Orion, a grid-based AMR radiation hydrodynamics solver. Unfortunately, Orion itself is proprietary, however it is built on the BoxLib 2.5 AMR framework from  CCSE at Lawrence Berkeley Labs, which is not proprietary. Because Orion's data output is vanilla BoxLib, a goal for this data reader should be made sufficiently general to support any BoxLib application.

To Do

There are several changes to the existing trunk of yt that will need to be made, mostly relating to eliminating "Enzo" from the names of things. Matt will handle this.

I (joishi) will attend to the creation of the necessary bits of lagos to support BoxLib? data:

  • OrionStaticOutput? -- this gets a bit confusing, because BoxLib? doesn't have a concept equivalent to the parameter file. That is left to the application built on it.
  • BoxLibHierarchy? -- boxlib does not write a nice hierarchy file like Enzo does, so this will have to work harder than EnzoHierarchy? to build things from the various header files BoxLib creates

Update (10 July 2008)

  • Reading is complete.
  • units appear mostly correct, but need testing.
  • DerivedFields? are still a mess. this is the major priority
  • need to add to a vector length legend to vector plots
  • a strange bug is occurring with large data sets: order 10 cells are not being placed correctly

Update (21 June 2008)

  • Branching has occurred.
  • 'AMR' is the new prefix, and all the base data types have been converted.
  • All of the lagos & raven unit tests pass for Enzo data
  • js oishi has nearly finished the reader.
    • FAB reader is done, using dtype construction
    • Offsets are not yet calculated
    • Parameter file reader is nearly done
    • Units are uncertain
    • Domain left edge and domain right edge are not (0,1)
  • Parameters from Orion will be mapped into Enzo parameters
  • Data IO will be in a simple style, and slicing (open problem due to striding in a one-d array inside a file being examined with fseek) will be on a fully-read array
  • Fields names are mapped back and forth between Enzo & Orion names (frozendict would be nice.)