The proposed DTD for ohmms and related applications reflects their design and implementations. An object is mapped into a xml node and each object works on a node. A node can be a simple text node or can be a complex node with multiple child nodes.
A typical materials simulation requires a series of runs on a given physical system. The proposed DTD/schema is intended to handle these cases:
A user starts a simulation with some initial configurations.
A user continues simulations starting with a previous state.
A user changes simulation parameters, e.g., external temperature.
A user changes physical models.
The root of valid input files for ohmmsapp is simulation: a simulation starts, when ohmmsapp (or equivalent) is executed. A simulation can have many serial or parallel threads running, as described by the definition
<!ELEMENT simulation (project?,random?,process+)>
A process element encapsulates a thread. Its main role is to process a sequence of instructions given as its child nodes. The execution of multiple processes can be sequential or embarrassingly parallel. No mixed execution is allowed. Spawning/joining of threads is also forbidden.
Similarly to threads in computing, the processes in a simulation share common resources. Once an object is created from a previous process, the object usually persists, especially when the object is expensive to create or destroy. This means that one should be careful in changing the problem size or the basic engines of a simulation too often, even though it might be be possible. For instance, if you want to change a potential from classical to quantum, execute ohmmsapp twice, rather than bunching two processes.
