This documentation introduction was generated manually by Kaden Hazzard.
Main changes (from main branch documentation):
Note: all authorship on the Free Energy framework is marked as ``Kaden Hazzard.'' This refers only to the documentation. The code was written in collaboration with Erik Welch (welch@mps.ohio-state.edu).
For typical ohmms applications without GUI supports on generic unix/linux machines, configuring with autoconf/automake is the best choice and is recommended. On some High-performance computers (so called, Super Computers), autoconf/automake often fails to work properly. Things will improve over the time but JK found that cmake or the perl script she wrote sometimes works better and easier to change for the local environments. Especially, if OpenGL/Qt should be used, using cmake is recommended and most likely that only cmake will work.
The perl script is kept for historical reasons and is available only to those who develop ohmms applications.
Once configuration is successful, build/src/ohmms-config.h (See ohmms-config::h) is generated. The compiler macros are set based on the configuration options and the local environments.
More on configuration can be found at http://www.mcc.uiuc.edu/ohmms/docs/dg/configtools.html
The actual parsing of xml documents is done by libxml2 library with few template classes and functions implemented to reduce the amount of coding required to use libxml2 directly (see libxmldefs.h).
The main instructions are parsed by a DOM parser and the entire tree is stored in memory. The assumption here is that the instructions are small and large-scale data are stored in other formats, typically in hdf5 formats, and the main xml file merely maps the name of the object to the physical data in hdf5 files.
Since DOM tree consists of text nodes, the conversion from the text node to the actual objects is done by the ohmms classes. In general, the classes that should handle a xml node are inherited from OhmmsElementBase and implement the virtual function put(xmlNodePtr cur).
The current design DOES NOT require that there is one-to-one mapping between the xml node to a physical object. The node can be handled by a simple object or can be handled by factory classes. An object can overwrite, add or remove its child nodes and the node itself, if the content is no longer used by other objects.
1.3.4