Infinite lattice definition

This page contains minutes from a Google Plus meeting between Chris Dembia and the PyNE members who attended the PyNE hack-a-thon in August, 2012 about the pyne.mcnp.Inp class and pyne.mcnpcard module (both of which are to be renamed).

The people who reviewed the code at the hack-a-thon are Anthony Scopatz (scopatz), Elliot, Eric, and Paul Wilson (gonuke).

The following items were discussed:

• It was suggested that a much more general code is written that can define a lattice geometry for any code (MCNPX, Serpent, MCode, etc.). Efforts to develop general geometry syntax exist, but we don't know their plans for distribution (Reactor Geometry Generator, Meshkit, Castle?).
• Ideally, this lattice geometry builder would step away from the current "add" paradigm of the mcnp.Inp class, in which there is no provision for modifying existing cards. Ideally, there would be methods to copy a portion of the geometry and paste it elsewhere in the geometry, to translate the geometry, etc. Aside from this would be the ability to modify particular parameters for parameter space studies. It is preferable to modify a parameter of the input and re-run the simulation rather than to have to define an entirely new simulation.
• It is desirable that the geometry/simulation definition is done independently of any code such as MCNPX. This should be fine for geometry and materials, but is not so clear for MCNPX data cards.

The tasks that Chris Dembia (fitze) has time to tackle are the following, which fall far short of the ideal code described above:

• Move pyne.mcnp.Inp into its own separate module. Accordingly, remove from pyne.mcnp.Inp any notion of running MCNPX.
• Rewrite pyne.mcnpcard with an additional layer of abstraction, so that "cards" are independent of MCNPX, but MCNPX cards or Serpent cards can be generated by some other module.
• Separate the definition of geometry and materials from the specification of MCNPX/Serpent data cards.
• Develop the code in such a way that someone can later allow for persistence through the use of JSON files.
• Write documentation for further work on the module
• Rewrite the example and tests to adapt to the above changes.

Development notes:

• The current work will be split into two modules, one that generates an "in-memory" definition of reactor geometry (including materials), and one that uses that definition to create an input to MCNPX, and eventually Serpent or MCODE. Tentatively, the former will be named reactordef and the latter will be named inputgen.