+
+ValueFinfo: Stores functions for set and get operations on a specific field.
+LookupFinfo: Stores functions for set with index, get with index, a
+ get to return size of table, and a get to return the whole table.
+DestFinfo: Stores a single function.
+SrcFinfo: Defines origin of a message. Manages the send and sendTo operations.
+ Typed. Provides index for FuncId lookup.
+Note that the Finfos do NOT map one-to-one to the funcs.
+
+The Finfo may have multiple functions in it. Each function is defined using
+an Ftype that provides 3 functions:
+constructor: Loads in the function of the form &Reac::setKf.
+checkSlot( const Slot* s): Does RTTI check on the slot to ensure compatibility.
+op( Eref e, const char* buf): converts the data entry and buffer and calls func.
+
+MESSAGE SETUP
+bool add( Element* src, const string& srcField,
+ Element* dest, const string& destField );
+ Decides if fields are for simple or shared messages.
+Case 1: Simple Msg:
+bool addMsgToFunc( Element* src, const Finfo* finfo, Element* dest, FuncId fid )
+ Makes a new Msg, with Src and Dest Elements.
+Msg::Msg( src, dest ): constructor registers the new Msg on the src and dest:
+ Element::addMsg( m )
+ This part needs thought, to decide what kind of Msg to make.
+Conn::add( m): To put the Msg on the Conn.
+src->addConn : To put the conn on the Src.
+src->addTargetFunc: To put the target Func info on the Src.
+
+Case 2: Shared Msg.
+addSharedMsg( Element* src, const Finfo* f1, Element* dest, const Finfo* f2 )
+Yet to implement.
+
+------------------------------------------------------------------------------
+Tree operations.
+Move:
+Shell::doMove( Id orig, Id newParent )
+This function moves the object orig to the new parent NewParent. It does so
+by deleting the old parent->child Msg and creating a new one.
+
+Shell::doCopy( Id orig, Id newParent, string newName, unsigned int n, bool copyExtMsgs)
+This function creates a copy of the 'orig' object and all its descendants.
+It renames the object to 'newName'.
+This copy includes all parameters and state variables. The copy can be multiple,
+so that the single original now becomes an array of size n. If this happens
+then the DataHandlers of the copy have to be upgraded to the next higher
+dimension. Likewise, Messages must also be upgraded.
+The copy always includes the messages that were within the copied tree. If the
+copeExtMsgs field is True then all messages are copied.
+Present status: only n = 1 and copyExtMsgs = 0 are currently supported.
+Tested with all current implementations of messaging.
+Not tested on multiplen nodes.
+
+Shell::doDelete( Id i )
+Destroys Id i, all its messages, and all its children.
+
+------------------------------------------------------------------------------
+OpFunc lookup
+Every function used by MOOSE has a unique FuncId, consistent across nodes.
+This is assigned at static initialization time when the Cinfo constructor
+scans the FinfoArray.
+Managed in Cinfo::funcs_[FuncId]
+Assigned in Cinfo::init using Finfo::registerOpFuncs
+
+There is a static global vector of OpFuncs in the Cinfo class that has entries
+for every function so defined. The FuncId is the index into this vector.
+Additionally, each Cinfo instance has a vector of OpFuncs applicable to itself,
+again indexed by FuncId. Invalid FuncIds for the class have a zero pointer.
+
+FuncId 0 is a dummy function.
+
+------------------------------------------------------------------------------
+Solvers
+Solvers take over operation of a number of regular objects. This is done
+by replacing the data and class info of the original, with special
+'Zombie' versions provided by the solver. Typically the data provided is
+a wrapper for the data of the solver itself, and the class info is a
+set of access functions that act on the data, with exactly the same interface
+as the original class. The messages of the zombified Element are left intact,
+with the possible exception of the 'process' message.
+
+To do zombification, the Element provides several handy functions:
+MsgId findCaller( fid ): Finds the first Msg that calls the specified fid.
+getInputMsgs( vector< MsgId >, Fid ): Finds all Msgs that call the fid.
+getOutputs< vector< Id >, const SrcFinfo* ): Finds all target Ids of the Src
+getInputs< vector< Id >, const DestFinfo* ): Finds all src Ids of the Dest
+zombieSwap( const Cinfo*, DataHandler* ): Replaces Cinfo and data on Element.
+
+The solver data class should provide utility functions for the Zombies to
+covert object Ids to lookup indices into the solver.
+
+
+Original Data is replaced completely with a solved version
+The Element uses a replacement Cinfo to handle this, so that the operation:
+ OpFunc Element::getOpFunc( funcId ); // asks Cinfo for opFunc.
+is now redone. This handles all field access and async messages.
+< Need to work out what to do with sync messages >
+
+
+
+
+
+
+
+Slot::sendTo
+ - Sets up a temporary buffer for the argument and target index.
+ - only it doesn't use it. Could replace the target index stuff
+ done below in Conn::tsend.
+Eref::tsend
+ - Creates a Qinfo with the useSendTo flag
+ - Element looks up a Conn based on ConnId.
+Conn::tsend
+ - Looks for a Msg with a target Element matching the target Id.
+ - Appends the target index after the arg in the buffer.
+ - Updates the Qinfo to indicate the new size
+Msg::addToQ
+ - the Qinfo gets the msgId of the target
+Element::addToQ
+Qinfo::addToQ called with the queue vector from the Element.
+ - copies the Qinfo and then the arg into the queue.
+
+...................... There it sits till Element::clearQ
+
+Element::clearQ
+ Marches through buffer
+Element::execFunc
+ - Extracts Qinfo
+ - Looks up func and Msg
+ - If useSendTo:
+ OpFunc::op Executes the function.
+ - else:
+ Msg::exec
+ - Sorts out which target to use.
+ Unnecessary as it is on it
+ Opfunc::op: Executes the function.
+
+
+------------------------------------------------------------------------------
+Parallelism and grouping.
+After some analysis, it seems like many parallel simulations will have a
+lumpy connectivity. That is, there will be groups with high internal
+connectivity. Different groups and stray other elements have sparser
+connectivity. For example, a brain region (e.g., OB) will be highly connected
+internally, and much more loosely connected externally. So the OB would form
+one group, and perhaps the Piriform another group.
+
+Multithreading and MPI-based decomposition are very similar as one scales up:
+in both cases we need buffers for data transfer. Up to a point it makes sense
+to amalgamate all MPI based communication for each node even if it has many
+threads internally. This is the main asymmetry.
+
+------------------------------------------------------------------------------
+
+MULTITHREADING.
+Async:
+Setup:
+Nothing special
+Send:
+
+Each thread has a separate section of the Queue on each target Element. So
+there is never any need for individual mutexes.
+clearQ: Three possible levels of separation.
+ - Separate at the level of Msgs for large Msgs handling lots of
+ targets. Separate chunks of the targets could be assigned to
+ different threads. Needs that no other threads are modifying target.
+ - Separate at the level of Elements; so that each Element is on a
+ different thread. Need to set up enough Elements to balance this
+ properly. Can we set up multiple Elements on the same node with the
+ same Id? This would work well for cases where there are huge numbers
+ of Elements.
+ - Separate at the level of solvers. Works where one big solver handles
+ lots of Elements. This becomes very solver-specific, and we would
+ have to define rules for how the solver is allowed to do this.
+Sync:
+No problems because the memory locations are distinct for all data transfer.
+
+Data transfer of 'group' queues, from perspective of each thread.
+ - During process, put off-group stuff into off-group queues.
+ - on-node other threads; and off-node data each have queues.
+ - During process, put in-group data into own 'output' queue.
+ - When Process is done, consolidate all in-group 'output' queues.
+ - Send consolidated in-group queue to all nodes in group
+ - off-group, on-node queues are handled by their owner threads.
+ - Send off-group, off-node queues to target nodes.
+ - Receive consolidated queues from on-group nodes.
+ [further consolidate?]
+ - Receive mythread input queue from off-group, on-node threads
+ - Recieve anythread input queues from off-group off-node
+ [Consolidate input queues ?]
+ - Iterate through consolidated queue for in-group, on-node.
+ - Iterate through consolidated queue for in-group, off-node.
+ - Iterate through input queue for off-group, on-node
+ - Iterate through input queue for off-group, off-node.
+ - Each thread will have to pick subset of entries to handle.
+
+Data transfer of 'non-group' queues, from perspective of each thread:
+ - During process, put off-group stuff into off-group queues.
+ - on-node other threads; and off-node data each have queues.
+ - During process, put own stuff into own input queue.
+ - off-group, on-node queues are handled by their owner threads.
+ - Send off-group, off-node queues to target nodes.
+ - Receive mythread input queue from off-group, on-node threads
+ - Recieve anythread input queues from off-group off-node
+ [Consolidate input queues ?]
+ - Iterate through input queue for off-group, on-node
+ - Iterate through input queue for off-group, off-node.
+ - Each thread will have to pick subset of entries to handle.
+
+.........................................................................
+Setting up multithread scheduling.
+For comparison, here is regular scheduling
+Shell::start:
+ calls Clock::threadStartFunc( void* threadInfo ), no threads.
+Clock::threadStartFunc( void* threadInfo ) is the static thread function.
+ calls Clock::Start in non-thread version, with args in threadInfo
+Clock::Start:
+ If just one tickPtr: advance through the tickPtr for the entire time.
+ If multiple tickPtrs (i.e., many dts):
+ sort the tickPtrs
+ loop while tickPtr[0].nextTime < endTime
+ advance tickPtr0 till nextTime
+ sort again
+ update nextTime.
+ *---*
+
+Multithread scheduling: Assume group-wise queue handling for now.
+Shell::start:
+ Makes barrier. Spawns child threads, with threadStartFunc.
+ Waits for them to join.
+Clock::threadStartFunc( void* threadInfo ) calls tStart in threaded version.
+Clock::tStart()
+ if just one tickPtr, advance through it for the entire time.
+ TickPtr::advance: loop while nextTime_ < endTime. In this loop,
+ call all the Ticks (at different stages)
+ Need to cleanly handle advancing of p->currTime and nextTime_,
+ which are used by all threads. So this must be made thread-safe.
+
+
+ Tick::advance():
+ Qinfo::clearQ( threadId )
+ Note that here there is a Q shared among
+ all threads, and it is treated as readonly.
+ Conn::process.
+ Puts outgoing data into thread-local output Q.
+ Condition: when all other threads are done, the
+ Qs are either merged or put into a frame-buffer
+ so that all threads can now handle entire
+ set as readonly.
+ Or, Barrier: Ensure all threads are done
+ Thread 0: Merge Qs into a frame-buffer, set as readonly
+ Barrier: Ensure thread0 is done before proceeding.
+ Equivalently, the entry into the clearQ routine could
+ be the synchronization point.
+
+ If multiple tickPtrs:
+
+
+
+
+ *---*
+
+Qinfo::readQ( threadId )
+ Reads the data from threadId. It is entirely readonly, and is thread-
+ safe. Different threads can use the same threadId.
+
+Qinfo::clearQ( threadId )
+ Clears the data from threadId; that is, zeroes it out.
+
+The design sequence is that for
+
+------------------------------------------------------------------------------
+
+MPI:
+Async:
+Setup: need to figure out off-node targets. See below for send.
+
+Send:
+Msg has been preconfigured to add to the regular Q, the outgoing Q, or both.
+Shouldn't this be separate Msgs? But it is to the same Element, just to
+a different buffer on it.
+
+ClearQ:
+On-node stuff is as usual.
+Postmasters (or Elements themselves) clear out off-node Qs in a straightforward
+way, since everything is now serialized.
+Once these arrive on the target node, they simply get dumped into the incoming
+Q of the target Element.
+
+
+------------------------------------------------------------------------------
+
+Managing space, specially in chemical models.
+
+Conceptually, each Compartment is enclosed by one or more Geometry
+objects. There may or may not be an adjacent Compartment on the other
+side. The Compartment has a vector of Boundary objects, which are
+managed in a FieldElement.
+The geometry/adjacency relationships are defined by messages from the
+Boundary FieldElement.
+Compartments also have a 'size' and 'dimension'. I haven't yet worked
+out a general way to get this from an arbitrary set of Geometries
+around them, but in principle it can be obtained from this.
+Again, in principle, the size may change during a simulation.
+
diff --git a/docs/developer/Ksolve.txt b/docs/developer/Ksolve.txt
new file mode 100644
index 0000000000..609752a096
--- /dev/null
+++ b/docs/developer/Ksolve.txt
@@ -0,0 +1,101 @@
+API for Ksolve implementation
+
+Introduction.
+This part of the MOOSE documentation describes how fast linear algebra
+solutions of chemical reaction networks are carried out. The equations are
+a system of nonlinear ODEs defined as follows:
+
+dS/dt = N.v
+
+where S is the vector of molecule concentrations
+N is the stoichiometry matrix defining the reaction system, and v is the
+rate vector, that is, the vector of rates of each reaction in the system.
+The rows of N are molecules, and the columns are reactions.
+
+Numerics
+The actual calculations in the Ksolve are done using the GNU Scientific
+Library, GSL. The GSL offers a number of numerical methods, most of which
+are available to the Ksolver. The adaptive timestep Runge Kutta method rk5
+is usually a good choice.
+
+Other roles ofthe Ksolve system
+Other than the calculations, the key role played in the Ksolve is to interface
+between the Element and message-based model structure definition, and the
+contents of the various matrices and vectors that do the number crunching.
+This is in two phases:
+
+Setup: Here the ksolve system has to scan through the reaction system to build
+up the stoichiometry matrix and calculation rules for the rate vector.
+Runtime updates: Here the Ksolver has to respond to any requests from the
+MOOSE model structure for getting or setting values in the reaction sytem.
+
+In addition there are various elaborations for handling interfaces to other
+solvers and numerical engines, such as Smoldyn and the SigNeur system.
+
+
+=============================================================================
+
+System overview
+
+Classes:
+Stoich: Manages the data structures in the simulation. Specifically,
+ molecule vector S
+ initial conditions Sinit
+ Reaction velocity vector v
+ Stoichiometry matrix N
+ Vector of rate terms rates
+ Vector of function terms funcs
+ Mapping from the Ids to S, rates, funcs objMap
+
+ Also has key functions:
+ Set up the model setPath()
+ Update the reaction velocities updateV()
+ Reinitializes conditions reinit()
+ Note that process() is a dummy function.
+
+
+
+GslIntegrator: Numerical engine for Stoich, using the GSL.
+ It has a few simulation control parameters
+ method
+ accuracy
+ stepsize
+ and it has a pointer to the stoich_ class.
+ It also holds internal data structures for GSL.
+
+ It does the actual calculations in the function:
+ process
+
+
+KinSparseMatrix: Efficiently holds the stoichiometry matrix.
+ Derived from SparseMatrix< int >
+ Provides efficient compute operations for getting dS/dt from the
+ molecule vector and the reaction velocity vector.
+ It has some hooks for doing Gillespie type calculations too.
+
+RateTerm: Base class for a large number of derived classes which compute
+ derivatives for various kinds of reactions, like enzymatic,
+ reversible, and so on. Looks up molecule amounts by their indices in
+ the Stoich::S vector.
+
+FuncTerm: Base class for assorted derived classes which compute
+ functions based on molecule arguments looked up by their indices.
+
+
+Zombie classes:
+ These are all derived from the Stoich, and have no C++ fields of their
+ own. Instead they have the MOOSE fields of the class that they
+ are taking over.
+
+ At setup, the 'zombify' function takes all the relevant parameters
+ from the original object, puts them into the Stoich, and replaces
+ the 'data' part of the original object with the Zombie version.
+ Thus all the original messages and Ids are unchanged.
+
+ There is an 'unzombify' function which supposedly does the reverse,
+ but it hasn't been rigorously tested.
+
+ In operation, all fields and functions of the zombified class are
+ handled by accessing the corresponding Stoich fields.
+
+=============================================================================
diff --git a/docs/developer/KsolveGsolveDsolveParallelization.txt b/docs/developer/KsolveGsolveDsolveParallelization.txt
new file mode 100644
index 0000000000..79b8d07f95
--- /dev/null
+++ b/docs/developer/KsolveGsolveDsolveParallelization.txt
@@ -0,0 +1,41 @@
+This file contatins the description of the parallel implementations of Ksolve::process, Gsolve::process, Dsolve::process .
+
+Ksolve :
+ Kinetic solver implements a linear algebra solution for fast computation of the chemical reactions.
+ The process function performs the calculations using the rungekutta method or order 5 on the various voxelpools involved at this timestep of the simulation.
+ This step is parallelized by distributing the voxels among the available threads.
+
+Gsolve :
+ Stochastic solver solves the chemical reactions on a per molecule basis instead of using linear algebra solutions like the Kinetic solver.
+ The parallelization was done by dividing the molecules among the available threads.
+
+Dsolve :
+ Calculates the diffusion gradient for every molecule. The parallelization technique is similar to Gsolve, where we distribute the molecules between the execution threads.
+
+
+Programming Models Used :
+ OpenMP - for the ease of use.
+ Pthreads - for the flexibility.
+
+ To avail a particular parallelization of a particular programming model we set the flag in the .h files of the respective solvers.
+ The environment variable NUM_THREADS, represents the number of threads with which the solvers can be run. It needs to have a value for proper execution.
+
+Performance improvement due to parallelization :
+ Kmeans - 4.5X
+ Gsolve - 5.8X
+ Dsolve - 3.8X
+
+Performances improve with increasing problem sizes.
+
+OpenMP vs Pthreads :
+ Compared to Pthreads based parallelization, OpenMP based parallelization gave better performance.
+ The reason for this is the optimization that is performed by the OpenMP framework.
+ Once the OpenMP framework creates a parallel thread (at the first encounter of a "OpenMP parallel" directive), the threads are kept alive until the end of the program/application.
+ However, with pthreads, the basic parallelization technique is to create the threads whenever a parallel section is encountered and to kill the threads once the work is done.
+ This creates a heavy burden in cases where the overhead of thread creation-destruction is high.
+ Hence, the pthread implementation was modified such that it creates threads once at the start of the application and killed at the end of the it.
+ The threads are however allowed to work only when the main-thread has reached a point where parallel work is possible.
+ For the rest of the time, the worker-threads are kept idle. This behaviour is achieved by the use of semaphores.
+ Each worker-main thread pair is controlled using a pair of semaphores, using which messages are passed in between them.
+ This optimization improved the performance of pthread-based implementation and we achived the speedups equivalent to the ones with OpenMP.
+
diff --git a/docs/developer/MessageObjectLookup.txt b/docs/developer/MessageObjectLookup.txt
new file mode 100644
index 0000000000..8cdde37ae8
--- /dev/null
+++ b/docs/developer/MessageObjectLookup.txt
@@ -0,0 +1,23 @@
+How to go from Msg to corresponding Element and object, and back.
+
+The system sets up a set of Manager Elements, one for each Msg subclass
+(Single, OneToAll, Sparse, and so on).
+These Manager Elements are OneDimGlobals, that is, an array.
+The Manager base data class is just a MsgId (with some added functions).
+
+So every time a message is created, it figures out which Manager it belongs to,
+and pushes back its MsgId onto the array. The Msg constructor calls
+MsgManager::addmsg( MsgId mid, Id managerId ).
+
+
+There is a static vector of unsigned ints, Msg::lookUpDataId_, indexed by
+msgid, to look up the dataIds for each msg. So:
+Msg to DataId: Msg::lookUpDataId_[msg->msgid]
+
+object to msg: Msg::safeGetMsg( getMid() );
+where the getMid function just returns the mid_ value of the MsgManager.
+
+In use, the derived MsgManager, such as SparseMsgWrapper, typecasts the Msg to
+the appropriate type and does stuff with it.
+
+
diff --git a/docs/developer/PortingOldMooseObjects.txt b/docs/developer/PortingOldMooseObjects.txt
new file mode 100644
index 0000000000..abbc552daa
--- /dev/null
+++ b/docs/developer/PortingOldMooseObjects.txt
@@ -0,0 +1,36 @@
+1. In the initCinfo function, at the end where the static Cinfo is created,
+we need to make the Dinfo allocation a static one.
+
+1a. above the static Cinfo function, add a line
+ static Dinfo< T > dinfo;
+1b. Replace the line
+ new Dinfo< T >()
+ with
+ &dinfo
+
+2. Eliminate all instances of Qinfo. Some functions may pass it in as an
+argument, just eliminate the argument.
+
+3. In 'send' calls, eliminate the threadInfo argument.
+
+4. Check that you are consistent with the naming scheme for all SrcFinfos:
+ they must have a suffix 'Out'.
+
+5. Use Element-level operations with care. Many commands
+are strictly per-node, and will do odd things if invoked in parallel.
+id(), getName(), numData(), getNode(), hasFields(), isGlobal() and
+getNumOnNode() are safe on any node. But don't try to do any data access
+operations. Use SetGet calls for data access.
+
+6. In the unlikely event that you are dealing with Zombies, the Zombie
+handling has changed. Now the ZombieSwap function just takes the new
+Cinfo and does three things:
+ - allocates new data with this new Cinfo, using the same size.
+ - deletes the old data
+ - Replaces the Cinfo.
+This means that if you want to transfer any values over from the old to the
+new class, you need to extract the values first, zombify, and then put them
+into the new class.
+
+7. In the even less likely event that you are dealing with DataHandlers,
+ talk to Upi. The DataHandlers have been eliminated.
diff --git a/docs/developer/PythonRecommendations.org b/docs/developer/PythonRecommendations.org
new file mode 100644
index 0000000000..370451e7aa
--- /dev/null
+++ b/docs/developer/PythonRecommendations.org
@@ -0,0 +1,135 @@
+#+TITLE: Recommended coding practices for Python scripting
+Python is a very flexible scripting language with very few rules
+imposed by the language designers. Thus you are free to shoot yourself
+in the foot any way you like and nobody is going to stop you. A
+popular slogan summarizing the Python philosophy is "We are all
+consenting adults here".
+
+But not everybody who writes code is an "adult" in the programming
+sense. And even seasoned programmers have a tendency to get entangled
+by their own "smart" code to render them immobile
+(programmatically). Time and again we need to be reminded of the
+basics.
+
+There are some pretty common ideas that keep coming up in various
+mailing list discussions and here is a collection of aphorisms, tips,
+tricks and links to such things.
+
+* KISS: Keep it short and simple
+** Logical program units should fit in one screen
+ That is not a hard limit, but if your function definition is too
+ long then you may want to rethink it. A function should do one well
+ defined task. Check your function to see if you have put in
+ multiple disparate tasks inside one function.
+
+ See
+ [[http://stackoverflow.com/questions/475675/when-is-a-function-too-long]]
+
+** More than five logical units at any level is too much
+ Remember that code has to be read and understood by average human
+ beings. And five to seven is the number of items most people can
+ easily keep in mind. So it is a good idea to compose things with
+ those many elements. Think of data flow diagrams.
+
+** "If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
+ That was Linus Torvalds in 1995. While it sounds a bit drastic,
+ loops nested more than three levels need serious
+ consideration. Most likely you can find a better way to write that
+ code if you think hard enough.
+
+** "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
+ - Brian Kernighan.
+
+ What you thought was a clever trick is likely to cause a lot of
+ pain in future. If it is too clever, two weeks down the line you
+ will most probably have no clue how it works. Forget about other
+ people reading your code being able to understand your code. If you
+ think the trick is really necessary, document it!
+
+** Write idiomatic code
+ Like natural (human) languages programming languages also gather
+ standard idioms. Some ways of programming turn out to be so useful
+ that everybody starts using them. You will be more productive in a
+ new programming language (and more readable to your fellow
+ programmers) if you master these idioms. A nice collection of such
+ idioms for Python is available here:
+ [[http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html]]
+
+* Document
+** "You know you're brilliant, but maybe you'd like to understand what you did 2 weeks from now."
+ - Linus Torvalds.
+
+ While most software companies reuire their programmers to document
+ their work, many beginning hackers and academic programmers think
+ "I know what I am doing! I know this code inside out, there is no
+ need for documentation." As Linus correctly pointed out, you, two
+ weeks from writing a piece of code, are a different person from the
+ one who wrote it. And if your code was too clever, most likely you
+ will not be understand it later (here comes the quote by Brian
+ Kernighan). So better document your code for your own good.
+
+* Think
+** Before you write anything, think!
+ It is often better to make rough outlines using pen and paper
+ before you start typing your code. Just like writing an essay or a
+ novel, programs need a coherent flow of thought, and an outline
+ helps with that.
+
+** "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."
+ Brian Kernighan wrote that in 1979 and it still applies no matter
+ how proficient you are with gdb or some other debugger. Jumping
+ into a debugger without re-reading your code is a sure sign that
+ you are not using your brain properly. A debugger can help you
+ narrow down the code you need to investigate, but usually a second
+ reading of your code (better after a break) is the most efficient
+ and educational way to find and fix a bug.
+
+* Fast Python: Some points regarding performance for more advanced users (but good to practice these from the beginning)!
+** These points are quoted from a post by Guido van Rossum on Google+ on 11 Sep 2012
+ - Avoid overengineering datastructures. Tuples are better than
+ objects (try namedtuple too though). Prefer simple fields over
+ getter/setter functions.
+
+ - Built-in datatypes are your friends. Use more numbers, strings,
+ tuples, lists, sets, dicts. Also check out the collections
+ library, esp. deque.
+
+ - Be suspicious of function/method calls; creating a stack frame is
+ expensive.
+
+ - Don't write Java (or C++, or Javascript, ...) in Python.
+
+ - Are you sure it's too slow? Profile before optimizing!
+
+ - The universal speed-up is rewriting small bits of code in C. Do
+ this only when all else fails.
+
+ - I'm -0 on using generator[ expression]s unless you know you have
+ huge lists of values to iterate over. The concrete list
+ [comprehension] is usually faster than the genexpr until memory
+ allocation becomes critical.
+
+** Michael Foord added the following points to the same post by Guido
+ Understand the performance characteristics of basic operations on
+ the builtin types. For example
+
+ - Checking for membership in a list is O(N) but for a set or
+ dictionary it is O(1).
+
+ - Adding lists and tuples creates new objects.
+
+ - Inserting to the left of a list is O(N) whilst append is O(1)
+ (use a deque instead). And so on.
+
+** Richard Merren added to the same post by Guido
+ - Use dicts to store and retrieve information--they are very fast.
+
+ - Break your task up to simple and testable/verifiable functions so
+ that you make less errors on each part.
+
+ - Don't be afraid to give variables and functions long and
+ descriptive names so you can reread your code and figure out what
+ it does.
+
+ - Do things the way they make sense to you and don't worry about
+ optimizing your code until you find out which part is slow.
diff --git a/docs/developer/ReduceOperations b/docs/developer/ReduceOperations
new file mode 100644
index 0000000000..d1206523f1
--- /dev/null
+++ b/docs/developer/ReduceOperations
@@ -0,0 +1,154 @@
+Overview
+Reduce operations are those that scan through many objects, condensing some
+attribute into a reduced form. For example, we might use a reduce operation to
+compute statistics on Vm across neurons in a population in a model
+spread across multiple nodes. Another common use is to keep track of the
+max field dimension in a variable size field such as the number of synapses on
+a channel or an IntFire neuron.
+
+
+There are two modes of operation:
+1. through a regular Reduce Msg, originating from a ReduceFinfo on a regular
+object, and terminating on any 'get' DestFinfo. ReduceFinfos are derived from
+SrcFinfos. They are templated on the type of the 'get' function, and on
+the type of the reduce class (for example, a triad of mean, variance and count).
+The ReduceFinfo constructor takes as an argument a 'digest' function. The
+job of the digest function is to take an argument of the reduce class
+(which has the contents of the entire reduction operation),
+and do something with it (such as saving values into the originating object).
+
+2. Through Shell::doSyncDataHandler. This takes the synced Elm and its
+FieldElement as Ids, and a string for the field to be reduced, assumed an
+unsigned int. It creates a temporary ReduceMsg from the Shell to the Elm with
+the field to be reduced. Here the digest function just takes the returned
+ReduceMax< uint > and puts the max value in Shell::maxIndex. It then posts
+the ack. The calling Shell::doSyncDataHandler waits for the ack, and when it
+comes, it calls a 'set' function to put the returned value into the
+FieldDataHandler::fieldDimension_.
+
+At some point I may want to embed the doSyncDataHandler into any of the
+'set' functions that invalidate fieldDimension. Problem is race conditions,
+where a set function would call the doSync stuff which internally has its
+own call to Ack-protected functions, like 'set'. Must fix.
+
+
+
+The setup of the Reduce functionality is like this:
+
+- Create and define the ReduceFinfo.
+ ReduceFinfo< T, F, R >( const string& name, const string& doc,
+ void ( T::*digestFunc )( const Eref& er, const R* arg )
+ Here T is the type of the object that is the src of the ReduceMsg,
+ F is the type of the returned reduded field
+ R is the Reduce class.
+
+- Create and define the ReduceClass. This does two things:
+ - Hold the data being reduced
+ - Provide three functions, for primaryReduce, secondaryReduce, and
+ tertiraryReduce. We'll come to these in a little while.
+
+-
+-
+
+
+When executing reduce operations from the Shell::doSyncDataHandler, this
+ is what happens:
+- Shell::doSyncDataHander does some checking, then
+ requestSync.send launches the request, and waits for ack
+ - Shell::handleSync handles the request on each node
+ - Creates a temporary ReduceMsg from Shell to target elm
+ - The ReduceMsg includes a pointer to a const ReduceFinfoBase*
+ which provides two functions:
+ - makeReduce, which makes the ReduceBase object
+ - digestReduce, which refers to the digestFunc of
+ the calling object.
+ - Sends a call with a zero arg on this Msg.
+ - Msg is handled by ReduceMsg::exec.
+ - This extracts the fid, which points to a getOpFunc.
+ - It creates the derived ReduceBase object.
+ - It adds the ReduceBase object into the ReduceQ
+ - indexed by thread# so no data overwrites.
+ - It scans through all targets on current thread and uses the
+ derived virtual function for ReduceBase::primaryReduce
+ on each.
+ Overall, for each thread, the 'get' values get reduced and stored
+ into the ReduceBase derived class in the queue. There is such an
+ object for each thread.
+
+ - Nasty scheduling ensues for clearing the ReduceQ.
+ - in Barrier 3, we call Clock::checkProcState
+ - this calls Qinfo::clearReduceQ
+ - This marches through each thread on each reduceQ entry
+ - Uses the ReduceBase entry from the zeroth thread
+ as a handle.
+ - Calls ReduceBase::secondaryReduce on each entry for
+ each thread.
+ - This is done in an ugly way using
+ findMatchingReduceEntry, could be cleaned up.
+ - Calls ReduceBase::reduceNodes
+ - If MPI is running this does an instantaneous
+ MPI_Allgather with the contents of the
+ ReduceBase data.
+ - Does ReduceBase::tertiaryReduce on the received data
+/// New version
+ - calls Element::setFieldDimension directly using ptr.
+/// End of new stuff
+ - returns isDataHere.
+
+
+ - If reduceNodes returns true, calls ReduceBase::assignResult
+ - This calls the digestReduce function, which is
+ Shell::digestReduceMax
+
+////////////////////////////////////////////////////////////////////////
+// Old version
+ - Shell::digestReduceMax assigns maxIndex_ and sends ack
+ - ack allows doSyncDataHandler to proceed
+ - calls Field::set on all tgts to set "fieldDimension" to maxIndex_.
+////////////////////////////////////////////////////////////////////////
+ - Should really do a direct ptr assignment, within the
+ assignResult function: Assume here that we want the assignment
+ to be reflected on all nodes.
+
+The current code is grotty on several fronts:
+ - The findMatchingReduceEntry stuff could be fixed using a more
+ sensible indexing.
+ - Should use direct ptr assignment for fieldDimension within
+ assignResult.
+ - I probably don't need to pass in both the FieldElement and its parent.
+
+When executing reduce operations from messages, this is what happens:
+- ReduceFinfo.send launches the request. No args.
+ - The ReduceMsg::exec function (which is called per thread):
+ - This extracts the fid, which points to a getOpFunc.
+ - It creates the derived ReduceBase object.
+ - It adds the ReduceBase object into the ReduceQ
+ - indexed by thread# so no data overwrites.
+ - It scans through all targets on current thread and uses the
+ derived virtual function for ReduceBase::primaryReduce
+ on each.
+ - Now we go again to the scheduling system to clear ReduceQ.
+ - in Barrier 3, we call Clock::checkProcState
+ - this calls Qinfo::clearReduceQ
+ - This marches through each thread on each reduceQ entry
+ - Uses the ReduceBase entry from the zeroth thread
+ as a handle.
+ - Calls ReduceBase::secondaryReduce on each entry for
+ each thread.
+ - This is done in an ugly way using
+ findMatchingReduceEntry, could be cleaned up.
+ - Calls ReduceBase::reduceNodes
+ - If MPI is running this does an instantaneous
+ MPI_Allgather with the contents of the
+ ReduceBase data.
+ - Does ReduceBase::tertiaryReduce on the received data
+ - returns isDataHere.
+
+ - If reduceNodes returns true, calls ReduceBase::assignResult
+ on the originating Element.
+ - This calls the digestReduce function, which is
+ what was given to the ReduceFinfo when it was created.
+ - This does whatever field assignments are needed,
+ internally to the originating element which asked for
+ the field values.
+ Note no acks. It happens in Barrier 3 is all.
diff --git a/docs/developer/Scheduling.txt b/docs/developer/Scheduling.txt
new file mode 100644
index 0000000000..9c8b02a285
--- /dev/null
+++ b/docs/developer/Scheduling.txt
@@ -0,0 +1,145 @@
+This section describes the MOOSE multithreaded scheduling and how it
+interfaces with the parser, the Shell, and with MPI calls to other nodes.
+
+The code for this is mostly in shell/ProcessLoop.cpp.
+
+
+Overview:
+MOOSE sets off a number of threads on each node. If the machine has C cores,
+then C threads are used for computing, 1 thread is used for managing MPI
+data transfer, and 1 thread is used on node 0 only for interfacing between
+the Shell and the Parser. The number of compute threads C can be overridden on
+the command line, but defaults to the number of hardware cores.
+
+All threads go through process loops. As long as MOOSE is running, the system
+keeps the threads going through process loops, and keeps them in sync through
+three barriers per cycle around the loop.
+
+Barriers are checkpoints where the system guarantees that each
+thread will wait till all threads have arrived. MOOSE barriers differ from
+regular Pthreads barriers in that there is a special, single-thread function
+executed within each barrier. You can think of the net effect of a bundle of
+wires which have tight ties (barriers) at three points. Between the ties
+the wires hang loose and do their own calculations, but everything is brought
+into sync at the ties.
+
+When MOOSE is idling, all these threads continue but the Process call does
+not get sent to compute objects.
+
+When MOOSE is running a calculation, then the Process call does get issued.
+
+
+Details:
+
+As long as MOOSE is running, and whether or not it is doing a simulation,
+the following process loop operates:
+
+
+Stage Thread# Description
+Phase 1 0:C-1 Carry out Process calculations on all simulated objects
+ C Do nothing.
+ C+1 On node 0 only: Lock mutex for input from parser.
+
+Barrier1 Single Clear StructuralQ. This accumulates operations
+ which alter the structure of the simulation, and thus
+ must be done single-threaded.
+ Swap inQ and outQ.
+ At the end of this barrier, all Process calculations
+ are all done and have sent their messages. Structural
+ operations have been done. The
+ message queues have been swapped so that data is
+ ready to be read and acted upon.
+
+Phase 2 0:C-1 Clocks juggle the Ticks (on thread 0 only).
+ Deliver and execute local node messages.
+ Go into a loop to handle off-node messages.
+ C Go into a loop to broadcast/receive all off-node msgs,
+ one node at a time.
+ This has to be done with a predetermined data block
+ size, which is judged as a bit over the median data
+ size. On the occasions where the data to come is bigger
+ than this block, there is an immediate resend initiated
+ that transfers the bigger block.
+ At present we don't have dynamic resizing of the
+ median block size, but it should not be hard to set up.
+ C+1 On node 0 only: Do nothing.
+
+Barrier 2 Single Swap mpiInQ and mpiRecvQ. This barrier is encountered
+ in the same loop as Phase 2, once for each node.
+ At the end of each round through this barrier, all
+ off-node messages on the indexed node have been sent,
+ received, and acted upon.
+
+Phase 3 0:C-1 Complete execution for last node.
+ C Do nothing
+ C+1 Unlock the mutex for input from parser
+
+Barrier 3 Single Clear reduce operations, that is, operations where each
+ thread and each node collates information and reduces it
+ to a single quantity to go to either the master node
+ or to all nodes.
+ Change Clock state, between run, reinit, stop etc.
+ At the end of this barrier, all messages from all
+ nodes have been handled. The Clock knows what to
+ do for the next cycle. Typicaly it goes back to Phase 1.
+
+Messaging, scheduling, and threads:
+Broadly, at any instant during the Phases, there are two available Queues:
+the inQ and the outQ.
+InQ: The inQ is a single, readonly, collated queue which
+is updated during Barrier 1. inQ has all the data from all the threads, and
+all the compute threads read it. It also contains all the data that needs to
+go off-node.
+outQ: The outQ is subdivided into one writable queue per thread, so there is
+no chance of overwriting data. Starting from Phase 2, the outQ accumulates
+messaging entries. This can be from messages sent in response to other
+messages in Phase 2, or more commonly from messages sent during the Process
+operation in Phase 1. Finally, in Barrier1 at swapQ, all the content from
+all the outQs is stitched together to make up the inQ, and all the subQs from
+the outQ are cleared.
+
+This same theme is repeated between nodes. The mpiInQ is the collated Q that
+has arrived from the sending node, and its contents are identical to the inQ
+of the sending node. The mpiRecvQ is a buffer sitting waiting for the next
+cycle of data to come from the next node.
+
+
+Clocks and scheduling.
+
+The Clock class coordinates the operation of a vector of Ticks. There
+is a single Clock object ( ClockId = 1 ) in the simulation.
+The Tick objects are present in an array on the Clock. Each Tick has a
+timestep (dt), and connects to a target Elements through messages.
+Unlike regular messages, which send their requests through the Queueing system,
+the Tick directly traverses through all messages, and calls the
+'process' function on the target Elements. This hands it down to the
+DataHandler, which iterates through all the target objects within the Element,
+and calls the specified Process function. Any function having the
+appropriate arguments could be called here. This is how different phases of
+Process, as well as Reinit, are called through the same mechanism.
+
+
+In Phase 1:
+The Clock and its child Ticks are called in parallel by all the threads. The
+thread decomposition is done by the DataHandler.
+
+In Phase 2:
+On thread 0 only, the Clock handles advancing of timesteps on Phase 2.
+ After each Tick is called, it advances its current Time by dt.
+ The sequencing for advancing Tick timings is done by the Clock, by
+ brute force sorting of the Ticks after every pass through the Process
+ loop.
+ Ticks are sorted first by dt, and if that is the same, by their
+ own index. So if Tick 2 and 3 have the same dt, Tick 2 will always
+ be called first.
+
+In Barrier 3:
+The Clock executes Clock::checkProcState, which among other things decides
+whether to keep doing what it was (typically running Process or idling).
+Calls to alter ProcState are called only during phase 2, typically resulting
+from the Shell sending messages to the clock to do things.
+
+Reinit goes through almost identical phases and operations as the steps
+ for advancing the simulation. The main difference is that the
+ function called on the target objects at Reinit, is of course, reinit.
+
diff --git a/docs/developer/doxygen-API.cpp b/docs/developer/doxygen-API.cpp
new file mode 100644
index 0000000000..6511ba0741
--- /dev/null
+++ b/docs/developer/doxygen-API.cpp
@@ -0,0 +1,408 @@
+/**
+\page AppProgInterface Applications Programming Interface, API. Async13 branch.
+
+\section DataStructs Key Data structures
+\subsection DataStructOverview Overview
+MOOSE represents all simulation concepts through objects. The API specifies
+how to manipulate these objects. Specifically, it deals with their
+creation, destruction, field access, computation, and exchange of data
+through messages.
+
+Objects in MOOSE are always wrapped in the Element container class.
+Each Element holds an array of Objects, sized from zero to a very large
+number limited only by machine memory.
+
+The functions and fields of each class in MOOSE are defined in Finfos:
+Field Info classes. These are visible to users as fields.
+
+Data communication between Elements (that is, their constitutent Objects)
+is managed by the Msg class: messages.
+
+These three concepts: Elements, Finfos, and Msgs - are manipulated by
+the API.
+
+\subsection DataStructElementAccess Id: Handles for Elements
+
+Each Element is uniquely identified by an \b Id. Ids are consistent
+across all nodes and threads of a multiprocessor simulation. Ids are
+basically indices to a master array of all Elements. Ids are used by
+the Python system too.
+
+\subsection DataStructElementClasses Element classes: Handling Objects within elements.
+The \b Element is a virtual base class that manages objects.
+It deals with creation, resizing, lookup and
+destruction of the data. It handles load balancing. It manages fields.
+It manages messages.
+
+\subsection DataStructObjectClasses Object classes: Computational and data entities in MOOSE.
+\b Objects in MOOSE do the actual work of computation and data structures. They
+are insulated from the housekeeping jobs of creation, interfacing to scripts
+and to messaging. To do this they present a very stereotyped interface to
+the MOOSE Element wrapper. The following are the essential components of this
+interface. These are discussed in more detail in the document
+"Building New MOOSE Classes."
+\subsubsection ObjectsInMooseConstructor Object Constructors
+All MOOSE classes need a constructor \b Object() that correctly initializes
+all fields. This constructor does not take any arguments. It can be omitted
+only if the default C++ constructor will guarantee initialization.
+\subsubsection ObjectsInMooseAssignment Object assignment operator
+MOOSE needs to know how to copy objects. By default it does a bit-copy.
+If this is not what you need, then you must explicitly specify an assignment
+operator. For example, if you set up pointers and do not want your objects
+to share the data in the pointers, you will want to specify an assignment
+operator to rebuild the contents of the pointers.
+\subsubsection ObjectsInMooseFinfo Object fields.
+MOOSE needs to know what fields an object has. Fields can be of three main
+kinds: value fields, message source fields, and message destination
+(aka function) fields. All these fields are managed by \b Finfo objects
+(Field infos), which are in turn organized by the Cinfo (Class Info) objects
+as described below. In a nutshell, all fields are associated with a name,
+access functions, and some documentation by creating Finfos for them, and
+all the Finfos are stored in the Cinfo.
+\subsubsection ObjectsInMooseCinfo Object class information.
+Every MOOSE class is managed by a \b Cinfo (Class Info) object. This is defined
+in a static initializer function in every class. The Cinfo stores
+the class name and documentation, how to look up fields, how to
+handle data, and so on.
+\subsubsection ObjectsInMooseMsgs Object message sending.
+Any MOOSE object can call any function in any other object. This is managed
+by the message source fields: \b SrcFinfos. SrcFinfos defined as above all
+present a \b send() function, which traverses all targets of the message and
+calls the target function with the specified arguments. SrcFinfos are typed, so
+precisely the correct number and type of arguments are always sent. Messages
+can go across nodes, the user does not need to do anything special to
+arrange this.
+
+\subsection DataStructObjectAccess ObjId: Identifiers for Objects within elements.
+
+The \b ObjId specifies a specific object within the Element. All Elements
+manage a linear array of identical objects, which can have any number of
+entries greater than zero, up to the limits of memory. The ObjId::dataIndex
+field is the index into this array.
+In addition, the ObjId has a field ObjId::fieldIndex that comes into use in a
+subset of objects. This is used when each object has to manage arrays of
+fields, which are made visible as FieldElements. For example, one could have
+an array of receptor channels, each of which manages an array of synapses.
+Thus to fully specify a synapse, one uses both the ObjId::dataIndex to
+specify the parent receptor, and the ObjId::fieldIndex to specify the synapse
+on that receptor.
+
+\subsection DataStructObjId ObjId: Fully specified handle for objects.
+
+The ObjId is a composite of Id and DataId. It uniquely specifies any
+entity in the simulation. It is consistent across nodes.
+In general, one would use the ObjId for most Object manipulation,
+field access, and messaging API calls.
+The ObjId can be initialized using a string path of an object.
+The string path of an object can be looked up from its ObjId.
+
+\subsection DataStructTrees Element hierarchies and path specifiers.
+Elements are organized into a tree hierarchy, much like a Unix file
+system. This is similar to the organization in GENESIS. Since every
+Element has a name, it is possible to traverse the hierarchy by specifying
+a path. For example, you might access a specific dendrite on cell 72 as
+follows:
+
+\verbatim
+/network/cell[72]/dendrite[50]
+\endverbatim
+
+Note that this path specifier maps onto a single ObjId.
+Every object can be indexed, and if no index is given then it assumed
+that it refers to index zero. For example, the above path is identical
+to:
+
+\verbatim
+/network[0]/cell[72]/dendrite[50]
+\endverbatim
+
+Path specifiers can be arbitrarily nested. Additionally, one can have
+single dimensional arrays at any level of nesting. Here is an example
+path with nested arrays:
+
+\verbatim
+/network/layerIV/cell[23]/dendrite[50]/synchan/synapse[1234]
+\endverbatim
+
+\subsection ObjIdAndPaths ObjIds, paths, and dimensions.
+Objects sit on the Elements, which follow a tree hierarchy. There are
+two ways to find an object.
+First, the ObjId completely identifies an object no matter where it is in
+the object tree.
+Second, one can traverse the Element tree using indices to identify
+specific Objects. This too uniquely identifies each Object.
+Every ObjId has a 'parent' ObjId, the exception being the root ObjId
+which is its own parent.
+Any ObjId can have its own 'child' objects in the tree.
+The tree cannot loop back onto itself.
+Objects are always stored as linear arrays.
+
+\verbatim
+/foo[0]/bar
+\endverbatim
+is a different object from
+\verbatim
+/foo[1]/bar
+\endverbatim
+
+Some useful API calls for dealing with the path:
+
+ObjId::ObjId( const string& path ): Creates the ObjId pointing to an
+ already created object on the specified path.
+
+string ObjId::path(): Returns the path string for the specified ObjId.
+
+\verbatim
+ObjId f2( "/f1[2]/f2" );
+assert( f2.path() == "/f1[2]/f2[0]" );
+\endverbatim
+
+There is a special meaning for the path for synapses. Recall that the
+ObjId for synapses (which are FieldElements of SynChans) has two
+indices, the DataIndex and the FieldIndex. The DataIndex of the
+synapse is identical to that of its parent SynChan.
+This is illustrated as follows:
+
+\verbatim
+ObjId synchan( "/cell/synchan[20] );
+assert( synchan.dataIndex == 20 );
+
+ObjId synapse( "/cell/synchan[20]/synapse[5]" );
+assert( synapse.dataIndex == 20 );
+assert( synapse.fieldIndex == 5 );
+\endverbatim
+
+\subsection Wildcard_paths Wildcard paths
+Some commands take a \e wildcard path. This compactly specifies a large
+number of ObjIds. Some example wildcards are
+
+\verbatim
+/network/## // All possible children of network, followed recursively
+/network/# // All children of network, only one level.
+/network/ce# // All children of network whose name starts with 'ce'
+/network/cell/dendrite[] // All dendrites, regardless of index
+/network/##[ISA=CaConc] // All descendants of network of class CaConc
+/soma,/axon // The elements soma and axon
+\endverbatim
+
+
+\section FieldAccess Setting and Getting Field values.
+\subsection FieldAccessOverview Overview
+There is a family of classes for setting and getting Field values.
+These are the
+\li SetGet< A1, A2... >::set( ObjId id, const string& name, arg1, arg2... )
+and
+\li SetGet< A >::get( ObjId id, const string& name )
+functions. Here A1, A2 are the templated classes of function arguments.
+A is the return class from the \e get call.
+
+Since Fields are synonymous with functions of MOOSE objects,
+the \e set family of commands is also used for calling object functions.
+Note that the \e set functions do not have a return value.
+
+The reason there has to be a family of classes is that all functions in
+MOOSE are strongly typed. Thus there are SetGet classes for up to six
+arguments.
+
+
+\subsection FieldAccessExamples Examples of field access.
+1. If you want to call a function foo( int A, double B ) on
+ObjId oid, you would do:
+
+\verbatim
+ SetGet2< int, double >::set( oid, "foo", A, B );
+\endverbatim
+
+2. To call a function bar( int A, double B, string C ) on oid:
+\verbatim
+ SetGet3< int, double, string >::set( oid, "bar", A, B, C );
+\endverbatim
+
+3. To assign a field value "short abc" on object oid:
+\verbatim
+ Field< short >::set( oid, "abc", 123 );
+\endverbatim
+
+4. To get a field value "double pqr" on object oid:
+\verbatim
+ double x = Field< short >::get( oid, "pqr" );
+\endverbatim
+
+5. To assign the double 'xcoord' field on all the objects on
+element Id id, which has an array of the objects:
+\verbatim
+ vector< double > newXcoord;
+ // Fill up the vector here.
+ Field< double >::setVec( id, "xcoord", newXcoord );
+\endverbatim
+ Note that the dimensions of newXcoord should match those of
+ the target element.
+
+ You can also use a similar call if it is just a function on id:
+\verbatim
+ SetGet1< double >::setVec( id, "xcoord_func", newXcoord );
+\endverbatim
+
+6. To extract the double vector 'ycoord' field from all the objects on id:
+\verbatim
+ vector< double > oldYcoord; // Do not need to allocate.
+ Field< double >::getVec( id, "ycoord", oldYcoord );
+\endverbatim
+
+7. To set/get LookupFields, that is fields which have an index to lookup:
+\verbatim
+ double x = LookupField< unsigned int, double >::get( objId, field, index );
+ LookupField< unsigned int, double >::set( objId, field, index, value );
+\endverbatim
+
+\section APIcalls API system calls
+\subsection FieldAccessOverview Overview
+There is a special set of calls on the Shell object, which function as the
+main MOOSE programmatic API. These calls are all prefixed with 'do'. Here is
+the list of functions:
+
+\li Id doCreate( string type, Id parent, string name, vector< unsigned int > dimensions );
+\li bool doDelete( Id id )
+\li MsgId doAddMsg( const string& msgType, ObjId src, const string& srcField, ObjId dest, const string& destField);
+\li void doQuit();
+\li void doStart( double runtime );
+\li void doReinit();
+\li void doStop();
+\li void doMove( Id orig, Id newParent );
+\li Id doCopyId orig, Id newParent, string newName, unsigned int n, bool copyExtMsgs);
+\li Id doFind( const string& path ) const
+\li void doSetClock( unsigned int tickNum, double dt )
+\li void doUseClock( string path, string field, unsigned int tick );
+\li Id doLoadModel( const string& fname, const string& modelpath );
+
+
+
+\section ClockScheduling Clocks, Ticks, and Scheduling
+\subsection ClockOverview Overview
+Most of the computation in MOOSE occurs in a special function called
+\e process,
+which is implemented in all object classes that advance their internal
+state over time. The role of Clocks and Ticks is to set up the sequence of
+calling \e process for different objects, which may have different intervals
+for updating their internal state. The design of scheduling in moose is
+similar to GENESIS.
+
+As a simple example, suppose we had six objects, which had to advance their
+internal state with the following intervals:
+\li \b A: 5
+\li \b B: 2
+\li \b C: 2
+\li \b D: 1
+\li \b E: 3
+\li \b F: 5
+
+Suppose we had to run this for 10 seconds. The desired order of updates
+would be:
+
+\verbatim
+Time Objects called
+1 D
+2 D,B,C
+3 D,E
+4 D,B,C
+5 D,A,F
+6 D,B,C,E
+7 D
+8 D,B,C
+9 D,E
+10 D,B,C,A,F
+\endverbatim
+
+\subsection ClockReinit Reinit: Reinitializing state variables.
+In addition to advancing the simulation, the Clocks and Ticks play a closely
+related role in setting initial conditions. It is required that every object
+that has a \e process call, must have a matching \e reinit function. When the
+command \e doReinit is given from the shell, the simulation is reinitialized
+to its boundary conditions. To do so, the \e reinit function is called in the
+same sequence that the \process would have been called at time 0 (zero).
+For the example above, this sequence would be:\n
+D,B,C,E,A,F
+
+In other words, the ordering is first by dt for the object, and second by
+the sequence of the object in the list.
+
+During reinit, the object is expected to restore all state variables to their
+boundary condition. Objects typically also send out messages during reinit
+to specify this boundary condition value to dependent objects. For example,
+a compartment would be expected to send its initial \e Vm value out to a
+graph object to indicate its starting value.
+
+\subsection ClockSetup Setting up scheduling
+The API for setting up scheduling is as follows:\n
+1. Create the objects to be scheduled.\n
+2. Create Clock Ticks for each time interval using
+
+\verbatim
+ doSetClock( TickNumber, dt ).
+\endverbatim
+
+In many cases it is necessary to have a precise sequence of events
+ocurring at the same time interval. In this case, set up two or more
+Clock Ticks with the same dt but successive TickNumbers. They will
+execute in the same order as their TickNumber. \n
+Note that TickNumbers are unique. If you reuse a TickNumber, all that
+will happen is that its previous value of dt will be overridden.
+
+Note also that dt can be any positive decimal number, and does not
+have to be a multiple of any other dt.
+
+3. Connect up the scheduled objects to their clock ticks:
+
+\verbatim
+ doUseClock( path, function, TickNumber )
+\endverbatim
+
+Here the \e path is a wildcard path that can specify any numer of objects.\n
+The \e function is the name of the \e process message that is to be used. This
+is provided because some objects may have multiple \e process messages.
+The \e TickNumber identifies which tick to use.
+
+Note that as soon as the \e doUseClock function is issued, both the
+\e process and \e reinit functions are managed by the scheduler as discussed
+above.
+
+\subsection ClockSchedExample Example of scheduling.
+As an example, here we set up the scheduling for the same
+set of objects A to F we have discussed above.\n
+First we set up the clocks:
+
+\verbatim
+ doSetClock( 0, 1 );
+ doSetClock( 1, 2 );
+ doSetClock( 2, 3 );
+ doSetClock( 3, 5 );
+\endverbatim
+
+Now we connect up the relevant objects to them.
+
+\verbatim
+ doUseClock( "D", "process", 0 );
+ doUseClock( "B,C", "process", 1 );
+ doUseClock( "E", "process", 2 );
+ doUseClock( "A,F", "process", 3 );
+\endverbatim
+
+Next we initialize them:
+
+\verbatim
+ doReinit();
+\endverbatim
+
+During the \e doReinit call, the \e reinit function of the objects would be
+called in the following sequence:
+\verbatim
+ D, B, C, E, A, F
+\endverbatim
+
+Finally, we run the calculation for 10 seconds:
+
+\verbatim
+ doStart( 10 );
+\endverbatim
+
+*/
diff --git a/docs/developer/doxygen-design-document.cpp b/docs/developer/doxygen-design-document.cpp
new file mode 100644
index 0000000000..31957ab989
--- /dev/null
+++ b/docs/developer/doxygen-design-document.cpp
@@ -0,0 +1,50 @@
+/**
+\page DesignDocument Design Document
+
+\section DD_Goals Goals
+- Cleanup.
+- Handle multithreading and MPI from the ground up.
+
+\section DD_WhyDoThis Why do this?
+It is a huge amount of work to refactor a large existing code base. This is
+needed here, and was in fact anticipated, for two reasons:
+- We needed the experience of building a fairly complete, functioning system
+ to know what the underlying API must do.
+- The original parallel stuff was a hack.
+
+This redesign does a lot of things differently from the earlier MOOSE messaging.
+- Introduces a buffer-based data transfer mechanism, with a fill/empty
+ cycle to replace the earlier function-call mechanism. The fill/empty
+ cycle is needed for multithreading and also works better with multinode
+ data traffic.
+- All Elements are now assumed to be array Elements, so indexing is built into
+ messaging from the ground up.
+- Field access function specification is cleaner.
+- Separation of function specification from messaging. This means that any
+ message can be used as a communication line for any function call
+ between two Elements. This gives an enormous simplification to message
+ design. However, it entails:
+- Runtime type-checking of message data, hopefully in a very efficient way.
+ As message setup is itself runtime, and arbitrary functions can sit
+ on the message channels, it turns out to be very hard to
+ do complete checking at compile or setup time.
+- Wildcard info merged into messages.
+- Three-tier message manipulation hierarchy, for better introspection and
+ relating to higher-level setup calls. These are
+ Msg: Lowest level, manages info between two Elements e1 and e2.
+ Deals with the index-level connectivity for the Element arrays.
+ Conn: Mid level. Manages a set of Msgs that together make a messaging
+ unit that takes a function call/data from source to a set of
+ destination Elements and their array entries. Has introspection
+ info. Is a MOOSE field.
+ Map: High level. Manages a set of Conns that together handle a
+ conceptual group. Equivalent to an anatomical projection from
+ one set of neurons to another in the brain. Equivalent to what
+ the 'createmap' function would generate. Has introspection.
+ Is a MOOSE Element.
+
+- Field access and function calls now go through the messaging interface. Not
+ necessarily the fastest way to do it, but simplifies life in a
+ multinode/multithreaded system, and reduces the complexity of the
+ overall interface.
+*/
diff --git a/docs/developer/doxygen-main.cpp b/docs/developer/doxygen-main.cpp
new file mode 100644
index 0000000000..7c1d36aacd
--- /dev/null
+++ b/docs/developer/doxygen-main.cpp
@@ -0,0 +1,48 @@
+/**
+\mainpage MOOSE source code documentation
+
+\section intro_sec Introduction
+
+MOOSE is the base and numerical core for large, detailed simulations
+including Computational Neuroscience and Systems Biology. MOOSE spans the
+range from single molecules to subcellular networks, from single cells to
+neuronal networks, and to still larger systems. it is backwards-compatible
+with GENESIS, and forward compatible with Python and XML-based model
+definition standards like SBML and NeuroML.
+
+MOOSE uses Python as its primary scripting language. For backward
+compatibility we have a GENESIS scripting module, but this is deprecated.
+MOOSE uses Qt/OpenGL for its graphical interface. The entire GUI is
+written in Python, and the MOOSE numerical code is written in C++.
+
+\section support_sec Hardware and availability
+MOOSE runs on everything from laptops to large clusters. It supports
+multiple-core machines through threading, and cluster architectures using
+MPI, the Message Passing Interface. MOOSE is compiled for Linux,
+MacOS, and to the extent that we can get it to compile, on Windows.
+
+MOOSE is free software.
+MOOSE makes extensive use of external libraries. The main MOOSE code itself
+is LGPL, meaning it is easy to reuse with attribution but will remain
+free. However, the common release of MOOSE uses the GNU scientific library
+(GSL) which is under the GPL. For such releases, MOOSE should be treated
+as also being under the GPL.
+
+Apart from the auto-generated documentation for the source-code itself, here are
+some higher-level hand-written documents:
+
+\ref ProgrammersGuide
+
+\ref AppProgInterface
+
+\ref DesignDocument
+
+\ref HSolveDevOverview
+
+\ref HSolveImplementation
+
+\ref Profiling
+
+\ref ParamFitting
+
+*/
diff --git a/docs/developer/doxygen-programmers-guide.cpp b/docs/developer/doxygen-programmers-guide.cpp
new file mode 100644
index 0000000000..ba756f8207
--- /dev/null
+++ b/docs/developer/doxygen-programmers-guide.cpp
@@ -0,0 +1,277 @@
+/**
+\page ProgrammersGuide Programmer's Guide
+Documentation for programmers.
+
+\section PG_ProcessLoop Process Loop
+The MOOSE main process loop coordinates script commands, multiple threads
+to execute those commands and carry out calculations, and data transfer
+between nodes.
+
+\subsection PG_Threads Threads
+MOOSE runs in multithread mode by default. MOOSE uses pthreads.
+
+1. The main thread (or the calling thread from a parser such as Python)
+is always allocated.\n
+2. MOOSE estimates the number of CPU cores and sets up that same number
+of compute threads. To override this number, the user can specify at the
+command line how many threads to use for computation.\n
+If MOOSE is running with MPI, one more thread is allocated
+for controlling MPI data transfers.
+
+MOOSE can also run in single-threaded mode. Here everything remains in the
+'main' thread or the parser thread, and no other threads are spawned.
+
+\subsection PG_ProcessLoopDetails Multithreading and the Process Loop
+The MOOSE process loop coordinates input from the main thread, such as
+parser commands, with computation and message passing. MOOSE has one
+process loop function (processEventLoop) which it calls on all compute
+threads. All these threads
+synchronize on custom-written barriers, during which a special single-
+thread function is executed.
+
+The sequence of operations for a single-node, multithread calculation is
+as follows:
+
+1. The Process calls of all the executed objects are called. This typically
+ triggers all scheduled calculations, which emit various messages. As
+ this is being done on multiple threads, all messages are dumped into
+ individual temporary queues, one for each thread.\n
+2. The first barrier is hit. Here the swapQ function consolidates all
+ the temporary queues into a single one.\n
+3. All the individual threads now work on the consolidated queue to digest
+ messages directed to the objects under that thread. Possibly further
+ messages will be emitted. As before these go into thread-specific
+ queues.\n
+4. The second barrier is hit. Now the scheduler advances the clock by one
+ tick.\n
+5. The loop cycles back.
+
+In addition to all this, the parser thread can dump calls into its special
+queue at any time. However, the parser queue operates a mutex to
+protect it during the first barrier. During the first barrier, the
+queue entries from the parser thread are also incorporated into the
+consolidated queue, and the parser queue is flushed.
+
+These steps are illustrated below:
+
+@image html MOOSE_threading.gif "MOOSE threading and Process Loop"
+
+\subsection PG_MPIProcessLoopDetails Multinode data transfer, Multithreading and the Process Loop
+MOOSE uses MPI to transfer data between nodes. The message queues are
+already in a format that can be transferred between nodes, so the main
+issue here is to coordinate the threads, the MPI, and the computation in
+a manner that is as efficient as possible.
+When carrying out MPI data transfers, things are somewhat more involved.
+Here we have to additionally coordinate data transfers between many nodes.
+This is done using an MPI loop (mpiEventLoop) which is called on
+a single additional thread. MPI needs two buffers: one for sending and
+one for receiving data. So as to keep the communications going on in
+the background, the system interleaves data transfers from each node with
+computation. The sequence of operations starts out similar to above:
+
+1. The Process calls of all the executed objects are called. This typically
+ triggers all scheduled calculations, which emit various messages. As
+ this is being done on multiple threads, all messages are dumped into
+ individual temporary queues, one for each thread. MPI thread is idle.\n
+2. The first barrier is hit. Here the swapQ function consolidates all
+ the temporary queues into a single one.\n
+3. Here, rather than digest the local consolidated queue, the system
+ initiates an internode data transfer. It takes the node0 consolidated
+ queue, and sends it to all other nodes using MPI_Bcast. On node 0,
+ the command reads the provided buffer. On all other nodes, the command
+ dumps the just-received data from node 0 to the provided buffer.
+ The compute threads are idle during this phase.\n
+4. Barrier 2 is hit. Here the system swaps buffer pointers so that
+ the just-received data is ready to be digested, and the other buffer
+ is ready to receive the next chunk of data.\n
+5. Here the compute threads digest the data from node 0, while the
+ MPI thread sends out data from node 1 to all other nodes.\n
+6. Barrier 2 comes round again, buffer pointers swap.\n
+7. Compute threads digest data from node 1, while MPI thread sends out
+ data from node 2 to all other nodes.\n
+... This cycle of swap/(digest+send) is repeated for all nodes.\n
+
+8. Compute threads digest data from the last node. MPI thread is idle.\n
+9. In the final barrier, the clock tick is advanced.\n
+10. The loop cycles back.
+
+As before, the parser thread can dump data into its own queue, and this
+is synchronized during the first barrier.
+
+These steps are illustrated below:
+
+@image html MOOSE_MPI_threading.gif "MOOSE threading and Process Loop with MPI data transfers between nodes."
+
+\subsection ksolve_threading Threading with the Kinetics GSL solver.
+
+Currently we only subdivide voxels, not parts of a single large model
+ within one voxel.\n
+
+The GslIntegrator handles Process and Reinit. This drives the data
+structures set up by the Stoich class.
+ The Compartment, which is a ChemMesh subclass,
+ is subdivided into a number of MeshEntries (voxels).
+ The GslIntegrator has to be created with as many instances as there are
+MeshEntries (voxels) in the mesh.
+ The setup function (currently manual) calls the GslIntegrator::stoich()
+function on all instances of GslIntegrator (e.g., using setRepeat).
+ The scheduling (currently manual) does:
+
+ Clock0: MeshEntry::process.
+ Clock1: GslIntegrator::process.
+
+ During Reinit, the GslIntegrator builds up a small data structure called
+StoichThread. This contains a pointer to the Stoich, to the ProcInfo, and
+the meshIndex. There is a separate StoichThread on each GslIntegrator
+instance.
+ During Process on the MeshEntry, the following sequence of calls
+ensues:
+
+ ChemMesh::updateDiffusion( meshIndex )
+ Stoich::updateDiffusion( meshIndex, stencil )
+ Iterate through stencils, calling Stencil::addFlux for meshIndex
+ In Stencil::addFlux: Add flux values to the Stoich::flux vector.
+
+
+ During Process on the GslIntegrator:
+
+ the GslIntegrators on all threads call their inner loop
+ for advancing to the next timestep through gsl_odeiv_evolve_apply.
+ The GslIntegrators on all threads call Stoich::clearFlux.
+
+ During Process on the Stoich, which is called through the GslIntegrator
+ functions, not directly from Process:
+
+ Through the GSL, Stoich::gslFunc is called on each thread. This
+ calls the innerGslFunc with the appropriate meshIndex. This does the
+ calculations for the specified voxel. These calculations include
+ the chemistry, and also add on the appropriate flux terms for each
+ molecule at this meshIndex.\n
+ The Stoich::clearFlux function zeroes out all the entries in the
+ flux_ vector at the specified meshIndex.\n
+
+
+
+\section Solvers_zombies Solvers and Zombies
+\subsection SolversOverview Overview
+\subsection WritingZombies Writing Zombies
+Zombies are superficially identical classes to regular MOOSE classes, only
+they are now controlled by some kind of numerically optimized solver. The
+role of the Zombie is to give the illusion that the original object is there
+and behaving normally (except perhaps computing much faster). All the original
+messages and fields are preserved. It is important that there be a one-to-one
+match between the original and zombie list of Finfos in the Cinfo static
+intialization.\n
+Zombies provide an interface between the original fields and the solver. They
+usually do so by maintaining a pointer to the solver, and using its access
+functions.\n
+Zombie classes typically also provide two special functions: \n
+zombify( Element* solver, Element* orig)
+and unzombify( Element* zombie). These do what you might expect from the name.
+The solver calls these operations during setup.\n
+
+There are two main kinds of zombies:
+
+ Soulless zombies: These lack any data whatsoever, and are
+ derived classes from the solver. The Zombie data is nothing
+ but a pointer to the managing solver, and is never duplicated.
+ These are managed by a ZombieHandler. During the zombify
+ routine, all the relevant data goes over to the solver,
+ and the original data and dataHandler is deleted.
+ Transformed Zombies: These carry some data of their own, as well as
+ a pointer to the managing solver. If they are converted to an
+ array, or resized they have to have their own data resized too.
+ These are managed by a regular DataHandler. During the
+ zombify routine, some parts of the data are copied over to
+ the new Zombie data structure, some go to the solver, and the
+ rest is discarded. The original data is deleted.
+
+
+\section NewClasses Writing new MOOSE classes
+\subsection NewClassesOverview Overview
+
+MOOSE is designed to make it easy to set up new simulation classes. This
+process is discussed in detail in this section. Briefly, the developer
+provides their favourite implementation of some simulation concept as
+a class. The functions and fields of this class are exposed to the MOOSE
+system through a stereotyped ClassInfo structure. With this, all of the
+MOOSE functionality becomes available to the new class.
+
+\subsection FunctionsOnObjects Functions on MOOSE objects
+
+MOOSE provides a general way for objects to call each other's functions through
+messaging, and for the script to also call these functions. To do this
+functions are exposed to the API in two layers. The top layer associates
+names with each function, using Finfos. A DestFinfo is the most straightforward
+way to do this, as it handles just a single function. ValueFinfos
+and their kin are associated with two functions: a set function and a get
+function.
+
+The second layer wraps each function in a consistent form so that the message
+queuing system can access it. This is done by the OpFunc and its
+derived classes, EpFunc, UpFunc, GetOpFunc, ProcOpFunc, and FieldOpFunc.
+The form of the wrapping in all cases is:
+
+\verbatim
+void op( const Eref& e, const Qinfo* q, const double* buf ) const
+\endverbatim
+
+The job of each of these classes is to then map the arguments in the buffer
+to the arguments used by the object function. Here are some of the key features:
+
+ OpFunc: These contain just the arguments to the function.
+ For example:
+ \verbatim
+ OpFunc1< Foo, double >( &Foo::sum );
+ ...
+ void Foo::sum( double v ) {
+ tot_ += v;
+ }
+ \endverbatim
+ These are useful when the function only operates on the internal fields
+ of the destination object.
+
+ EpFunc: These pass the Eref and the Qinfo in ahead of the other
+ function arguments. This is essential when you want to know about the
+ MOOSE context of the function. For example, if you need to send a
+ message out you need to know the originating object and thread. If you
+ want to manipulate a field on the Element (as opposed to the individual
+ object), again you need a pointer to the Eref. If your function needs
+ to know what the originating Object was, it can get this from the
+ Qinfo. For example:
+ \verbatim
+ EpFunc1< Bar, double >( &Bar::sum );
+ ...
+ void Bar::sum( const Eref& e, const Qinfo* q, double v ) {
+ tot_ += v;
+ Id src = q->src();
+ msg->send( e, q->threadNum(), tot_, src );
+ }
+ \endverbatim
+
+ UpFunc: These are used in FieldElements, where the actual data
+ and operations have to be carried out one level up, on the parent.
+ For example, Synapses may be FieldElements sitting as array entries
+ on a Receptor object. Any functions coming to the Synapse have to be
+ referred to the parent Receptor, with an index to identify which
+ entry was called. UpFuncs do this.
+ \verbatim
+ static DestFinfo addSpike( "addSpike",
+ "Handles arriving spike messages. Argument is timestamp",
+ new UpFunc1< Receptor, double >( &Receptor::addSpike )
+ );
+ // Note that the DestFinfo on the Synapse refers to a function
+ // defined on the Receptor.
+ ...
+ void Receptor::addSpike( unsigned int index, double time ) {
+ Synapse& s = synTable[index];
+ s.addEvent( time );
+ }
+ \endverbatim
+
+ ProcOpFunc:
+ GetOpFunc:
+ FieldOpFunc:
+
+
+*/
diff --git a/docs/developer/hsolve-developer-overview.cpp b/docs/developer/hsolve-developer-overview.cpp
new file mode 100644
index 0000000000..898b663e38
--- /dev/null
+++ b/docs/developer/hsolve-developer-overview.cpp
@@ -0,0 +1,208 @@
+/**
+
+\page HSolveDevOverview HSolve Overview
+
+\section Introduction
+
+This document gives an overview of the Hines' solver (HSolve) implementation
+in MOOSE. At present it talks more about the interaction between HSolve and
+the rest of MOOSE, and does not talk about HSolve's internals (that is, the
+numerical implementation). Hence, it will be useful for someone who is
+implementing a new numerical scheme in MOOSE.
+
+When a neuronal model is read into MOOSE (from a NeuroML file, for example),
+it is represented inside MOOSE by biophysical objects (of type Compartment,
+HHChannel, etc.) linked up by messages. Representing the model in terms of
+objects and messages is nice because it provides a natural interface that
+the user and the rest of the system can use.
+
+These objects have fields, using which the user can specify model
+parameters, and monitor state variables during a simulation. The objects
+also have some ODE solving code (usually Exponential Euler, or EE) which
+allows them to advance their own state. The messages allow the objects to
+talk to each other. In addition, the message connectivity depicts the
+model's structure.
+
+In absence of HSolve, these objects do the following things:
+- They are woken up once every time-step to perform their calculations.
+ (Usually a function called process()).
+- Serve parameter and state variables via fields. For example, for plotting, a
+ Compartment's Vm may be inquired once every few time-steps. Objects do this
+ by providing a get() function for each field, and also a set() function to
+ change the field values.
+- Communicate with each other via messages. For example, a Compartment object
+ will receive axial current from its neighbouring compartments, and also
+ channel current from HHChannel objects.
+- Communicate with "external" objects (e.g.: other neurons) via messages. For
+ example, sending/receiving synaptic events, receiving current injection in a
+ compartment, etc.
+
+This method of doing calculations is good because it is simple to implement,
+and also provides a fallback method. However, it is very slow for the following
+reasons:
+- The EE method itself is slow. Sometimes even for simple models with a 2-3
+ compartments and channels, a timestep of 1e-6 seconds does not give
+ accurate results. On the other hand, with HSolve, a timestep of 50e-6 is
+ usually enough even for the biggest models.
+- Objects exchange information using messages. With a model of ~100 compartments
+ and 2 channels per compartment, one can expect ~1000 messages being exchanged
+ per time-step. This can seriously slow down calculations.
+- Objects may be spread out in memory, which will lead to a lot of cache misses.
+ A single cache miss leads to a penalty of ~200-400 processor cycles.
+
+The Hines' solver, in addition to being a higher-order integration method, also
+increases speed by doing all the calculations in one place, and storing all the
+data in arrays. This eliminates messaging overheads, and improves data locality.
+
+At the same time, one will like to retain the original objects-and-messages
+representation of the model, so that the user can easily inspect and
+manipulate it. In MOOSE, this is accomplished by replacing the original
+objects with "zombie" objects, whenever a solver like the HSolve is created.
+The clients of the original objects remain unaware of this switch, and to
+them, the zombie objects look just like the originals. The zombie objects
+have the same fields as the original objects, and the message connectivity
+is also retained. The illusion is made complete by letting the zombie
+objects forward any field queries and incoming messages to the HSolve. More
+detail on zombie objects is in the "Zombies" section below.
+
+\section ConceptualOverview Conceptual Overview
+
+MOOSE allows you to keep your main numerical code very loosely coupled with
+the rest of the MOOSE system. HSolve makes good use of this, and keeps the
+numerical code as independent of MOOSE-specific concepts/classes as
+possible. The points of interaction between HSolve and the rest of MOOSE are
+neatly contained in a few classes/files.
+
+Note: At present, a single HSolve object handles calculations for a single
+neuron. Soon, HSolve will also handle calculations for arrays of identical
+neurons.
+
+Here is an overview of how things proceed chronologically in a simulation:
+
+-# The user loads in a model, from, say a NeuroML file. The model is represented
+ inside MOOSE as a bunch of objects, connected by messages. The objects are
+ of type Compartment, HHChannel, etc. The connections between these
+ objects capture the structure of the model. Each of the objects have fields
+ (e.g.: "Vm" for a Compartment, "Gk" for an HHChannel). The user can use
+ these fields to read/modify the parameters and state of the model.
+-# The objects are capable of doing their own calculations at simulation time,
+ using the Exponential Euler method. Usually, the user "schedules" all the
+ objects constituting the model. This means hooking up the objects to a clock,
+ which will invoke the objects at regular intervals to do their calculations.
+ However, since we want HSolve to the calculations instead of the original
+ objects, this scheduling step is not necessary.
+-# The user connects this single-neuron model with other, external things. For
+ example, a Table object may be connected to a Compartment object for the
+ purpose of monitoring its Vm, later during the simulation. Other examples
+ are:
+ - a Table providing time-varying current-injection to a compartment.
+ - synaptic connections between compartments belonging to different
+ neurons.
+-# The user creates an HSolve object.
+-# The user "schedules" the HSolve object so that it can do its calculations.
+-# The user sets the "dt" field of the HSolve object.
+-# The user points the HSolve object to the model. This is done by setting
+ the HSolve's "target" field to the location of model inside MOOSE.
+
+ (Note: MOOSE, arranges objects in a tree, just like directories and files
+ are arranged in a tree by filesystems. Hence, the location of a model is
+ simply the "path" to an object which contains all of the model's objects).
+
+ Setting the "target" field causes HSolve to do the following:
+ -# Traverse the model, and build internal data structures based on the
+ model's structure, parameters and state.
+ -# "Deschedule" all the original objects, so that they are not longer
+ invoked by the clock to do their calculations.
+ -# Create "zombie" objects. More on this in the "Zombies" section below.
+-# The user runs the simulation. As mentioned above, only the HSolve is invoked
+ every time-step to do its calculations. Further, the rest of the system
+ continues to interact with the individual zombified biophysical objects, not
+ knowing that HSolve is doing all the thinking in the background.
+
+Note that at present, the user is responsible for carrying out all the above
+steps. In the future, a "solver manager" will be implemented which will take
+over most of the above responsibilities from the user. The user will mainly
+need to specify the choice of solver: EE, HSolve, or any other, if present.
+
+\section Zombies
+
+When an HSolve object is created, it takes over all the above functions from
+the original objects. At the same time, each of the original objects is
+replaced by a corresponding "zombie" object. For example, a Compartment
+object is replaced with a ZombieCompartment object. The user (or the rest
+of the system) continues to interact with the zombie objects, unaware of the
+switch. The role of the zombies is to act as fully-functional stand-ins,
+while letting the HSolve do all the thinking. Hence, a Table object can
+continue requesting for Vm from the compartment it was connected to, not
+knowing that the compartment has now been replaced by a zombie. Simliarly,
+another Table object can continue feeding current inject values to a
+compartment, not knowing that they are being fed into HSolve. All of this is
+accomplished in the following way:
+
+- The original objects are disconnected from the scheduling system, so that
+ they are no longer woken up for performing their calculations. Instead, the
+ HSolve object is invoked once every time-step.
+- When a field query is made to a zombie object, it calls set/get functions on
+ the HSolve, rather than on itself.
+- Similarly, when an incoming message arrives, a function on the HSolve is
+ called to handle it.
+- During a simulation, the HSolve sends out messages on behalf of the original
+ objects, to any outside objects that are connect to objects belonging to the
+ handled neuronal model.
+
+For further details about zombies, see the \ref ProgrammersGuide.
+
+\section code C++ code: classes and files
+
+Now we look at the different C++ classes that make up HSolve, and at the
+role they play in the processes described above.
+
+At setup time, most of the information flow is in the MOOSE --> HSolve
+direction. Here, the HSolveUtils class is of particular interest.
+
+At simulation time, most of the information flow is in the HSolve --> MOOSE
+direction. Here, the HSolve class and the Zombie classes capture most of the
+interactions.
+
+The numerical implementation is contained in the 3 classes HSolveActive,
+HSolvePassive, and HinesMatrix.
+
+Further details below:
+
+-# HSolveUtils: This is a little library of convenience functions built on top
+ of more basic MOOSE API calls. This library is meant for someone
+ implementing a numerical scheme, and wishing to read in the model. A
+ typical call looks like: "For a given compartment, give me all its
+ neighbouring compartments", or, "For a given compartment, give me all the
+ HHChannels that it has".
+-# HSolve: The user and the rest of MOOSE interact with this class, and the
+ Zombie classes. HSolve does the following:
+ -# Inherits numerical code and data structures from the HSolveActive
+ class.
+ -# It provides an interface for looking up and modifying the parameters
+ and state of the model. This is implemented as a host of set/get
+ functions, written in HSolveInterface.cpp.
+ -# Elevates its own status from regular C++ class to a MOOSE class. It does
+ so by registering itself as a class with the MOOSE system. Here it also
+ tells MOOSE that it has fields called "target" and "dt" (as mentioned
+ earlier). It also specifies that it has a field called 'process', which
+ allows it to be connected to a clock from the MOOSE scheduling system.
+ All of this is done in HSolve::initCinfo().
+ -# When the "target" field is set, it sets up its internal data structures
+ using code inherited from HSolveActive. At this point, it also
+ converts all the original objects into zombies.
+ .
+-# HSolveActive: At setup time, when the "target" field of HSolve is set,
+ it triggers the HSolveActive::setup() function. This function is encoded in
+ HSolveActiveSetup.cpp. It traverses the model using the HSolveUtils API,
+ interrogates the model's structure, parameter and state, and sets up all the
+ internal data-structures accordingly. At simulation time, HSolveActive
+ does the full-fledged calculations for a neuronal model with ion channels,
+ calcium, synapses, etc.The entry point for these calculations is
+ HSolveActive::step().
+-# HSolvePassive: This class does the compartmental calculations for passive
+ neurons. Derives from HinesMatrix.
+-# HinesMatrix: This class stores the HinesMatrix.
+-# Zombie*: These are the zombie classes.
+
+*/
diff --git a/docs/developer/hsolve-implementation.cpp b/docs/developer/hsolve-implementation.cpp
new file mode 100644
index 0000000000..a6cbce1e11
--- /dev/null
+++ b/docs/developer/hsolve-implementation.cpp
@@ -0,0 +1,156 @@
+/**
+
+\page HSolveImplementation HSolve Implementation
+
+\section Introduction
+
+This page documents the internals of HSolve, i.e. the data structures and working of the HSolve class and its base classes. This document is meant to serve as a reference for anyone who wants to get a better understanding of how to interface with existing data structures of HSolve, or who wants to extend the existing code.
+
+\section GettingToHSolve Getting to HSolve
+
+Where are the entry points into HSolve? (from the python scripting perspective)
+
+
+
+
+The first entry point is, of course, when the HSolve object is created from python, with some path. This calls the HSolve constructor, but is otherwise innocuous.
+
+
+The second entry point, and the more important one as far as setup is concerned, is the HSolve::setup function which gets called as soon as the target field of the HSolve object (in python) is set. This is evident in the definition of the HSolve::setPath function. HSolve::setup is where the matrix for the corresponding compartment gets set up, by walking through the dendritic tree and collecting the various compartment elements. Following this, the fields of HSolveActive get populated, such as the HHChannels, gates, Calcium-dependent channels and synapses. Lastly, outgoing messages are redirected as required. The setup process will be elaborated upon shortly.
+
+
+The third entry point is the moose.reinit() call, which automatically calls a series of reinit functions within hsolve, starting with HSolve::reinit. The reinit call basically resets the simulation to start from the beginning (all updated values are discarded and values are reinitialized). The various calls from reinit are once again explained in detail further below.
+
+
+The last entry point, and where the actual work starts is moose.start( sim_dt ), which triggers the calling of HSolveActive::step (via HSolve::process) repeatedly. This is where the actual simulation happens.
+
+
+
+\section HSolveMembers HSolve classes and members
+
+\subsection HinesMatrixSetup Hines Matrix Setup and Data Members
+
+For setup, I'm going to take a bottom-up approach, and start with the Hines Matrix itself: how it is organized as a data structure and how it is accessed in the HSolve code. In order to do this, I'm first going to talk about the Hines method itself.
+
+- The Hines Matrix itself is an admittance matrix of the dendritic tree, after the Ek and Gk values of the various channels have been calculated at a given time step. (TODO: explain half-time step at which each operation is performed)
+
+- The Hines Matrix is a predominantly tridiagonal matrix, with off-tridiagonal elements appearing only when there are branches (or junctions) in the dendritic tree. This is ensured by the indexing mechanism:
+ - The Hines indexing mechanism starts from a leaf and performs a depth-first-search on the tree.
+ - Numbers are assigned "on the way up", after having exhausted all children of a particular node.
+ - The position of the soma is not relevant to the indexing scheme.
+
+- Each compartment in the tree contributes to the diagonal of the Hines Matrix. Neighbouring compartments will contribute to corresponding cells in the tridiagonal: for example, consider compartments 2-3-4 to be a linear segment in the tree. Then, compartment 3 will contribute to the diagonal element (3, 3), to elements (3, 2) and (2, 3) by virtue of its being connected to compartment 2, and to elements (3, 4) and (4, 3) by virtue of its connection with compartment 4.
+
+- Each branch in the tree is a Y-network. Consider:
+ \verbatim
+ 2 6
+ \ /
+ Y
+ |
+ 7 \endverbatim
+ This can equivaltently be converted into the corresponding delta:
+ \verbatim
+ 2---6
+ \ /
+ 7 \endverbatim
+ Therefore, a Y branch contributes three elements to each of the upper and lower halves of the triangle, 6 elements in total. In this example, these elements are (2,6) and (6,2); (2,7) and (7,2); (6,7) and (7,6). Note that because of the Hines indexing scheme, at least one of these elements will always be a part of the tridiagonal itself. Also, if we designate "parents" and "children" in the process of performing the DFS, then parents will always have a Hines index that is one more than its that of its greatest child.
+
+- Each multi-way branch is more than a Y-network. For a three-way branch, one can create upto six different branches in the equivalent "delta" configuration:
+ \verbatim
+ 2 4 6
+ \ | /
+ \|/
+ Y
+ |
+ 7 \endverbatim
+ Which becomes:
+ \verbatim
+ 4
+ /|\
+ / | \
+ 2--|--6
+ \ | /
+ \|/
+ 7 \endverbatim
+ In such a scenario, the resulting electrical network has 6 unknowns (or in general nC2 unknowns, where n is the total number of nodes in the group of compartments involed at the junction). On the other hand, there are only four (or in general, n) constraints: for a given set of node voltages, the node currents must be the same before and after the transformation (or vice versa). The system of equations is therefore underconstrained. However, for the purpose of effecting the transformation, any one solution is sufficient. It can be inferred from inspection upon writing out the respective equations, that the following value of Gij satisfies the constraints:
+ \verbatim Gij = Gi * Gj / Gsum \endverbatim
+ where Gsum is the sum over all Gi.
+
+- The admittances produced by each compartment due to itself and its linear neighbours is stored in the HinesMatrix::HS_ vector. HS_ is a vector of doubles, consisting of the flattened diagonal and the values against which the Hines matrix is to be inverted (i.e., the external currents). HS_ can be regarded as the flattened version of an Nx4 matrix "Hines", where N is the number of compartments in the neuron.
+ - Hines[i][0] (or HS_[ 4*i + 0 ]) contains the diagonal element, after including the effects of external currents.
+ - Hines[i][1] contains the element to the right and bottom of Hines[i][0] in the symmetric matrix: element (i,i+1) = element (i+1,i).
+ - Hines[i][2] contains the diagonal element due to passive effects alone.
+ - Hines[i][3] contains the total external current injected into this compartment.
+
+- The admittances produced at junctions are stored in the HinesMatrix::HJ_ vector. HJ_ is a flattened vector comprising of elements produced by Wyes converted to Deltas. So, in the previous example, HJ_ would store (in that order) Hines[2][6], Hines[6][2], Hines[2][7], Hines[7][2], Hines[6][7], Hines[7][6]. However, the HJ_ vector itself does not store any information regarding the location of its elements within the Hines matrix.
+
+- The information linking the junctions to HJ_ is stored separately in HinesMatrix::junction_ and HinesMatrix::operandBase_ . But in order to understand these, we first need to look at how they were made. This utilizes two further data structures: HinesMatrix::coupled_ and HinesMatrix::groupNumber_ .
+ - HinesMatrix::coupled_ is a vector of groups. A group is a vector of unsigned ints. There are as many groups as there are branch-points in the dendritic tree, and each group holds the children (in order of Hines index) followed by the parent. In other words, the group contains a vector of the Hines indices of all compartments surrounding a branch point, in order of Hines index. coupled_ is a vector of all such groups (one for each branch-point).
+ - HinesMatrix::groupNumber_ is a map of unsigned ints to unsigned ints. Given the Hines index of a compartment (which is part of a group in coupled_), it tells you the index of its corresponding group into the coupled_ vector. That is, if i is the Hines index of a compartment, then the group it belongs to is coupled_[ groupNumber_[ i ] ].
+ - HinesMatrix::junction_ is a vector of JunctionStruct. There is one element in the junction_ vector for each parent-child pair in the dendritic tree. Each element contains the Hines index of the corresponding child compartment, and a rank which denotes the number of compartments remaining in its group. "Remaining" here means the number of compartments with Hines index greater than the current compartment itself. The rank therefore tells you how many more elements of the Hines Matrix can be eliminated by this compartment.
+ - HinesMatrix::operandBase_ is a map from unsigned ints to an iterator into HJ_. Given the Hines index of a compartment in a group, it gives you the iterator into HJ_ at the point corresponding to where that compartment's eliminates start. "Compartment's eliminates" here refers to the elements that must be eliminated by this compartment. In the above example of the Y branch, operandBase_[2] would point to the element corresponding to (2,6). operandBase_[6] would point to the element in HJ_ corresponding to (6,7). 7 will not be an available index in operandBase_, because there is nothing left to eliminate.
+
+- The way to iterate through HinesMatrix::HJ_, therefore, involves doing the following:
+ - Iterate through HinesMatrix::junction_
+ - Find the Hines index of the compartment corresponding to this JunctionStruct element.
+ - Find the pointer into HJ_ using HinesMatrix::operandBase_ [ index ].
+ - Find the rank (the number of elements to be eliminated by this compartment) from the JunctionStruct.
+ - Move rank steps forward in HJ_.
+ - Repeat.
+
+- In case you want to find the group associated with a certain compartment (for knowing the Vm values of neighbouring compartments, for, instance), then find the group as \verbatim group = coupled_[ groupNumber_[ index ] ] \endverbatim
+
+There are a few more data members of the HinesMatrix class that have not yet been discussed. These are:
+- nCompt_: the number of compartments
+- dt_: the simulation time step
+- VMid_: the voltage values of the compartments (in order of Hines index) at the middle of the time step (t + dt/2).
+- operand_: A vector of iterators into HS_, HJ_ and VMid_, which enables easy access to the relevant data during forward elimination.
+- backOperand_: A vector of iterators into HJ_ and VMid_, which enables easy access to the relevant data during backward substitution.
+- stage_: A variable that represents which of updateMatrix, backwardSubstitution and forwardElimination have been completed.
+
+\subsection HSolvePassiveSetup HSolvePassive methods
+
+HSolvePassive has methods that enable it to build up the compartment network of the neuron by inspecting the messaging strucutre. A path into the compartment network has to be supplied for each neuron. The building of the tree is accomplished by the following three methods:
+- HSolvePassive::walkTree
+ This fucntion takes a valid compartment Id as input and traverses the message strucutre until a terminal compartment is found. At this point, it performs a depth-first-search with this terminal compartment as the root. Having accumulated all compartments while going down the tree in a vector (compartmentId_), the method reverses the vector so that compartments get automatically arranged in the order of their Hines indices.
+- HSolvePassive::initialize
+ Initialize pulls out the membrane parameters from each of the compartments: Vm, Cm, Em, Rm and inject. All leakage channels are iterated through, and the effective Em/Rm and Cm/dt are stored in a CompartmentStruct object for each compartment.
+- HSolvePassive::storeTree
+ This last method actually creates the tree object by going through compartmentId_ once again and storing the initVm, Cm, Em, Rm and Ra values in the tree_ data structure.
+
+Once the tree has been setup, it is given as a parameter to HinesMatrix which then creates the matrix out of it.
+
+HSolvePassive also contains methods to perform integration in a single-time step (backward Euler). This comprises the stages of Gaussian elimination:
+- HSolvePassive::updateMatrix
+ This method is used to update matrix parameters, subject to changed compartment parameters - Em/Rm, Cm/dt and inject values.
+ (Note that this function is not used. HSolveActive::udpateMatrix does everything that this function does, and a bit more)
+- HSolvePassive::forwardEliminate
+ This function mostly relies on the operand_ structure created at the HinesMatrix level and uses the operands to reduce the matrix to an upper triangular matrix.
+- HSolvePassive::backwardSubstitute
+ This function solves the matrix equation for the unknown VMid vector by performing a backward substitution process.
+
+\subsection HSolveActiveSetup HSolveActive setup and data members
+
+ HSolveActive inherits from HinesMatrix via HSolvePassive. While HinesMatrix has methods to build up the matrix and HSolvePassive has methods to solve the matrix, HSolveActive has data and methods that allow it to manipulate channels. The three key methods involved are:
+- HSolveActive::advanceChannels
+ This function recomputes the "state" values of each of the channels. The state_variable is a flattened vector of the fraction of opened gates across all channels across all compartments. To update state values, the values of rate constants are looked up from the lookup tables, depending upon what the membrane voltage and calcium concetration are at this instant.
+- HSolveActive::calculateChannelCurrents
+ This function is used to re-compute the total current entering each compartment from "state" information. The state values are raised to the required power and multipled with the respective Gbar.
+- HSolveActive::advanceCalcium
+ - This method pushes forward the caActivation values (total calcium current flowing into each pool) by adding up the contributions from each channel feeding the respective pools.
+ - It also updates the calcium conentration in each pool depending upon the calcium current so calculated.
+- HSolveActive::updateMatrix
+ - This method supersedes HSolvePassive::updateMatrix.
+ - Changes in the channel conductances only affect the diagonal values of the Hines matrix (because the channel conductances connect Vm to ground). updateMatrix computes the new values of the diagonal parameters as well as the modified values of the "B" vector - the vector against which the Hines matrix is being inverted.
+ - The values of inject are also modified, since injectVarying (obtained via a message) could have changed.
+ - Finally, external currents, from channels not handled by HSolve, are added to the "B" vector part of HS_.
+
+
+
+
+*/
diff --git a/docs/developer/parameter_fitting.cpp b/docs/developer/parameter_fitting.cpp
new file mode 100644
index 0000000000..9c59d499e1
--- /dev/null
+++ b/docs/developer/parameter_fitting.cpp
@@ -0,0 +1,120 @@
+/**
+
+\page ParamFitting Parameter fitting
+
+\section Introduction
+
+When you have experimental data on a phenomenon, and you intend to create a computational model of it, usually you need to apply parameter fitting/searching techniques. These methods help you determine those parameters of your model that you have no reference on. Parameter fitting using MOOSE models are accomplished through utilizing Optimizer [1] , a parameter fitting tool developed for neural simulations.
+
+
+\section Installation Installation
+
+Installation of Optimizer and it's dependencies can be done by running through the Optimizer documentation . If MOOSE is already installed, dependencies like inspyred, wxpython and pyelectro are needed to installed only besides Optimizer.
+
+If you encounter errors while simulating, then probably the repository of Optimizer is not updated by some changes I made. Here is the repository of a definitely working (but not necessarily the latest) version .
+
+
+\section Usage Usage
+
+The tutorial of Optimizer can guide you through how to work with the GUI, though it's usage is quite obvious.
+
+So the process of parameter fitting consists of the following steps:
+
+
+ Provide experimental data, simulation script, fitting settings to Optimizer,
+ Run parameter fitting,
+
+ Optimizer provides parameters to the simulation through params.param file located next to the simulation script,
+ Optimizer runs the simulation,
+
+ Simulation retrieves the parameters from params.param using OptimizerInterface,
+ Simulation runs with the given parameters,
+ Simulation saves the results to trace.dat, located next to the simulation script, using OptimizerInterface,
+
+ Optimizer compares the results with the experimental data, finishes if the results ~fit the experimental data, otherwise goes to 2.1 to run the simulation again with other parameters.
+
+ Optimizer shows parameter fitting results.
+
+
+Let's see an example of a cooperation between Optimizer and MOOSE. First create a python script that is going to be the simulation file, in which your MOOSE code would be that runs the simulation. Let's call it opttest.py:
+
+\verbatim
+
+from moose import optimizer_interface
+import math
+
+# constants
+time_range = 1000 # time range (let's say in ms)
+experimental_params = [2.1, 3.5, 8.1] # these should be retrieved at the
+ # end of the parameter fitting
+
+def simulation(t, params):
+ """
+ Our simple, artificial 'neural simulation'.
+ """
+ return math.exp(-params[0]*t) * params[1] + params[2] * (t/5) * 0.1
+
+def generateInput():
+ """
+ Generates the input file using the 'experimental parameters'.
+ """
+ with open('input.dat', 'w') as f:
+ for t in range(time_range):
+ f.write(str(simulation(t, experimental_params)) + '\n')
+
+#~ generateInput() # this should be uncommented at the first time
+#~ # to generate the experimental data of the simulation
+
+# generally when you put up your MOOSE simulation, everything before this
+# comment is NOT needed
+# load params
+oi = optimizer_interface.OptimizerInterface() # load parameters from params.param
+params = oi.getParams() # stores the parameters as a list of floats
+
+# simulate using simulation() function
+results = []
+for t in range(time_range):
+ results.append(simulation(t, params))
+
+# add & write traces
+oi.addTrace(results) # adds a trace as the result of the simulation
+oi.writeTraces() # writes the added traces to trace.dat so
+ # Optimizer can read and compare them to the
+ # experimental data
+
+\endverbatim
+
+Instead of having a real MOOSE simulation, there's just an artificial one (basically a function) implemented - it is faster to run, and fundamentally the same as if we had a real MOOSE simulation.
+
+At first we have some global constants and two functions to simplify the code. The main part can be found after the OptimizerInterface object is initialised. We retrieve the parameters that Optimizer has suggested, then we run the 'simulation' with these parameters. Next we add a trace of the simulation's output that is going to be compared with the experimental data. Here you can either pass an iterable object (like a simple python list or numpy.array), or a moose.Table object. At the end we write the trace to trace.dat.
+
+To use this script, first uncomment the call to generateInput() function so it can save the 'experimental data' into input.dat. This input may contain the times (not necessary) of the sampling in the first column and each trace in another following column. Run the script then comment generateInput() back - not necessary, but it would slow down the simulation. After that, open Optimizer GUI by running neuraloptimizer file inside optimizer_base_dir/optimizer/. Select input.dat as your input file, with the following parameters (and also uncheck 'Contains time'):
+
+ number of traces: 1
+ length of traces (ms): 1000
+ sampling frequency (Hz): 1000
+
+
+Then click the Load trace button and if everything goes well, you should see a plot of your input data (now a linear function). Click the arrow at the top!
+
+On the second layer select 'external' where originally Neuron is selected. It tells Optimizer that we'd like to use a simulator apart from Neuron. Then in the 'Command to external simulator' box three elements should be given separated by space:
+
+ the command to execute: python - this will run our python script (obviously) consisting the model definition and running of simulation (opttest.py)
+ the model file: /absolute_path_to_the_model_file/opttest.py
+ (some options passed to your simulation script as commandline arguments)
+ number of parameters to optimize: 3
+
+So the whole command should look somewhat like this:
+\verbatim python /absolute_path_to_the_model_file/opttest.py 3 \endverbatim
+
+On the next layer you can select the fitness function(s) of your choice. Let's select MSE, with a weight of 1.0.
+
+On the 'Select Algorithm' layer choose Simulated Annealing (it's fast enough), then choose the boundaries and the starting points of your parameters (take into consideration the experimental parameters in opttest.py). After that, you can run the parameter fitting, leaving the rest settings as default.
+
+When the parameter search is finished you can save the proper parameter values, see how the model fits the experimental data or check MSE values evolve simulation after simulation.
+
+\author Viktor Tóth
+
+[1] P. Friedrich, M. Vella, A. I. Gulyás, T. F. Freund, and S. Káli, “A flexible, interactive software tool for fitting the parameters of neuronal models,” Front. Neuroinform, vol. 8, p. 63, 2014.
+
+*/
diff --git a/docs/developer/profiling.cpp b/docs/developer/profiling.cpp
new file mode 100644
index 0000000000..4a7c9ed089
--- /dev/null
+++ b/docs/developer/profiling.cpp
@@ -0,0 +1,135 @@
+/**
+
+\page Profiling Profiling
+
+\section Introduction
+
+It is possible to do profiling without altering any C++ implementation, and without writing any C++ testbed. Using Google's gperftools combined with cython , you can do C++ profiling by writing python script running the MOOSE functions in quetion.
+
+First cython, gperftools, libc6-prof packages have to be installed. Secondly a cython wrapper should be made for three functions of gperftools. After that, moose may be recompiled with the 'profile' option. Lastly, the wrapper may be included into arbitrary python script, thus gperftools functions can be used.
+
+\section PackageInstalltion Package Installation
+
+
+Cython: \verbatim ~$ sudo apt-get install cython \endverbatim
+
+gperftools: download it from here , then install it.
+
+libc6-prof: \verbatim ~$ sudo apt-get install libc6-prof \endverbatim
+
+kcachegrind (optional, for interpreting profiler output): \verbatim ~$ sudo apt-get install kcachegrind \endverbatim
+
+
+
+\section CythonWrapper Cython gperftools wrapper
+
+The simplest way to get the wrapper done is to write a cython script wrapping the gperftools functions and a python script that compiles the wrapped functions and link them to the gperftools library.
+
+Let's call the cython script gperftools_wrapped.pyx:
+
+\verbatim
+
+cdef extern from "gperftools/profiler.h":
+ int ProfilerStart(char* fname)
+ void ProfilerStop()
+ void ProfilerFlush()
+
+def ProfStart(fname):
+ return ProfilerStart(fname)
+
+def ProfStop():
+ ProfilerStop()
+
+def ProfFlush():
+ ProfilerFlush()
+
+\endverbatim
+
+Here we define a python function for each function of gperftools that we wrap. More functions can be wrapped for more custom profiling (see ProfilerStartWithOptions()).
+
+The python compiler script may look something like this (setup.py):
+
+\verbatim
+
+from distutils.core import setup
+from Cython.Build import cythonize
+
+setup(
+ name = 'gperftools_wrapped',
+ ext_modules = cythonize("gperftools_wrapped.pyx"),
+)
+
+\endverbatim
+
+Now the setup.py may be run with the following manner, adding the -lprofiler flag:
+\verbatim ~$ python setup.py build_ext --inplace -lprofiler \endverbatim
+
+If everything went right now you should have gperftools_wrapped.c, gperftools_wrapped.so, and a build directory as result of the compilation.
+
+Put gperftools_wrapped.so nearby your python testbed and import as gperftools_wrapped, so you can profile python C extensions. But (!) first the C extensions may be compiled using the -lprofiler flag.
+
+\section MooseRecomp Moose recompilation
+
+To profile moose, it should be recompiled with altering the Makefile setting BUILD: \verbatim BUILD=profile \endverbatim
+
+Essentially you should add the -lprofiler flag. So if the flags corresponding to the "profile" BUILD option does not include -lprofiler you should add it yourself (probably that is the case).
+
+Flags to use for example: \verbatim CXXFLAGS = -pg -lprofiler -fpermissive -fno-strict-aliasing -fPIC -Wall -Wno-long-long -pedantic -DUSE_GENESIS_PARSER \endverbatim
+
+You may only add the -lprofiler flag to the Makefile which compiles the C++ code you are interested in profiling (not tested). Then recompile moose.
+
+\section ProfilingInAction Profiling in action
+
+Before profiling one should always set the PYTHONPATH to the directory from where python picks up moose functions. To get the function names in your profiling, this should be done, whether it is already set in e.g. your .bashrc script. Example:
+
+\verbatim export PYTHONPATH=/path_to_moose/python/ \endverbatim
+
+To test profiling let's use an existing demo to check the runtime of HSolve functions.
+
+From the moose directory alter the script at Demos/traub_2005/py/test_hsolve_tcr.py. First import the wrapper we just made.
+
+\verbatim from gperftools_wrapped import * \endverbatim
+
+Then edit the testHSolve function, adding the wrapper functions:
+
+\verbatim
+
+ def testHSolve(self):
+ ProfStart("hsolve.prof")
+ self.schedule(simdt, plotdt, 'hsolve')
+ self.runsim(simtime, pulsearray=pulsearray)
+ self.savedata()
+ ProfFlush()
+ ProfStop()
+
+ def testEE(self):
+ pass
+ #self.schedule(simdt, plotdt, 'ee')
+ #self.runsim(simtime, pulsearray=pulsearray)
+ #self.savedata()
+
+\endverbatim
+
+You can also comment out the testEE() function so the it will run faster.
+
+After running the python script you should have a file named hsolve.prof. As you can see the string passed to ProfStart() determines the name of the profiler's output.
+
+You can interpret the output using pprof, or if you installed kcachegrind. Note that for the 'program' parameter of pprof you should provide the _moose.so file inside /path_to_moose/python/moose/.
+
+pprof text method:
+
+\verbatim
+~$ pprof --text /path_to_moose/python/moose/_moose.so hsolve.prof > log
+~$ less log
+\endverbatim
+
+kcachegrind method:
+
+\verbatim
+~$ pprof --callgrind /path_to_moose/python/moose/_moose.so hsolve.prof > output.callgrind
+~$ kcachegrind output.callgrind
+\endverbatim
+
+\author Viktor Tóth
+
+*/
diff --git a/docs/developer/setget.txt b/docs/developer/setget.txt
new file mode 100644
index 0000000000..c4afddab9c
--- /dev/null
+++ b/docs/developer/setget.txt
@@ -0,0 +1,112 @@
+Current system:
+ - Shell::doOp
+ initAck
+ op.send
+ while isAckPending {
+ clearQ
+ }
+- set
+ SetGet::set(const Eref& dest, const string& field, A arg)
+ checkSet
+ type conversions into a temp char* buffer
+ Shell::dispatchSet
+ Puts stuff into a prepacked buffer
+ Shell::innerDispatchSet
+ requestSet.send() to the target shell.
+ ..........................................................
+ Shell::handleSet on target shell
+ Checks if prepacked buffer is single arg or vec
+ if single:
+ create AssignmentMsg and tie to target
+ lowLevelSetGet.send() data from node 0 only.
+ ..........................................................
+ AssignmentMsg::exec (on all nodes and all threads)
+ Checks direction
+ extract prepacked buffer from arg
+ Checks isDataHere and p->execThread to see if to operate
+ executes op func.
+ If thread 0, sends back ack.
+ backward direction is similar, but does not send ack.
+ ..........................................................
+
+- setVec
+ SetGet< type >::setVec( const Eref& dest, const string& field,
+ const vector< A >& arg )
+ checkSet
+ type conversions into a prepacked buffer
+ Shell::dispatchSetVec
+ Stuff is already in prepacked buffer
+ Shell::innerDispatchSet // Note that this also deals with set.
+ requestSet.send() to the target shell.
+ ..........................................................
+ Shell::handleSet on target shell
+ Checks if prepacked buffer is single arg or vec
+ if vec:
+ create AssignVecMsg and tie to target
+ lowLevelSetGet.send() data from node 0 only.
+ ..........................................................
+ AssignVecMsg::exec (on all nodes and all threads)
+ Checks direction
+ extracts prepacked buffer from char* arg
+ Finds opFunc
+ DataHandler::iterator to go through all objects
+ Checks p->execThread to see if to operate
+ executes op func.
+ If thread 0, sends back ack.
+ backward direction is a single msg and looks OK, but no ack
+ ..........................................................
+
+- get
+ Field< type >::get (derived from SetGet1< type > )
+ Shell::dispatchGet (Blocking call).
+ Find field, type checks.
+ Find appropriate GetOpFunc and pass its fid
+ innerDispatchGet(sheller, tgt, fid)
+ initAck
+ requestGet.send
+ while isAckPending
+ clearQ
+ When data comes back into Shell::getBuf_ the isAckPending
+ clears.
+ Then, from within Field< Type >::get continue with:
+ take ptr to returned getBuf
+ Convert it
+ return converted value.
+ ..........................................................
+ Shell::handleGet
+ make new AssignmentMsg and tie to target
+ lowLevelGet.send
+ ..........................................................
+ AssignmentMsg::exec (on all nodes and all threads)
+ Checks direction
+ Checks isDataHere and p->execThread to see if to operate
+ executes GetOp func.
+ If thread 0, sends back ack.
+ backward direction is similar, but does not send ack.
+ ..........................................................
+ GetOpFunc::op ( defined as a template in OpFunc.h and friends)
+ Gets data from object
+ Converts to buffer
+ fieldOp on buffer (from OpFunc.cpp)
+ Puts data into prepacked buffer
+ Finds incoming Msg
+ Synthesizes return Qinfo
+ Adds return to Q going to shell
+ ..........................................................
+ Shell::recvGet( PrepackedBuffer pb)
+ Called with the return value put into the Q by GetOpFunc
+ Sets Shell::getBuf_ size for return value
+ copy return value from PrepackedBuffer into
+ Shell::getBuf_
+ ..........................................................
+ handleAck: Adds another to the returned acks
+ Eventually all the acks are back and isAckPending clears
+ innerDispatchGet returns the getBuf
+ ..........................................................
+
+- getVec:
+ Almost identical to get, and uses most of the same functions. Only
+ difference is that the handleGet sets up AssignVecMsg instead;
+ and the returned arguments are placed by index into the return
+ vector in recvGet.
+
diff --git a/docs/developer/the-messaging-system.cpp b/docs/developer/the-messaging-system.cpp
new file mode 100644
index 0000000000..bef52d56de
--- /dev/null
+++ b/docs/developer/the-messaging-system.cpp
@@ -0,0 +1,171 @@
+/**
+ * \page messagingSystem The Messaging System
+ *
+ * \section Intro Introduction
+ *
+ * The messaging system is central to the way moose works. Any understanding
+ * of the internals of moose must start with the messaging framework.
+ *
+ * The framework essentially allows "moose objects" to "send" messages to or
+ * "receive" messages from each other. The following sections expand on the
+ * exact implementation of sending and receiving messages, both from a C++
+ * programmer's perspective as well as from a python programmer's perspective.
+ *
+ * (TODO: add more messaging system philosophy)
+ *
+ * \section mooseObjects Moose Objects
+ *
+ * A moose object is an instance of a moose class. A moose class is a C++ class
+ * that has a Cinfo object representing it. Cinfo objects are class
+ * descriptors. They describe the fields that classes want to expose in the
+ * python script in one way or another.
+ *
+ * The fields that go into python are of three main types:
+ * - Value fields: the sort that are like a simple variable that can be
+ * changed as and when desired - a "public" data element on a python class
+ * - Source fields: A source of messages. These fields can be used to send
+ * data to other moose objects
+ * - Destination fields: A destination for messages. These are fields that act
+ * as recepients of messages sent by source fields.
+ *
+ * In an ordinary C++ class, there is no distinction between different class
+ * members. In order to create the aforementioned classification of class
+ * members into various field types, there is a need to use Finfo objects: the
+ * so-called "field descriptors".
+ *
+ * Consider the example of the simple class, Example:
+ *
+ * \verbatim
+ class Example {
+
+ private:
+ int x_;
+
+ public:
+
+ int getX() { return x_; }
+ void setX( int x ) { x_ = x; }
+
+ static const Cinfo *initCinfo() {
+ static ValueFinfo< Example, int > x(
+ "x",
+ "An example field of an example class",
+ &Example::getX,
+ &Example::setX
+ );
+ static Finfo *exampleFinfos[] = { &x };
+ static Cinfo exampleCinfo(
+ "Example", // The name of the class in python
+ Neutral::initCinfo(), // TODO
+ exampleFinfos, // The array of Finfos created above
+ 1, // The number of Finfos
+ new Dinfo< Example >() // The class Example itself (FIXME ?)
+ }
+
+ }; \endverbatim
+ *
+ * Example shows you how you can create a value field. The initCinfo function
+ * here could have been called anything. It merely does the job of creating a
+ * Cinfo object for the class. This is typically the case throughout moose. The
+ * ValueFinfo object takes the class and the value's data type as template
+ * arguments, as shown. The initialization parameters are the name of the
+ * class member in python, the python docstring for the member and the
+ * addresses of the set and get functions used to access and modify the said
+ * value field.
+ *
+ * But this alone is not enough. We have not yet created a Cinfo *object*
+ * corresponding to this class. The Cinfo object can be created in any of the
+ * files in the project, but it is usually created below the respective
+ * initCinfo function's definition. In this case, the object would be
+ * instantiated in a manner such as:
+ * \verbatim
+ static const Cinfo *exampleCinfo = Example::Cinfo(); \endverbatim
+ *
+ * This creates a Cinfo object in the same file which is picked up by pymoose
+ * during compilation. Example is then made into an actual python class,
+ * accessible as moose.Example (provided that the directory under which these
+ * files are located is included in the main moose Makefile for compilation).
+ *
+ * Note the importance of the "static" storage class specifier throughout this
+ * example.
+ *
+ * Any class that has such a Cinfo object described after it is considered to
+ * have been upgraded from a C++ class into a moose class.
+ *
+ * It helps to have moose classes rather than C++ classes, because they
+ * provide a mechanism for introspection. For example, you can "ask" a moose
+ * object what its fields are. In fact, you can be even more specific and ask
+ * it to tell you only its value fields, source fields or destination fields.
+ *
+ * \section sendingAndReceiving Sending and receiving
+ *
+ * Sending and receiving messages in moose is accomplished through source and
+ * destination fields respectively. Once again, in order to designate a field
+ * as a source or destination field, it is necessary to use an Finfo object.
+ *
+ * The trials directory in the moose buildQ branch gives an excellent example
+ * of how to define simple source and destination Finfos.
+ *
+ * \verbatim
+ static SrcFinfo1< double > XOut( "XOut", "Value of random field X" );
+ static DestFinfo handleX( "handleX",
+ "Prints out X as and when it is received",
+ new OpFunc1< Receiver, double >( &Receiver::handleX )
+ ); \endverbatim
+ *
+ * The source Finfo is defined within a function that returns the address of
+ * the Finfo. This is done because the same function is called in order to use
+ * the send() method of the source Finfo that activates the sending of the
+ * message.
+ *
+ * Notice that the source Finfo is defined using the class "SrcFinfo1". The 1
+ * indicates the number of variables being sent across. It is also the number
+ * of template arguments that have to be supplied and the number of extra
+ * parameters that go into the send() call. Sender::process() calls
+ * XOut()->send( e, pthreadIndexInGroup, X_ ). The X_ here is the variable
+ * being sent across. There's only one variable being sent, which is why we
+ * use an SrcFinfo1. For another example, one can take a look at
+ * biophysics/Compartment.cpp. Here, we need to send out two variables, so we
+ * use an SrcFinfo2 class. The sending function is defined as
+ * raxialOut()->send( e, pthreadIndexInGroup, Ra_, Vm_ ) to send out Ra_ and
+ * Vm_. In such a manner, upto six variables can be sent out in a single
+ * message.
+ *
+ * The destination field is defined by a handler function which is held by the
+ * OpFunc class. The handler should be able to take as many variables as the
+ * source field sends out. So OpFunc can also take upto six template arguments.
+ * The actual handler function (be it handleX or handleRaxial) takes these many
+ * values as arguments (in the same order).
+ *
+ * More information regarding OpFunc-like classes can be found in the
+ * Programmers Guide.
+ *
+ * \section creatingConnections Creating connections
+ *
+ * So far we have taken a look at how sources and destinations are made, but
+ * not at how they are actually connected. There is as yet no information
+ * designating which destinations a source field is supposed to send messages
+ * to when their send() method is called.
+ *
+ * In order to find out more about how connections are made (and also about how
+ * pymoose can be used) read the pymoose walkthrough in the user documentation.
+ * In the trials example, we created the connection in test_trials.py with:
+ * \verbatim
+ conn = moose.connect(s, 'XOut', r, 'handleX') \endverbatim
+ * In order to accomplish this in C++, one would do something like:
+ * \verbatim
+ MsgId mid = shell->doAddMsg("Single", srcId, "XOut", destId,
+ "handleX" ); \endverbatim
+ * This requires the definition of a shell variable which handles the creation
+ * of paths in the moose system. Read the Application Programming Interface
+ * guide for more information on paths. For now, try to digest the fact that
+ * the following lines create a shell object that can be used to make objects
+ * on paths - a neutral object and a compartment object have been created as a
+ * demonstration.
+ * \verbatim
+ Shell* shell = reinterpret_cast< Shell* >( Id().eref().data() );
+ Id n = shell->doCreate( "Neutral", Id(), "n" );
+ Id c = shell->doCreate( "Compartment", n, "c" ); \endverbatim
+ * This creates a Neutral object at /n and a Compartment object at /n/c/.
+ *
+ */
diff --git a/docs/doxygen/Doxyfile b/docs/doxygen/Doxyfile
new file mode 100644
index 0000000000..7915038651
--- /dev/null
+++ b/docs/doxygen/Doxyfile
@@ -0,0 +1,2410 @@
+# Doxyfile 1.8.9.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "MOOSE - Multiscale Object Oriented Simulation Environment"
+
+# The PROJECT_NUMBER
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF =
+
+# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
+# in the documentation. The maximum height of the logo should not exceed 55
+# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
+# the logo to the output directory.
+
+PROJECT_LOGO = moose_log.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./cpp
+
+# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
+# characters to appear in the names of generated files. If set to NO, non-ASCII
+# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
+# U+3044.
+# The default value is: NO.
+
+ALLOW_UNICODE_NAMES = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = YES
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new
+# page for each member. If set to NO, the documentation of a member will be part
+# of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
+# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:
+# Fortran. In the later case the parser tries to guess whether the code is fixed
+# or free formatted code, this is the default for Fortran type files), VHDL. For
+# instance to make doxygen treat .inc files as Fortran files (default is PHP),
+# and .f files as C (default is Fortran), use: inc=Fortran f=C.
+#
+# Note: For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = NO
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = YES
+
+# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO,
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. If set to YES, local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO, only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO, these classes will be included in the various overviews. This option
+# has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO, these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO, these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES, upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES, the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
+# append additional text to a page's title, such as Class Reference. If set to
+# YES the compound reference will be hidden.
+# The default value is: NO.
+
+HIDE_COMPOUND_REFERENCE= NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each
+# grouped member an include statement to the documentation, telling the reader
+# which file to include in order to use the member.
+# The default value is: NO.
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = YES
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
+# list. This list is created by putting \todo commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = NO
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
+# list. This list is created by putting \test commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../moose-core/basecode \
+ ../../moose-core/biophysics \
+ ../../moose-core/builtins \
+ ../../moose-core/device \
+ ../../moose-core/diffusion \
+ ../../moose-core/hsolve \
+ ../../moose-core/intfire \
+ ../../moose-core/kinetics \
+ ../../moose-core/ksolve \
+ ../../moose-core/mesh \
+ ../../moose-core/mpi \
+ ../../moose-core/msg \
+ ../../moose-core/randnum \
+ ../../moose-core/pymoose \
+ ../../moose-core/scheduling \
+ ../../moose-core/shell \
+ ../../moose-core/signeur \
+ ../../moose-core/synapse \
+ ../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = YES
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/doxygen/doxy_1.4.6/Doxyfile b/docs/doxygen/doxy_1.4.6/Doxyfile
new file mode 100644
index 0000000000..73ede6e3c4
--- /dev/null
+++ b/docs/doxygen/doxy_1.4.6/Doxyfile
@@ -0,0 +1,1237 @@
+# Doxyfile 1.4.6
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+# TAG = value [value, ...]
+# For lists items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+# by quotes) that should identify the project.
+
+PROJECT_NAME = MOOSE
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number.
+# This could be handy for archiving the generated documentation or
+# if some version control system is used.
+
+PROJECT_NUMBER =
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+# base path where the generated documentation will be put.
+# If a relative path is entered, it will be relative to the location
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./Docs/developer
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# The default language is English, other supported languages are:
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish,
+# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese,
+# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
+# Swedish, and Ukrainian.
+
+OUTPUT_LANGUAGE = English
+
+# This tag can be used to specify the encoding used in the generated output.
+# The encoding is not always determined by the language that is chosen,
+# but also whether or not the output is meant for Windows or non-Windows users.
+# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
+# forces the Windows encoding (this is the default for the Windows binary),
+# whereas setting the tag to NO uses a Unix-style encoding (the default for
+# all platforms other than Windows).
+
+USE_WINDOWS_ENCODING = NO
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+# include brief member descriptions after the members that are listed in
+# the file and class documentation (similar to JavaDoc).
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+# the brief description of a member or function before the detailed description.
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# Doxygen will generate a detailed section even if there is only a brief
+# description.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+# path before files name in the file list and in the header files. If set
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+# can be used to strip a user-defined part of the path. Stripping is
+# only done if one of the specified strings matches the left-hand part of
+# the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful is your file systems
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+# will interpret the first line (until the first dot) of a JavaDoc-style
+# comment as the brief description. If set to NO, the JavaDoc
+# comments will behave just like the Qt-style comments (thus requiring an
+# explicit @brief command for a brief description.
+
+JAVADOC_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+# treat a multi-line C++ special comment block (i.e. a block of //! or ///
+# comments) as a brief description. This used to be the default behaviour.
+# The new default is to treat a multi-line C++ comment block as a detailed
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member
+# documentation.
+
+DETAILS_AT_TOP = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab.
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that acts
+# as commands in the documentation. An alias has the form "name=value".
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to
+# put the command \sideeffect (or @sideeffect) in the documentation, which
+# will result in a user-defined paragraph with heading "Side Effects:".
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+# sources only. Doxygen will then generate output that is more tailored for C.
+# For instance, some of the names that are used will be different. The list
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+# sources only. Doxygen will then generate output that is more tailored for Java.
+# For instance, namespaces will be presented as packages, qualified scopes
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
+# include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING = YES
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available.
+# Private class members and static file members will be hidden unless
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+# will be included in the documentation.
+
+EXTRACT_PRIVATE = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file
+# will be included in the documentation.
+
+EXTRACT_STATIC = NO
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+# defined locally in source files will be included in the documentation.
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+# undocumented members of documented classes, files or namespaces.
+# If set to NO (the default) these members will be included in the
+# various overviews, but no documentation section is generated.
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy.
+# If set to NO (the default) these classes will be included in the various
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+# friend (class|struct|union) declarations.
+# If set to NO (the default) these declarations will be included in the
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation
+# that is typed after a \internal command is included. If the tag is set
+# to NO (the default) then the documentation will be excluded.
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+# file names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+# will show members with their full class and namespace scopes in the
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+# is inserted in the documentation for inline members.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+# will sort the (detailed) documentation of file and class members
+# alphabetically by member name. If set to NO the members will appear in
+# declaration order.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or
+# disable (NO) the todo list. This list is created by putting \todo
+# commands in the documentation.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or
+# disable (NO) the test list. This list is created by putting \test
+# commands in the documentation.
+
+GENERATE_TESTLIST = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or
+# disable (NO) the bug list. This list is created by putting \bug
+# commands in the documentation.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+# disable (NO) the deprecated list. This list is created by putting
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+# the initial value of a variable or define consists of for it to appear in
+# the documentation. If the initializer consists of more lines than specified
+# here it will be hidden. Use a value of 0 to hide initializers completely.
+# The appearance of the initializer of individual variables and defines in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+# at the bottom of the documentation of classes and structs. If set to YES the
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES = YES
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES = NO
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from the
+# version control system). Doxygen will invoke the program by executing (via
+# popen()) the command , where is the value of
+# the FILE_VERSION_FILTER tag, and is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER =
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated by doxygen. Possible values are YES and NO. If left blank
+# NO is used.
+
+WARNINGS = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that
+# doxygen can produce. The string should contain the $file, $line, and $text
+# tags, which will be replaced by the file and line number from which the
+# warning originated and the warning text. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning
+# and error messages should be written. If left blank the output is written
+# to stderr.
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain
+# documented source files. You may enter file names like "myfile.cpp" or
+# directories like "/usr/src/myproject". Separate the files or directories
+# with spaces.
+
+INPUT = ./Docs ./basecode ./biophysics ./builtins ./device ./geom ./hsolve ./kinetics ./ksolve ./manager ./mesh ./msg ./randnum ./sbml ./scheduling ./shell ./signeur ./smol ./testReduce ./threadTests ./utility
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank the following patterns are tested:
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
+
+FILE_PATTERNS =
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories
+# should be searched for input files as well. Possible values are YES and NO.
+# If left blank NO is used.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+# directories that are symbolic links (a Unix filesystem feature) are excluded
+# from the input.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS = *.py */.svn/*
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or
+# directories that contain example code fragments that are included (see
+# the \include command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank all files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude
+# commands irrespective of the value of the RECURSIVE tag.
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or
+# directories that contain image that are included in the documentation (see
+# the \image command).
+
+IMAGE_PATH = ./Docs/images
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command , where
+# is the value of the INPUT_FILTER tag, and is the name of an
+# input file. Doxygen will then use the output that the filter program writes
+# to standard output. If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+# is applied to all files.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will be used to filter the input files when producing source
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will
+# be generated. Documented entities will be cross-referenced with these sources.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES (the default)
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES (the default)
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+# will generate a verbatim copy of the header file for each class for
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+# of all compounds will be generated. Enable this if the project
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX = NO
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all
+# classes will be put under the same header in the alphabetical index.
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+# generate HTML output.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard header.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard footer.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+# style sheet that is used by each HTML page. It can be used to
+# fine-tune the look of the HTML output. If the tag is left blank doxygen
+# will generate a default style sheet. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET =
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+# files or namespaces will be aligned in HTML using tables. If set to
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS = YES
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files
+# will be generated that can be used as input for tools like the
+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+# be used to specify the file name of the resulting .chm file. You
+# can add a path in front of the file if the result should not be
+# written to the html output directory.
+
+CHM_FILE =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+# be used to specify the location (absolute path including file name) of
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+# controls if a separate .chi index file is generated (YES) or that
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+# controls whether a binary table of contents is generated (YES) or a
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND = NO
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+# top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it.
+
+DISABLE_INDEX = NO
+
+# This tag can be used to set the number of enum values (range [1..20])
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
+# generated containing a tree-like index structure (just like the one that
+# is generated for HTML Help). For this to work a browser that supports
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+# probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW = NO
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+# used to set the initial width (in pixels) of the frame in which the tree
+# is shown.
+
+TREEVIEW_WIDTH = 250
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+# generate Latex output.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+# generate index for LaTeX. If left blank `makeindex' will be used as the
+# default command name.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+# LaTeX documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used
+# by the printer. Possible values are: a4, a4wide, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+# the generated latex document. The header should contain everything until
+# the first chapter. If it is left blank doxygen will generate a
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will
+# contain links (just like the HTML output) instead of page references
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS = NO
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+# plain latex in the generated Makefile. Set this option to YES to get a
+# higher quality PDF documentation.
+
+USE_PDFLATEX = NO
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+# command to the generated LaTeX files. This will instruct LaTeX to keep
+# running if errors occur, instead of asking the user for help.
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+# The RTF output is optimized for Word 97 and may not look very pretty with
+# other RTF readers or editors.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+# RTF documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+# will contain hyperlink fields. The RTF file will
+# contain links (just like the HTML output) instead of page references.
+# This makes the output suitable for online browsing using WORD or other
+# programs which support those fields.
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. You only have to provide
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an rtf document.
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+# generate man pages
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will
+# generate an XML file that captures the structure of
+# the code including all documentation.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+# evaluate all C-preprocessor directives found in the sources and include
+# files.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+# names in the source code. If set to NO (the default) only conditional
+# compilation will be performed. Macro expansion can be done in a controlled
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+# then the macro expansion is limited to the macros specified with the
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by
+# the preprocessor.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will
+# be used.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that
+# are defined before the preprocessor is started (similar to the -D option of
+# gcc). The argument of the tag is a list of macros of the form: name
+# or name=definition (no spaces). If the definition and the = are
+# omitted =1 is assumed. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+# this tag can be used to specify a list of macro names that should be expanded.
+# The macro definition that is found in the sources will be used.
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all function-like macros that are alone
+# on a line, have an all uppercase name, and do not end with a semicolon. Such
+# function macros are typically used for boiler-plate code, and will confuse
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed
+# in the class index. If set to NO only the inherited external classes
+# will be listed.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will
+# be listed.
+
+EXTERNAL_GROUPS = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# or super classes. Setting the tag to NO turns the diagrams off. Note that
+# this option is superseded by the HAVE_DOT option below. This is only a
+# fallback. It is recommended to install and use dot, since it yields more
+# powerful graphs.
+
+CLASS_DIAGRAMS = YES
+
+# If set to YES, the inheritance and collaboration graphs will hide
+# inheritance and usage relations if the target is undocumented
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz, a graph visualization
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT = NO
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect inheritance relations. Setting this tag to YES will force the
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect implementation dependencies (inheritance, containment, and
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK = YES
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+# tags are set to YES then doxygen will generate a graph for each documented
+# file showing the direct and indirect include dependencies of the file with
+# other documented files.
+
+INCLUDE_GRAPH = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+# documented header file showing the documented files that directly or
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
+# generate a call dependency graph for every global function or class method.
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+
+CALL_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the
+# \dotfile command).
+
+DOTFILE_DIRS =
+
+# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_WIDTH = 1024
+
+# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_HEIGHT = 1024
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that a graph may be further truncated if the graph's
+# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH
+# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default),
+# the graph is not depth-constrained.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, which results in a white background.
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS = NO
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+# generate a legend page explaining the meaning of the various boxes and
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+# remove the intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE = NO
diff --git a/docs/doxygen/doxy_1.4.6/Doxyfile.full b/docs/doxygen/doxy_1.4.6/Doxyfile.full
new file mode 100644
index 0000000000..dbb197ef37
--- /dev/null
+++ b/docs/doxygen/doxy_1.4.6/Doxyfile.full
@@ -0,0 +1,1237 @@
+# Doxyfile 1.4.6
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+# TAG = value [value, ...]
+# For lists items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+# by quotes) that should identify the project.
+
+PROJECT_NAME = MOOSE
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number.
+# This could be handy for archiving the generated documentation or
+# if some version control system is used.
+
+PROJECT_NUMBER =
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+# base path where the generated documentation will be put.
+# If a relative path is entered, it will be relative to the location
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./Docs/developer
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# The default language is English, other supported languages are:
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish,
+# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese,
+# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
+# Swedish, and Ukrainian.
+
+OUTPUT_LANGUAGE = English
+
+# This tag can be used to specify the encoding used in the generated output.
+# The encoding is not always determined by the language that is chosen,
+# but also whether or not the output is meant for Windows or non-Windows users.
+# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
+# forces the Windows encoding (this is the default for the Windows binary),
+# whereas setting the tag to NO uses a Unix-style encoding (the default for
+# all platforms other than Windows).
+
+USE_WINDOWS_ENCODING = NO
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+# include brief member descriptions after the members that are listed in
+# the file and class documentation (similar to JavaDoc).
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+# the brief description of a member or function before the detailed description.
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# Doxygen will generate a detailed section even if there is only a brief
+# description.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+# path before files name in the file list and in the header files. If set
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+# can be used to strip a user-defined part of the path. Stripping is
+# only done if one of the specified strings matches the left-hand part of
+# the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful is your file systems
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+# will interpret the first line (until the first dot) of a JavaDoc-style
+# comment as the brief description. If set to NO, the JavaDoc
+# comments will behave just like the Qt-style comments (thus requiring an
+# explicit @brief command for a brief description.
+
+JAVADOC_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+# treat a multi-line C++ special comment block (i.e. a block of //! or ///
+# comments) as a brief description. This used to be the default behaviour.
+# The new default is to treat a multi-line C++ comment block as a detailed
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member
+# documentation.
+
+DETAILS_AT_TOP = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab.
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that acts
+# as commands in the documentation. An alias has the form "name=value".
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to
+# put the command \sideeffect (or @sideeffect) in the documentation, which
+# will result in a user-defined paragraph with heading "Side Effects:".
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+# sources only. Doxygen will then generate output that is more tailored for C.
+# For instance, some of the names that are used will be different. The list
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+# sources only. Doxygen will then generate output that is more tailored for Java.
+# For instance, namespaces will be presented as packages, qualified scopes
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
+# include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING = YES
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available.
+# Private class members and static file members will be hidden unless
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+# will be included in the documentation.
+
+EXTRACT_PRIVATE = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file
+# will be included in the documentation.
+
+EXTRACT_STATIC = NO
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+# defined locally in source files will be included in the documentation.
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+# undocumented members of documented classes, files or namespaces.
+# If set to NO (the default) these members will be included in the
+# various overviews, but no documentation section is generated.
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy.
+# If set to NO (the default) these classes will be included in the various
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+# friend (class|struct|union) declarations.
+# If set to NO (the default) these declarations will be included in the
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation
+# that is typed after a \internal command is included. If the tag is set
+# to NO (the default) then the documentation will be excluded.
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+# file names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+# will show members with their full class and namespace scopes in the
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+# is inserted in the documentation for inline members.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+# will sort the (detailed) documentation of file and class members
+# alphabetically by member name. If set to NO the members will appear in
+# declaration order.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or
+# disable (NO) the todo list. This list is created by putting \todo
+# commands in the documentation.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or
+# disable (NO) the test list. This list is created by putting \test
+# commands in the documentation.
+
+GENERATE_TESTLIST = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or
+# disable (NO) the bug list. This list is created by putting \bug
+# commands in the documentation.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+# disable (NO) the deprecated list. This list is created by putting
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+# the initial value of a variable or define consists of for it to appear in
+# the documentation. If the initializer consists of more lines than specified
+# here it will be hidden. Use a value of 0 to hide initializers completely.
+# The appearance of the initializer of individual variables and defines in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+# at the bottom of the documentation of classes and structs. If set to YES the
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES = YES
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES = NO
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from the
+# version control system). Doxygen will invoke the program by executing (via
+# popen()) the command , where is the value of
+# the FILE_VERSION_FILTER tag, and is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER =
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated by doxygen. Possible values are YES and NO. If left blank
+# NO is used.
+
+WARNINGS = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that
+# doxygen can produce. The string should contain the $file, $line, and $text
+# tags, which will be replaced by the file and line number from which the
+# warning originated and the warning text. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning
+# and error messages should be written. If left blank the output is written
+# to stderr.
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain
+# documented source files. You may enter file names like "myfile.cpp" or
+# directories like "/usr/src/myproject". Separate the files or directories
+# with spaces.
+
+INPUT = ./Docs ./basecode ./biophysics ./builtins ./device ./geom ./hsolve ./kinetics ./ksolve ./manager ./mesh ./msg ./randnum ./sbml ./scheduling ./shell ./signeur ./smol ./testReduce ./threadTests ./utility
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank the following patterns are tested:
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
+
+FILE_PATTERNS =
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories
+# should be searched for input files as well. Possible values are YES and NO.
+# If left blank NO is used.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+# directories that are symbolic links (a Unix filesystem feature) are excluded
+# from the input.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS = *.py */.svn/*
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or
+# directories that contain example code fragments that are included (see
+# the \include command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank all files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude
+# commands irrespective of the value of the RECURSIVE tag.
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or
+# directories that contain image that are included in the documentation (see
+# the \image command).
+
+IMAGE_PATH = ./Docs/images
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command , where
+# is the value of the INPUT_FILTER tag, and is the name of an
+# input file. Doxygen will then use the output that the filter program writes
+# to standard output. If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+# is applied to all files.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will be used to filter the input files when producing source
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will
+# be generated. Documented entities will be cross-referenced with these sources.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES (the default)
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES (the default)
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+# will generate a verbatim copy of the header file for each class for
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+# of all compounds will be generated. Enable this if the project
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX = NO
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all
+# classes will be put under the same header in the alphabetical index.
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+# generate HTML output.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard header.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard footer.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+# style sheet that is used by each HTML page. It can be used to
+# fine-tune the look of the HTML output. If the tag is left blank doxygen
+# will generate a default style sheet. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET =
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+# files or namespaces will be aligned in HTML using tables. If set to
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS = YES
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files
+# will be generated that can be used as input for tools like the
+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+# be used to specify the file name of the resulting .chm file. You
+# can add a path in front of the file if the result should not be
+# written to the html output directory.
+
+CHM_FILE =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+# be used to specify the location (absolute path including file name) of
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+# controls if a separate .chi index file is generated (YES) or that
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+# controls whether a binary table of contents is generated (YES) or a
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND = NO
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+# top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it.
+
+DISABLE_INDEX = NO
+
+# This tag can be used to set the number of enum values (range [1..20])
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
+# generated containing a tree-like index structure (just like the one that
+# is generated for HTML Help). For this to work a browser that supports
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+# probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW = NO
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+# used to set the initial width (in pixels) of the frame in which the tree
+# is shown.
+
+TREEVIEW_WIDTH = 250
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+# generate Latex output.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+# generate index for LaTeX. If left blank `makeindex' will be used as the
+# default command name.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+# LaTeX documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used
+# by the printer. Possible values are: a4, a4wide, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+# the generated latex document. The header should contain everything until
+# the first chapter. If it is left blank doxygen will generate a
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will
+# contain links (just like the HTML output) instead of page references
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS = NO
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+# plain latex in the generated Makefile. Set this option to YES to get a
+# higher quality PDF documentation.
+
+USE_PDFLATEX = NO
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+# command to the generated LaTeX files. This will instruct LaTeX to keep
+# running if errors occur, instead of asking the user for help.
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+# The RTF output is optimized for Word 97 and may not look very pretty with
+# other RTF readers or editors.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+# RTF documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+# will contain hyperlink fields. The RTF file will
+# contain links (just like the HTML output) instead of page references.
+# This makes the output suitable for online browsing using WORD or other
+# programs which support those fields.
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. You only have to provide
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an rtf document.
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+# generate man pages
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will
+# generate an XML file that captures the structure of
+# the code including all documentation.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+# evaluate all C-preprocessor directives found in the sources and include
+# files.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+# names in the source code. If set to NO (the default) only conditional
+# compilation will be performed. Macro expansion can be done in a controlled
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+# then the macro expansion is limited to the macros specified with the
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by
+# the preprocessor.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will
+# be used.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that
+# are defined before the preprocessor is started (similar to the -D option of
+# gcc). The argument of the tag is a list of macros of the form: name
+# or name=definition (no spaces). If the definition and the = are
+# omitted =1 is assumed. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+# this tag can be used to specify a list of macro names that should be expanded.
+# The macro definition that is found in the sources will be used.
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all function-like macros that are alone
+# on a line, have an all uppercase name, and do not end with a semicolon. Such
+# function macros are typically used for boiler-plate code, and will confuse
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed
+# in the class index. If set to NO only the inherited external classes
+# will be listed.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will
+# be listed.
+
+EXTERNAL_GROUPS = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# or super classes. Setting the tag to NO turns the diagrams off. Note that
+# this option is superseded by the HAVE_DOT option below. This is only a
+# fallback. It is recommended to install and use dot, since it yields more
+# powerful graphs.
+
+CLASS_DIAGRAMS = YES
+
+# If set to YES, the inheritance and collaboration graphs will hide
+# inheritance and usage relations if the target is undocumented
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz, a graph visualization
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT = YES
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect inheritance relations. Setting this tag to YES will force the
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect implementation dependencies (inheritance, containment, and
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK = YES
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+# tags are set to YES then doxygen will generate a graph for each documented
+# file showing the direct and indirect include dependencies of the file with
+# other documented files.
+
+INCLUDE_GRAPH = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+# documented header file showing the documented files that directly or
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
+# generate a call dependency graph for every global function or class method.
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+
+CALL_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the
+# \dotfile command).
+
+DOTFILE_DIRS =
+
+# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_WIDTH = 1024
+
+# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_HEIGHT = 1024
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that a graph may be further truncated if the graph's
+# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH
+# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default),
+# the graph is not depth-constrained.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, which results in a white background.
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS = NO
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+# generate a legend page explaining the meaning of the various boxes and
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+# remove the intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE = NO
diff --git a/docs/doxygen/doxy_1.4.6/Doxyfile.intermediate b/docs/doxygen/doxy_1.4.6/Doxyfile.intermediate
new file mode 100644
index 0000000000..8b7c7d8c6c
--- /dev/null
+++ b/docs/doxygen/doxy_1.4.6/Doxyfile.intermediate
@@ -0,0 +1,1237 @@
+# Doxyfile 1.4.6
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+# TAG = value [value, ...]
+# For lists items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+# by quotes) that should identify the project.
+
+PROJECT_NAME = MOOSE
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number.
+# This could be handy for archiving the generated documentation or
+# if some version control system is used.
+
+PROJECT_NUMBER =
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+# base path where the generated documentation will be put.
+# If a relative path is entered, it will be relative to the location
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./Docs/developer
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# The default language is English, other supported languages are:
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish,
+# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese,
+# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
+# Swedish, and Ukrainian.
+
+OUTPUT_LANGUAGE = English
+
+# This tag can be used to specify the encoding used in the generated output.
+# The encoding is not always determined by the language that is chosen,
+# but also whether or not the output is meant for Windows or non-Windows users.
+# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
+# forces the Windows encoding (this is the default for the Windows binary),
+# whereas setting the tag to NO uses a Unix-style encoding (the default for
+# all platforms other than Windows).
+
+USE_WINDOWS_ENCODING = NO
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+# include brief member descriptions after the members that are listed in
+# the file and class documentation (similar to JavaDoc).
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+# the brief description of a member or function before the detailed description.
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# Doxygen will generate a detailed section even if there is only a brief
+# description.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+# path before files name in the file list and in the header files. If set
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+# can be used to strip a user-defined part of the path. Stripping is
+# only done if one of the specified strings matches the left-hand part of
+# the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful is your file systems
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+# will interpret the first line (until the first dot) of a JavaDoc-style
+# comment as the brief description. If set to NO, the JavaDoc
+# comments will behave just like the Qt-style comments (thus requiring an
+# explicit @brief command for a brief description.
+
+JAVADOC_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+# treat a multi-line C++ special comment block (i.e. a block of //! or ///
+# comments) as a brief description. This used to be the default behaviour.
+# The new default is to treat a multi-line C++ comment block as a detailed
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member
+# documentation.
+
+DETAILS_AT_TOP = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab.
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that acts
+# as commands in the documentation. An alias has the form "name=value".
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to
+# put the command \sideeffect (or @sideeffect) in the documentation, which
+# will result in a user-defined paragraph with heading "Side Effects:".
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+# sources only. Doxygen will then generate output that is more tailored for C.
+# For instance, some of the names that are used will be different. The list
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+# sources only. Doxygen will then generate output that is more tailored for Java.
+# For instance, namespaces will be presented as packages, qualified scopes
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
+# include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING = YES
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available.
+# Private class members and static file members will be hidden unless
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+# will be included in the documentation.
+
+EXTRACT_PRIVATE = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file
+# will be included in the documentation.
+
+EXTRACT_STATIC = NO
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+# defined locally in source files will be included in the documentation.
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+# undocumented members of documented classes, files or namespaces.
+# If set to NO (the default) these members will be included in the
+# various overviews, but no documentation section is generated.
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy.
+# If set to NO (the default) these classes will be included in the various
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+# friend (class|struct|union) declarations.
+# If set to NO (the default) these declarations will be included in the
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation
+# that is typed after a \internal command is included. If the tag is set
+# to NO (the default) then the documentation will be excluded.
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+# file names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+# will show members with their full class and namespace scopes in the
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+# is inserted in the documentation for inline members.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+# will sort the (detailed) documentation of file and class members
+# alphabetically by member name. If set to NO the members will appear in
+# declaration order.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or
+# disable (NO) the todo list. This list is created by putting \todo
+# commands in the documentation.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or
+# disable (NO) the test list. This list is created by putting \test
+# commands in the documentation.
+
+GENERATE_TESTLIST = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or
+# disable (NO) the bug list. This list is created by putting \bug
+# commands in the documentation.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+# disable (NO) the deprecated list. This list is created by putting
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+# the initial value of a variable or define consists of for it to appear in
+# the documentation. If the initializer consists of more lines than specified
+# here it will be hidden. Use a value of 0 to hide initializers completely.
+# The appearance of the initializer of individual variables and defines in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+# at the bottom of the documentation of classes and structs. If set to YES the
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES = YES
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES = NO
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from the
+# version control system). Doxygen will invoke the program by executing (via
+# popen()) the command , where is the value of
+# the FILE_VERSION_FILTER tag, and is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER =
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated by doxygen. Possible values are YES and NO. If left blank
+# NO is used.
+
+WARNINGS = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that
+# doxygen can produce. The string should contain the $file, $line, and $text
+# tags, which will be replaced by the file and line number from which the
+# warning originated and the warning text. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning
+# and error messages should be written. If left blank the output is written
+# to stderr.
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain
+# documented source files. You may enter file names like "myfile.cpp" or
+# directories like "/usr/src/myproject". Separate the files or directories
+# with spaces.
+
+INPUT = ./Docs ./basecode ./biophysics ./builtins ./device ./geom ./hsolve ./kinetics ./ksolve ./manager ./mesh ./msg ./randnum ./sbml ./scheduling ./shell ./signeur ./smol ./testReduce ./threadTests ./utility
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank the following patterns are tested:
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
+
+FILE_PATTERNS =
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories
+# should be searched for input files as well. Possible values are YES and NO.
+# If left blank NO is used.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+# directories that are symbolic links (a Unix filesystem feature) are excluded
+# from the input.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS = *.py */.svn/*
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or
+# directories that contain example code fragments that are included (see
+# the \include command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank all files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude
+# commands irrespective of the value of the RECURSIVE tag.
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or
+# directories that contain image that are included in the documentation (see
+# the \image command).
+
+IMAGE_PATH = ./Docs/images
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command , where
+# is the value of the INPUT_FILTER tag, and is the name of an
+# input file. Doxygen will then use the output that the filter program writes
+# to standard output. If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+# is applied to all files.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will be used to filter the input files when producing source
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will
+# be generated. Documented entities will be cross-referenced with these sources.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES (the default)
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES (the default)
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+# will generate a verbatim copy of the header file for each class for
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+# of all compounds will be generated. Enable this if the project
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX = NO
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all
+# classes will be put under the same header in the alphabetical index.
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+# generate HTML output.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard header.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard footer.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+# style sheet that is used by each HTML page. It can be used to
+# fine-tune the look of the HTML output. If the tag is left blank doxygen
+# will generate a default style sheet. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET =
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+# files or namespaces will be aligned in HTML using tables. If set to
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS = YES
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files
+# will be generated that can be used as input for tools like the
+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+# be used to specify the file name of the resulting .chm file. You
+# can add a path in front of the file if the result should not be
+# written to the html output directory.
+
+CHM_FILE =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+# be used to specify the location (absolute path including file name) of
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+# controls if a separate .chi index file is generated (YES) or that
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+# controls whether a binary table of contents is generated (YES) or a
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND = NO
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+# top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it.
+
+DISABLE_INDEX = NO
+
+# This tag can be used to set the number of enum values (range [1..20])
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
+# generated containing a tree-like index structure (just like the one that
+# is generated for HTML Help). For this to work a browser that supports
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+# probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW = NO
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+# used to set the initial width (in pixels) of the frame in which the tree
+# is shown.
+
+TREEVIEW_WIDTH = 250
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+# generate Latex output.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+# generate index for LaTeX. If left blank `makeindex' will be used as the
+# default command name.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+# LaTeX documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used
+# by the printer. Possible values are: a4, a4wide, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+# the generated latex document. The header should contain everything until
+# the first chapter. If it is left blank doxygen will generate a
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will
+# contain links (just like the HTML output) instead of page references
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS = NO
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+# plain latex in the generated Makefile. Set this option to YES to get a
+# higher quality PDF documentation.
+
+USE_PDFLATEX = NO
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+# command to the generated LaTeX files. This will instruct LaTeX to keep
+# running if errors occur, instead of asking the user for help.
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+# The RTF output is optimized for Word 97 and may not look very pretty with
+# other RTF readers or editors.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+# RTF documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+# will contain hyperlink fields. The RTF file will
+# contain links (just like the HTML output) instead of page references.
+# This makes the output suitable for online browsing using WORD or other
+# programs which support those fields.
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. You only have to provide
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an rtf document.
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+# generate man pages
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will
+# generate an XML file that captures the structure of
+# the code including all documentation.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+# evaluate all C-preprocessor directives found in the sources and include
+# files.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+# names in the source code. If set to NO (the default) only conditional
+# compilation will be performed. Macro expansion can be done in a controlled
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+# then the macro expansion is limited to the macros specified with the
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by
+# the preprocessor.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will
+# be used.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that
+# are defined before the preprocessor is started (similar to the -D option of
+# gcc). The argument of the tag is a list of macros of the form: name
+# or name=definition (no spaces). If the definition and the = are
+# omitted =1 is assumed. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+# this tag can be used to specify a list of macro names that should be expanded.
+# The macro definition that is found in the sources will be used.
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all function-like macros that are alone
+# on a line, have an all uppercase name, and do not end with a semicolon. Such
+# function macros are typically used for boiler-plate code, and will confuse
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed
+# in the class index. If set to NO only the inherited external classes
+# will be listed.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will
+# be listed.
+
+EXTERNAL_GROUPS = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# or super classes. Setting the tag to NO turns the diagrams off. Note that
+# this option is superseded by the HAVE_DOT option below. This is only a
+# fallback. It is recommended to install and use dot, since it yields more
+# powerful graphs.
+
+CLASS_DIAGRAMS = YES
+
+# If set to YES, the inheritance and collaboration graphs will hide
+# inheritance and usage relations if the target is undocumented
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz, a graph visualization
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT = YES
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect inheritance relations. Setting this tag to YES will force the
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect implementation dependencies (inheritance, containment, and
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK = YES
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+# tags are set to YES then doxygen will generate a graph for each documented
+# file showing the direct and indirect include dependencies of the file with
+# other documented files.
+
+INCLUDE_GRAPH = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+# documented header file showing the documented files that directly or
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
+# generate a call dependency graph for every global function or class method.
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+
+CALL_GRAPH = NO
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the
+# \dotfile command).
+
+DOTFILE_DIRS =
+
+# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_WIDTH = 1024
+
+# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_HEIGHT = 1024
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that a graph may be further truncated if the graph's
+# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH
+# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default),
+# the graph is not depth-constrained.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, which results in a white background.
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS = NO
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+# generate a legend page explaining the meaning of the various boxes and
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+# remove the intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE = NO
diff --git a/docs/doxygen/doxy_1.4.6/Doxyfile.minimal b/docs/doxygen/doxy_1.4.6/Doxyfile.minimal
new file mode 100644
index 0000000000..73ede6e3c4
--- /dev/null
+++ b/docs/doxygen/doxy_1.4.6/Doxyfile.minimal
@@ -0,0 +1,1237 @@
+# Doxyfile 1.4.6
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+# TAG = value [value, ...]
+# For lists items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+# by quotes) that should identify the project.
+
+PROJECT_NAME = MOOSE
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number.
+# This could be handy for archiving the generated documentation or
+# if some version control system is used.
+
+PROJECT_NUMBER =
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+# base path where the generated documentation will be put.
+# If a relative path is entered, it will be relative to the location
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./Docs/developer
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# The default language is English, other supported languages are:
+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish,
+# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese,
+# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish,
+# Swedish, and Ukrainian.
+
+OUTPUT_LANGUAGE = English
+
+# This tag can be used to specify the encoding used in the generated output.
+# The encoding is not always determined by the language that is chosen,
+# but also whether or not the output is meant for Windows or non-Windows users.
+# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES
+# forces the Windows encoding (this is the default for the Windows binary),
+# whereas setting the tag to NO uses a Unix-style encoding (the default for
+# all platforms other than Windows).
+
+USE_WINDOWS_ENCODING = NO
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+# include brief member descriptions after the members that are listed in
+# the file and class documentation (similar to JavaDoc).
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+# the brief description of a member or function before the detailed description.
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# Doxygen will generate a detailed section even if there is only a brief
+# description.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+# path before files name in the file list and in the header files. If set
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+# can be used to strip a user-defined part of the path. Stripping is
+# only done if one of the specified strings matches the left-hand part of
+# the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful is your file systems
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+# will interpret the first line (until the first dot) of a JavaDoc-style
+# comment as the brief description. If set to NO, the JavaDoc
+# comments will behave just like the Qt-style comments (thus requiring an
+# explicit @brief command for a brief description.
+
+JAVADOC_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+# treat a multi-line C++ special comment block (i.e. a block of //! or ///
+# comments) as a brief description. This used to be the default behaviour.
+# The new default is to treat a multi-line C++ comment block as a detailed
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the DETAILS_AT_TOP tag is set to YES then Doxygen
+# will output the detailed description near the top, like JavaDoc.
+# If set to NO, the detailed description appears after the member
+# documentation.
+
+DETAILS_AT_TOP = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab.
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that acts
+# as commands in the documentation. An alias has the form "name=value".
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to
+# put the command \sideeffect (or @sideeffect) in the documentation, which
+# will result in a user-defined paragraph with heading "Side Effects:".
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+# sources only. Doxygen will then generate output that is more tailored for C.
+# For instance, some of the names that are used will be different. The list
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+# sources only. Doxygen will then generate output that is more tailored for Java.
+# For instance, namespaces will be presented as packages, qualified scopes
+# will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to
+# include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING = YES
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available.
+# Private class members and static file members will be hidden unless
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+# will be included in the documentation.
+
+EXTRACT_PRIVATE = NO
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file
+# will be included in the documentation.
+
+EXTRACT_STATIC = NO
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+# defined locally in source files will be included in the documentation.
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+# undocumented members of documented classes, files or namespaces.
+# If set to NO (the default) these members will be included in the
+# various overviews, but no documentation section is generated.
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy.
+# If set to NO (the default) these classes will be included in the various
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+# friend (class|struct|union) declarations.
+# If set to NO (the default) these declarations will be included in the
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation
+# that is typed after a \internal command is included. If the tag is set
+# to NO (the default) then the documentation will be excluded.
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+# file names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+# will show members with their full class and namespace scopes in the
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+# is inserted in the documentation for inline members.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+# will sort the (detailed) documentation of file and class members
+# alphabetically by member name. If set to NO the members will appear in
+# declaration order.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or
+# disable (NO) the todo list. This list is created by putting \todo
+# commands in the documentation.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or
+# disable (NO) the test list. This list is created by putting \test
+# commands in the documentation.
+
+GENERATE_TESTLIST = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or
+# disable (NO) the bug list. This list is created by putting \bug
+# commands in the documentation.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+# disable (NO) the deprecated list. This list is created by putting
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+# the initial value of a variable or define consists of for it to appear in
+# the documentation. If the initializer consists of more lines than specified
+# here it will be hidden. Use a value of 0 to hide initializers completely.
+# The appearance of the initializer of individual variables and defines in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+# at the bottom of the documentation of classes and structs. If set to YES the
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES = YES
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES = NO
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from the
+# version control system). Doxygen will invoke the program by executing (via
+# popen()) the command , where is the value of
+# the FILE_VERSION_FILTER tag, and is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER =
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated by doxygen. Possible values are YES and NO. If left blank
+# NO is used.
+
+WARNINGS = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that
+# doxygen can produce. The string should contain the $file, $line, and $text
+# tags, which will be replaced by the file and line number from which the
+# warning originated and the warning text. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning
+# and error messages should be written. If left blank the output is written
+# to stderr.
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain
+# documented source files. You may enter file names like "myfile.cpp" or
+# directories like "/usr/src/myproject". Separate the files or directories
+# with spaces.
+
+INPUT = ./Docs ./basecode ./biophysics ./builtins ./device ./geom ./hsolve ./kinetics ./ksolve ./manager ./mesh ./msg ./randnum ./sbml ./scheduling ./shell ./signeur ./smol ./testReduce ./threadTests ./utility
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank the following patterns are tested:
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py
+
+FILE_PATTERNS =
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories
+# should be searched for input files as well. Possible values are YES and NO.
+# If left blank NO is used.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+# directories that are symbolic links (a Unix filesystem feature) are excluded
+# from the input.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS = *.py */.svn/*
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or
+# directories that contain example code fragments that are included (see
+# the \include command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank all files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude
+# commands irrespective of the value of the RECURSIVE tag.
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or
+# directories that contain image that are included in the documentation (see
+# the \image command).
+
+IMAGE_PATH = ./Docs/images
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command , where
+# is the value of the INPUT_FILTER tag, and is the name of an
+# input file. Doxygen will then use the output that the filter program writes
+# to standard output. If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+# is applied to all files.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will be used to filter the input files when producing source
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will
+# be generated. Documented entities will be cross-referenced with these sources.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER = NO
+
+# Setting the INLINE_SOURCES tag to YES will include the body
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES (the default)
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES (the default)
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+# will generate a verbatim copy of the header file for each class for
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+# of all compounds will be generated. Enable this if the project
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX = NO
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all
+# classes will be put under the same header in the alphabetical index.
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+# generate HTML output.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard header.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard footer.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+# style sheet that is used by each HTML page. It can be used to
+# fine-tune the look of the HTML output. If the tag is left blank doxygen
+# will generate a default style sheet. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET =
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+# files or namespaces will be aligned in HTML using tables. If set to
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS = YES
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files
+# will be generated that can be used as input for tools like the
+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm)
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+# be used to specify the file name of the resulting .chm file. You
+# can add a path in front of the file if the result should not be
+# written to the html output directory.
+
+CHM_FILE =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+# be used to specify the location (absolute path including file name) of
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+# controls if a separate .chi index file is generated (YES) or that
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+# controls whether a binary table of contents is generated (YES) or a
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND = NO
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+# top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it.
+
+DISABLE_INDEX = NO
+
+# This tag can be used to set the number of enum values (range [1..20])
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be
+# generated containing a tree-like index structure (just like the one that
+# is generated for HTML Help). For this to work a browser that supports
+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+# probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW = NO
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+# used to set the initial width (in pixels) of the frame in which the tree
+# is shown.
+
+TREEVIEW_WIDTH = 250
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+# generate Latex output.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked. If left blank `latex' will be used as the default command name.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+# generate index for LaTeX. If left blank `makeindex' will be used as the
+# default command name.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+# LaTeX documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used
+# by the printer. Possible values are: a4, a4wide, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+# the generated latex document. The header should contain everything until
+# the first chapter. If it is left blank doxygen will generate a
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will
+# contain links (just like the HTML output) instead of page references
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS = NO
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+# plain latex in the generated Makefile. Set this option to YES to get a
+# higher quality PDF documentation.
+
+USE_PDFLATEX = NO
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+# command to the generated LaTeX files. This will instruct LaTeX to keep
+# running if errors occur, instead of asking the user for help.
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+# The RTF output is optimized for Word 97 and may not look very pretty with
+# other RTF readers or editors.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+# RTF documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+# will contain hyperlink fields. The RTF file will
+# contain links (just like the HTML output) instead of page references.
+# This makes the output suitable for online browsing using WORD or other
+# programs which support those fields.
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. You only have to provide
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an rtf document.
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+# generate man pages
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will
+# generate an XML file that captures the structure of
+# the code including all documentation.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+# evaluate all C-preprocessor directives found in the sources and include
+# files.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+# names in the source code. If set to NO (the default) only conditional
+# compilation will be performed. Macro expansion can be done in a controlled
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+# then the macro expansion is limited to the macros specified with the
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by
+# the preprocessor.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will
+# be used.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that
+# are defined before the preprocessor is started (similar to the -D option of
+# gcc). The argument of the tag is a list of macros of the form: name
+# or name=definition (no spaces). If the definition and the = are
+# omitted =1 is assumed. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+# this tag can be used to specify a list of macro names that should be expanded.
+# The macro definition that is found in the sources will be used.
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all function-like macros that are alone
+# on a line, have an all uppercase name, and do not end with a semicolon. Such
+# function macros are typically used for boiler-plate code, and will confuse
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed
+# in the class index. If set to NO only the inherited external classes
+# will be listed.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will
+# be listed.
+
+EXTERNAL_GROUPS = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# or super classes. Setting the tag to NO turns the diagrams off. Note that
+# this option is superseded by the HAVE_DOT option below. This is only a
+# fallback. It is recommended to install and use dot, since it yields more
+# powerful graphs.
+
+CLASS_DIAGRAMS = YES
+
+# If set to YES, the inheritance and collaboration graphs will hide
+# inheritance and usage relations if the target is undocumented
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz, a graph visualization
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT = NO
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect inheritance relations. Setting this tag to YES will force the
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect implementation dependencies (inheritance, containment, and
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK = YES
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+# tags are set to YES then doxygen will generate a graph for each documented
+# file showing the direct and indirect include dependencies of the file with
+# other documented files.
+
+INCLUDE_GRAPH = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+# documented header file showing the documented files that directly or
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will
+# generate a call dependency graph for every global function or class method.
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+
+CALL_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the
+# \dotfile command).
+
+DOTFILE_DIRS =
+
+# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_WIDTH = 1024
+
+# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height
+# (in pixels) of the graphs generated by dot. If a graph becomes larger than
+# this value, doxygen will try to truncate the graph, so that it fits within
+# the specified constraint. Beware that most browsers cannot cope with very
+# large images.
+
+MAX_DOT_GRAPH_HEIGHT = 1024
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that a graph may be further truncated if the graph's
+# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH
+# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default),
+# the graph is not depth-constrained.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, which results in a white background.
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS = NO
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+# generate a legend page explaining the meaning of the various boxes and
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+# remove the intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine
+#---------------------------------------------------------------------------
+
+# The SEARCHENGINE tag specifies whether or not a search engine should be
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE = NO
diff --git a/docs/doxygen/doxy_1.4.6/docgen b/docs/doxygen/doxy_1.4.6/docgen
new file mode 100755
index 0000000000..b6ad06d623
--- /dev/null
+++ b/docs/doxygen/doxy_1.4.6/docgen
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+echo "###############################################################"
+echo "# Generating C++ Documentation #"
+echo "###############################################################"
+doxygen ./Doxyfile.full
+
+echo "##############################################################"
+echo "# Generating Python Documentation #"
+echo "##############################################################"
+
+( cd Docs/user/py && make html || true )
+
diff --git a/docs/doxygen/doxy_1.8.9/Doxyfile b/docs/doxygen/doxy_1.8.9/Doxyfile
new file mode 100644
index 0000000000..37ab18ffe8
--- /dev/null
+++ b/docs/doxygen/doxy_1.8.9/Doxyfile
@@ -0,0 +1,2410 @@
+# Doxyfile 1.8.9.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "MOOSE - Multiscale Object Oriented Simulation Environment"
+
+# The PROJECT_NUMBER
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF =
+
+# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
+# in the documentation. The maximum height of the logo should not exceed 55
+# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
+# the logo to the output directory.
+
+PROJECT_LOGO = moose_log.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./cpp
+
+# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
+# characters to appear in the names of generated files. If set to NO, non-ASCII
+# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
+# U+3044.
+# The default value is: NO.
+
+ALLOW_UNICODE_NAMES = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = YES
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new
+# page for each member. If set to NO, the documentation of a member will be part
+# of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
+# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:
+# Fortran. In the later case the parser tries to guess whether the code is fixed
+# or free formatted code, this is the default for Fortran type files), VHDL. For
+# instance to make doxygen treat .inc files as Fortran files (default is PHP),
+# and .f files as C (default is Fortran), use: inc=Fortran f=C.
+#
+# Note: For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = YES
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = YES
+
+# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO,
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. If set to YES, local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO, only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO, these classes will be included in the various overviews. This option
+# has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO, these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO, these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES, upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES, the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
+# append additional text to a page's title, such as Class Reference. If set to
+# YES the compound reference will be hidden.
+# The default value is: NO.
+
+HIDE_COMPOUND_REFERENCE= NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each
+# grouped member an include statement to the documentation, telling the reader
+# which file to include in order to use the member.
+# The default value is: NO.
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = YES
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
+# list. This list is created by putting \todo commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = NO
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
+# list. This list is created by putting \test commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../moose-core/basecode \
+ ../../moose-core/biophysics \
+ ../../moose-core/builtins \
+ ../../moose-core/device \
+ ../../moose-core/diffusion \
+ ../../moose-core/hsolve \
+ ../../moose-core/intfire \
+ ../../moose-core/kinetics \
+ ../../moose-core/ksolve \
+ ../../moose-core/mesh \
+ ../../moose-core/mpi \
+ ../../moose-core/msg \
+ ../../moose-core/randnum \
+ ../../moose-core/pymoose \
+ ../../moose-core/scheduling \
+ ../../moose-core/shell \
+ ../../moose-core/signeur \
+ ../../moose-core/synapse \
+ ../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = NO
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/doxygen/doxy_1.8.9/Doxyfile.full b/docs/doxygen/doxy_1.8.9/Doxyfile.full
new file mode 100644
index 0000000000..ab7cf523de
--- /dev/null
+++ b/docs/doxygen/doxy_1.8.9/Doxyfile.full
@@ -0,0 +1,2410 @@
+# Doxyfile 1.8.9.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "MOOSE - Multiscale Object Oriented Simulation Environment"
+
+# The PROJECT_NUMBER
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF =
+
+# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
+# in the documentation. The maximum height of the logo should not exceed 55
+# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
+# the logo to the output directory.
+
+PROJECT_LOGO = moose_log.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./cpp
+
+# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
+# characters to appear in the names of generated files. If set to NO, non-ASCII
+# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
+# U+3044.
+# The default value is: NO.
+
+ALLOW_UNICODE_NAMES = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = YES
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new
+# page for each member. If set to NO, the documentation of a member will be part
+# of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
+# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:
+# Fortran. In the later case the parser tries to guess whether the code is fixed
+# or free formatted code, this is the default for Fortran type files), VHDL. For
+# instance to make doxygen treat .inc files as Fortran files (default is PHP),
+# and .f files as C (default is Fortran), use: inc=Fortran f=C.
+#
+# Note: For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = YES
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = YES
+
+# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO,
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. If set to YES, local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO, only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO, these classes will be included in the various overviews. This option
+# has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO, these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO, these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES, upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES, the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
+# append additional text to a page's title, such as Class Reference. If set to
+# YES the compound reference will be hidden.
+# The default value is: NO.
+
+HIDE_COMPOUND_REFERENCE= NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each
+# grouped member an include statement to the documentation, telling the reader
+# which file to include in order to use the member.
+# The default value is: NO.
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = YES
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
+# list. This list is created by putting \todo commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = NO
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
+# list. This list is created by putting \test commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../moose-core/basecode \
+ ../../moose-core/biophysics \
+ ../../moose-core/builtins \
+ ../../moose-core/device \
+ ../../moose-core/diffusion \
+ ../../moose-core/hsolve \
+ ../../moose-core/intfire \
+ ../../moose-core/kinetics \
+ ../../moose-core/ksolve \
+ ../../moose-core/mesh \
+ ../../moose-core/mpi \
+ ../../moose-core/msg \
+ ../../moose-core/randnum \
+ ../../moose-core/pymoose \
+ ../../moose-core/scheduling \
+ ../../moose-core/shell \
+ ../../moose-core/signeur \
+ ../../moose-core/synapse \
+ ../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = YES
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/doxygen/doxy_1.8.9/Doxyfile.intermediate b/docs/doxygen/doxy_1.8.9/Doxyfile.intermediate
new file mode 100644
index 0000000000..5e2634d0c4
--- /dev/null
+++ b/docs/doxygen/doxy_1.8.9/Doxyfile.intermediate
@@ -0,0 +1,2410 @@
+# Doxyfile 1.8.9.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "MOOSE - Multiscale Object Oriented Simulation Environment"
+
+# The PROJECT_NUMBER
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF =
+
+# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
+# in the documentation. The maximum height of the logo should not exceed 55
+# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
+# the logo to the output directory.
+
+PROJECT_LOGO = moose_log.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./cpp
+
+# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
+# characters to appear in the names of generated files. If set to NO, non-ASCII
+# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
+# U+3044.
+# The default value is: NO.
+
+ALLOW_UNICODE_NAMES = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = YES
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new
+# page for each member. If set to NO, the documentation of a member will be part
+# of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
+# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:
+# Fortran. In the later case the parser tries to guess whether the code is fixed
+# or free formatted code, this is the default for Fortran type files), VHDL. For
+# instance to make doxygen treat .inc files as Fortran files (default is PHP),
+# and .f files as C (default is Fortran), use: inc=Fortran f=C.
+#
+# Note: For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = YES
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = YES
+
+# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO,
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. If set to YES, local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO, only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO, these classes will be included in the various overviews. This option
+# has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO, these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO, these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES, upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES, the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
+# append additional text to a page's title, such as Class Reference. If set to
+# YES the compound reference will be hidden.
+# The default value is: NO.
+
+HIDE_COMPOUND_REFERENCE= NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each
+# grouped member an include statement to the documentation, telling the reader
+# which file to include in order to use the member.
+# The default value is: NO.
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = YES
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
+# list. This list is created by putting \todo commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = NO
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
+# list. This list is created by putting \test commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../moose-core/basecode \
+ ../../moose-core/biophysics \
+ ../../moose-core/builtins \
+ ../../moose-core/device \
+ ../../moose-core/diffusion \
+ ../../moose-core/hsolve \
+ ../../moose-core/intfire \
+ ../../moose-core/kinetics \
+ ../../moose-core/ksolve \
+ ../../moose-core/mesh \
+ ../../moose-core/mpi \
+ ../../moose-core/msg \
+ ../../moose-core/randnum \
+ ../../moose-core/pymoose \
+ ../../moose-core/scheduling \
+ ../../moose-core/shell \
+ ../../moose-core/signeur \
+ ../../moose-core/synapse \
+ ../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = YES
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = NO
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/doxygen/doxy_1.8.9/Doxyfile.minimal b/docs/doxygen/doxy_1.8.9/Doxyfile.minimal
new file mode 100644
index 0000000000..37ab18ffe8
--- /dev/null
+++ b/docs/doxygen/doxy_1.8.9/Doxyfile.minimal
@@ -0,0 +1,2410 @@
+# Doxyfile 1.8.9.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project.
+#
+# All text after a double hash (##) is considered a comment and is placed in
+# front of the TAG it is preceding.
+#
+# All text after a single hash (#) is considered a comment and will be ignored.
+# The format is:
+# TAG = value [value, ...]
+# For lists, items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (\" \").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all text
+# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv
+# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv
+# for the list of possible encodings.
+# The default value is: UTF-8.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
+# double-quotes, unless you are using Doxywizard) that should identify the
+# project for which the documentation is generated. This name is used in the
+# title of most generated pages and in a few other places.
+# The default value is: My Project.
+
+PROJECT_NAME = "MOOSE - Multiscale Object Oriented Simulation Environment"
+
+# The PROJECT_NUMBER
+# could be handy for archiving the generated documentation or if some version
+# control system is used.
+
+PROJECT_NUMBER =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer a
+# quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF =
+
+# With the PROJECT_LOGO tag one can specify a logo or an icon that is included
+# in the documentation. The maximum height of the logo should not exceed 55
+# pixels and the maximum width should not exceed 200 pixels. Doxygen will copy
+# the logo to the output directory.
+
+PROJECT_LOGO = moose_log.png
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
+# into which the generated documentation will be written. If a relative path is
+# entered, it will be relative to the location where doxygen was started. If
+# left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = ./cpp
+
+# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
+# directories (in 2 levels) under the output directory of each output format and
+# will distribute the generated files over these directories. Enabling this
+# option can be useful when feeding doxygen a huge amount of source files, where
+# putting all generated files in the same directory would otherwise causes
+# performance problems for the file system.
+# The default value is: NO.
+
+CREATE_SUBDIRS = NO
+
+# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
+# characters to appear in the names of generated files. If set to NO, non-ASCII
+# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
+# U+3044.
+# The default value is: NO.
+
+ALLOW_UNICODE_NAMES = YES
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
+# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
+# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
+# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
+# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
+# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
+# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
+# Ukrainian and Vietnamese.
+# The default value is: English.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
+# descriptions after the members that are listed in the file and class
+# documentation (similar to Javadoc). Set to NO to disable this.
+# The default value is: YES.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief
+# description of a member or function before the detailed description
+#
+# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+# The default value is: YES.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator that is
+# used to form the text in various listings. Each string in this list, if found
+# as the leading text of the brief description, will be stripped from the text
+# and the result, after processing the whole list, is used as the annotated
+# text. Otherwise, the brief description is used as-is. If left blank, the
+# following values are used ($name is automatically replaced with the name of
+# the entity):The $name class, The $name widget, The $name file, is, provides,
+# specifies, contains, represents, a, an and the.
+
+ABBREVIATE_BRIEF =
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# doxygen will generate a detailed section even if there is only a brief
+# description.
+# The default value is: NO.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+# The default value is: NO.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
+# before files name in the file list and in the header files. If set to NO the
+# shortest path that makes the file name unique will be used
+# The default value is: YES.
+
+FULL_PATH_NAMES = YES
+
+# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
+# Stripping is only done if one of the specified strings matches the left-hand
+# part of the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the path to
+# strip.
+#
+# Note that you can specify absolute paths here, but also relative paths, which
+# will be relative from the directory where doxygen is started.
+# This tag requires that the tag FULL_PATH_NAMES is set to YES.
+
+STRIP_FROM_PATH =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+# path mentioned in the documentation of a class, which tells the reader which
+# header file to include in order to use a class. If left blank only the name of
+# the header file containing the class definition is used. Otherwise one should
+# specify the list of include paths that are normally passed to the compiler
+# using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but
+# less readable) file names. This can be useful is your file systems doesn't
+# support long names like on DOS, Mac, or CD-ROM.
+# The default value is: NO.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the
+# first line (until the first dot) of a Javadoc-style comment as the brief
+# description. If set to NO, the Javadoc-style will behave just like regular Qt-
+# style comments (thus requiring an explicit @brief command for a brief
+# description.)
+# The default value is: NO.
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
+# line (until the first dot) of a Qt-style comment as the brief description. If
+# set to NO, the Qt-style will behave just like regular Qt-style comments (thus
+# requiring an explicit \brief command for a brief description.)
+# The default value is: NO.
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a
+# multi-line C++ special comment block (i.e. a block of //! or /// comments) as
+# a brief description. This used to be the default behavior. The new default is
+# to treat a multi-line C++ comment block as a detailed description. Set this
+# tag to YES if you prefer the old behavior instead.
+#
+# Note that setting this tag to YES also means that rational rose comments are
+# not recognized any more.
+# The default value is: NO.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
+# documentation from any documented member that it re-implements.
+# The default value is: YES.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new
+# page for each member. If set to NO, the documentation of a member will be part
+# of the file/class/namespace that contains it.
+# The default value is: NO.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen
+# uses this value to replace tabs by spaces in code fragments.
+# Minimum value: 1, maximum value: 16, default value: 4.
+
+TAB_SIZE = 4
+
+# This tag can be used to specify a number of aliases that act as commands in
+# the documentation. An alias has the form:
+# name=value
+# For example adding
+# "sideeffect=@par Side Effects:\n"
+# will allow you to put the command \sideeffect (or @sideeffect) in the
+# documentation, which will result in a user-defined paragraph with heading
+# "Side Effects:". You can put \n's in the value part of an alias to insert
+# newlines.
+
+ALIASES =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding "class=itcl::class"
+# will allow you to use the command class in the itcl::class meaning.
+
+TCL_SUBST =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
+# only. Doxygen will then generate output that is more tailored for C. For
+# instance, some of the names that are used will be different. The list of all
+# members will be omitted, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
+# Python sources only. Doxygen will then generate output that is more tailored
+# for that language. For instance, namespaces will be presented as packages,
+# qualified scopes will look different, etc.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources. Doxygen will then generate output that is tailored for Fortran.
+# The default value is: NO.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for VHDL.
+# The default value is: NO.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given
+# extension. Doxygen has a built-in mapping, but you can override or extend it
+# using this tag. The format is ext=language, where ext is a file extension, and
+# language is one of the parsers supported by doxygen: IDL, Java, Javascript,
+# C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran:
+# FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran:
+# Fortran. In the later case the parser tries to guess whether the code is fixed
+# or free formatted code, this is the default for Fortran type files), VHDL. For
+# instance to make doxygen treat .inc files as Fortran files (default is PHP),
+# and .f files as C (default is Fortran), use: inc=Fortran f=C.
+#
+# Note: For files without extension you can use no_extension as a placeholder.
+#
+# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
+# the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See http://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+# The default value is: YES.
+
+MARKDOWN_SUPPORT = YES
+
+# When enabled doxygen tries to link words that correspond to documented
+# classes, or namespaces to their corresponding documentation. Such a link can
+# be prevented in individual cases by putting a % sign in front of the word or
+# globally by setting AUTOLINK_SUPPORT to NO.
+# The default value is: YES.
+
+AUTOLINK_SUPPORT = YES
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should set this
+# tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string);
+# versus func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+# The default value is: NO.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+# The default value is: NO.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip (see:
+# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen
+# will parse them like normal C++ but will assume all classes use public instead
+# of private inheritance when no explicit protection keyword is present.
+# The default value is: NO.
+
+SIP_SUPPORT = YES
+
+# For Microsoft's IDL there are propget and propput attributes to indicate
+# getter and setter methods for a property. Setting this option to YES will make
+# doxygen to replace the get and set methods by a property in the documentation.
+# This will only work if the methods are indeed getting or setting a simple
+# type. If this is not the case, or you want to show the methods anyway, you
+# should set this option to NO.
+# The default value is: YES.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+# The default value is: NO.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES to allow class member groups of the same type
+# (for instance a group of public functions) to be put as a subgroup of that
+# type (e.g. under the Public Functions section). Set it to NO to prevent
+# subgrouping. Alternatively, this can be done per class using the
+# \nosubgrouping command.
+# The default value is: YES.
+
+SUBGROUPING = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
+# are shown inside the group in which they are included (e.g. using \ingroup)
+# instead of on a separate page (for HTML and Man pages) or section (for LaTeX
+# and RTF).
+#
+# Note that this feature does not work in combination with
+# SEPARATE_MEMBER_PAGES.
+# The default value is: NO.
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
+# with only public data fields or simple typedef fields will be shown inline in
+# the documentation of the scope in which they are defined (i.e. file,
+# namespace, or group documentation), provided this scope is documented. If set
+# to NO, structs, classes, and unions are shown on a separate page (for HTML and
+# Man pages) or section (for LaTeX and RTF).
+# The default value is: NO.
+
+INLINE_SIMPLE_STRUCTS = NO
+
+# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or
+# enum is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically be
+# useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+# The default value is: NO.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
+# cache is used to resolve symbols given their name and scope. Since this can be
+# an expensive process and often the same symbol appears multiple times in the
+# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small
+# doxygen will become slower. If the cache is too large, memory is wasted. The
+# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range
+# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536
+# symbols. At the end of a run doxygen will report the cache usage and suggest
+# the optimal cache size from a speed point of view.
+# Minimum value: 0, maximum value: 9, default value: 0.
+
+LOOKUP_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in
+# documentation are documented, even if no documentation was available. Private
+# class members and static file members will be hidden unless the
+# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
+# Note: This will also disable the warnings about undocumented members that are
+# normally produced when WARNINGS is set to YES.
+# The default value is: NO.
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will
+# be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal
+# scope will be included in the documentation.
+# The default value is: NO.
+
+EXTRACT_PACKAGE = YES
+
+# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be
+# included in the documentation.
+# The default value is: NO.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined
+# locally in source files will be included in the documentation. If set to NO,
+# only classes defined in header files are included. Does not have any effect
+# for Java sources.
+# The default value is: YES.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. If set to YES, local methods,
+# which are defined in the implementation section but not in the interface are
+# included in the documentation. If set to NO, only methods in the interface are
+# included.
+# The default value is: NO.
+
+EXTRACT_LOCAL_METHODS = YES
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base name of
+# the file that contains the anonymous namespace. By default anonymous namespace
+# are hidden.
+# The default value is: NO.
+
+EXTRACT_ANON_NSPACES = YES
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
+# undocumented members inside documented classes or files. If set to NO these
+# members will be included in the various overviews, but no documentation
+# section is generated. This option has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy. If set
+# to NO, these classes will be included in the various overviews. This option
+# has no effect if EXTRACT_ALL is enabled.
+# The default value is: NO.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
+# (class|struct|union) declarations. If set to NO, these declarations will be
+# included in the documentation.
+# The default value is: NO.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any
+# documentation blocks found inside the body of a function. If set to NO, these
+# blocks will be appended to the function's detailed documentation block.
+# The default value is: NO.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation that is typed after a
+# \internal command is included. If the tag is set to NO then the documentation
+# will be excluded. Set it to YES to include the internal documentation.
+# The default value is: NO.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
+# names in lower-case letters. If set to YES, upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+# The default value is: system dependent.
+
+CASE_SENSE_NAMES = YES
+
+# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with
+# their full class and namespace scopes in the documentation. If set to YES, the
+# scope will be hidden.
+# The default value is: NO.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
+# append additional text to a page's title, such as Class Reference. If set to
+# YES the compound reference will be hidden.
+# The default value is: NO.
+
+HIDE_COMPOUND_REFERENCE= NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
+# the files that are included by a file in the documentation of that file.
+# The default value is: YES.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each
+# grouped member an include statement to the documentation, telling the reader
+# which file to include in order to use the member.
+# The default value is: NO.
+
+SHOW_GROUPED_MEMB_INC = NO
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
+# files with double quotes in the documentation rather than with sharp brackets.
+# The default value is: NO.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the
+# documentation for inline members.
+# The default value is: YES.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
+# (detailed) documentation of file and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order.
+# The default value is: YES.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
+# descriptions of file, namespace and class members alphabetically by member
+# name. If set to NO, the members will appear in declaration order. Note that
+# this will also influence the order of the classes in the class list.
+# The default value is: NO.
+
+SORT_BRIEF_DOCS = YES
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
+# (brief and detailed) documentation of class members so that constructors and
+# destructors are listed first. If set to NO the constructors will appear in the
+# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS.
+# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief
+# member documentation.
+# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting
+# detailed member documentation.
+# The default value is: NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy
+# of group names into alphabetical order. If set to NO the group names will
+# appear in their defined order.
+# The default value is: NO.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by
+# fully-qualified names, including namespaces. If set to NO, the class list will
+# be sorted only by class name, not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the alphabetical
+# list.
+# The default value is: NO.
+
+SORT_BY_SCOPE_NAME = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper
+# type resolution of all parameters of a function it will reject a match between
+# the prototype and the implementation of a member function even if there is
+# only one candidate or it is obvious which candidate to choose by doing a
+# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still
+# accept a match between prototype and implementation in such cases.
+# The default value is: NO.
+
+STRICT_PROTO_MATCHING = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
+# list. This list is created by putting \todo commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TODOLIST = NO
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
+# list. This list is created by putting \test commands in the documentation.
+# The default value is: YES.
+
+GENERATE_TESTLIST = NO
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug
+# list. This list is created by putting \bug commands in the documentation.
+# The default value is: YES.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO)
+# the deprecated list. This list is created by putting \deprecated commands in
+# the documentation.
+# The default value is: YES.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional documentation
+# sections, marked by \if ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../moose-core/basecode \
+ ../../moose-core/biophysics \
+ ../../moose-core/builtins \
+ ../../moose-core/device \
+ ../../moose-core/diffusion \
+ ../../moose-core/hsolve \
+ ../../moose-core/intfire \
+ ../../moose-core/kinetics \
+ ../../moose-core/ksolve \
+ ../../moose-core/mesh \
+ ../../moose-core/mpi \
+ ../../moose-core/msg \
+ ../../moose-core/randnum \
+ ../../moose-core/pymoose \
+ ../../moose-core/scheduling \
+ ../../moose-core/shell \
+ ../../moose-core/signeur \
+ ../../moose-core/synapse \
+ ../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = NO
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/images/MOOSE_MPI_threading.gif b/docs/images/MOOSE_MPI_threading.gif
new file mode 100644
index 0000000000..885806f0b0
Binary files /dev/null and b/docs/images/MOOSE_MPI_threading.gif differ
diff --git a/docs/images/MOOSE_threading.gif b/docs/images/MOOSE_threading.gif
new file mode 100644
index 0000000000..e92b7ab8f9
Binary files /dev/null and b/docs/images/MOOSE_threading.gif differ
diff --git a/docs/images/neuronalcompartment.jpg b/docs/images/neuronalcompartment.jpg
new file mode 100644
index 0000000000..6dd6702346
Binary files /dev/null and b/docs/images/neuronalcompartment.jpg differ
diff --git a/docs/images/neuroncompartment.fig b/docs/images/neuroncompartment.fig
new file mode 100644
index 0000000000..fa7e32a22b
--- /dev/null
+++ b/docs/images/neuroncompartment.fig
@@ -0,0 +1,369 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Portrait
+Center
+Metric
+A4
+200.00
+Single
+-2
+1200 2
+6 3465 3285 7155 5085
+6 3465 3285 7155 5085
+6 5805 3645 6165 4770
+6 5805 3671 6165 4770
+6 5805 4320 6165 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5805 4500 6165 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5895 4590 6075 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5985 4500 5985 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5985 4590 5985 4770
+-6
+# Resistor
+6 5880 3671 6060 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 5985 3686 5985 3824 5914 3847 6057 3893 5914 3939 6057 3984
+ 5914 4030 6057 4076 5914 4122 6057 4167 5985 4190 5985 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 5850 4230 6120 3735
+-6
+6 5040 3645 5400 4770
+# Resistor
+6 5115 3671 5295 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 5220 3686 5220 3824 5149 3847 5292 3893 5149 3939 5292 3984
+ 5149 4030 5292 4076 5149 4122 5292 4167 5220 4190 5220 4329
+-6
+6 5040 4320 5400 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5400 4590 5040 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5310 4500 5130 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5220 4590 5220 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5220 4500 5220 4320
+-6
+-6
+# Resistor
+6 3493 3585 4168 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 4153 3690 4015 3690 3992 3619 3946 3762 3900 3619 3855 3762
+ 3809 3619 3763 3762 3717 3619 3672 3762 3649 3690 3510 3690
+-6
+# Resistor
+6 6464 3585 7139 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 7124 3690 6986 3690 6963 3619 6917 3762 6871 3619 6826 3762
+ 6780 3619 6734 3762 6688 3619 6643 3762 6620 3690 6481 3690
+-6
+# Non-polar capacitor
+6 4237 3782 4745 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4269 4146 4730 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4500 3800 4500 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4500 4261 4500 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4269 4261 4730 4261
+-6
+# Ground
+6 5265 4725 5580 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5409 4761 5409 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5266 4903 5551 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5337 4975 5480 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5380 5046 5451 5046
+-6
+6 4435 3642 4570 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4498 3689 28 28 4498 3689 4526 3689
+-6
+6 5156 3642 5291 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5219 3689 28 28 5219 3689 5247 3689
+-6
+6 5921 3642 6056 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5984 3689 28 28 5984 3689 6012 3689
+-6
+6 5344 4723 5479 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5407 4770 28 28 5407 4770 5435 4770
+-6
+6 4798 3374 4933 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 4858 3461 47 47 4858 3461 4906 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4140 3690 6480 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 3825 4500 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 4590 4500 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 4770 5985 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4860 3510 4860 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 5355 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 5355 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 6165 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 6165 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 4635 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 4955 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 3664 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 6637 3987 Ra/2\001
+-6
+6 5158 4724 5293 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5221 4771 28 28 5221 4771 5249 4771
+-6
+6 4798 3641 4933 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4861 3688 28 28 4861 3688 4889 3688
+-6
+-6
+6 -360 3285 3330 5085
+6 -360 3285 3330 5085
+6 1980 3645 2340 4770
+6 1980 3671 2340 4770
+6 1980 4320 2340 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1980 4500 2340 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2070 4590 2250 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2160 4500 2160 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2160 4590 2160 4770
+-6
+# Resistor
+6 2055 3671 2235 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 2160 3686 2160 3824 2089 3847 2232 3893 2089 3939 2232 3984
+ 2089 4030 2232 4076 2089 4122 2232 4167 2160 4190 2160 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 2025 4230 2295 3735
+-6
+6 1215 3645 1575 4770
+# Resistor
+6 1290 3671 1470 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 1395 3686 1395 3824 1324 3847 1467 3893 1324 3939 1467 3984
+ 1324 4030 1467 4076 1324 4122 1467 4167 1395 4190 1395 4329
+-6
+6 1215 4320 1575 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1575 4590 1215 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1485 4500 1305 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1395 4590 1395 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1395 4500 1395 4320
+-6
+-6
+# Resistor
+6 -332 3585 343 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 328 3690 190 3690 167 3619 121 3762 75 3619 30 3762
+ -16 3619 -62 3762 -108 3619 -153 3762 -176 3690 -315 3690
+-6
+# Resistor
+6 2639 3585 3314 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 3299 3690 3161 3690 3138 3619 3092 3762 3046 3619 3001 3762
+ 2955 3619 2909 3762 2863 3619 2818 3762 2795 3690 2656 3690
+-6
+# Non-polar capacitor
+6 412 3782 920 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 444 4146 905 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 675 3800 675 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 675 4261 675 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 444 4261 905 4261
+-6
+# Ground
+6 1440 4725 1755 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1584 4761 1584 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1441 4903 1726 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1512 4975 1655 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1555 5046 1626 5046
+-6
+6 610 3642 745 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 673 3689 28 28 673 3689 701 3689
+-6
+6 1331 3642 1466 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1394 3689 28 28 1394 3689 1422 3689
+-6
+6 2096 3642 2231 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 2159 3689 28 28 2159 3689 2187 3689
+-6
+6 1519 4723 1654 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1582 4770 28 28 1582 4770 1610 4770
+-6
+6 973 3374 1108 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 1033 3461 47 47 1033 3461 1081 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 315 3690 2655 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 3825 675 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 4590 675 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 4770 2160 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1035 3510 1035 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 1530 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 1530 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 2340 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 2340 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 810 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 1130 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 -161 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 2812 3987 Ra/2\001
+-6
+6 1333 4724 1468 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1396 4771 28 28 1396 4771 1424 4771
+-6
+6 973 3641 1108 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1036 3688 28 28 1036 3688 1064 3688
+-6
+-6
+6 7290 3285 10980 5085
+6 7290 3285 10980 5085
+6 9630 3645 9990 4770
+6 9630 3671 9990 4770
+6 9630 4320 9990 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9630 4500 9990 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9720 4590 9900 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9810 4500 9810 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9810 4590 9810 4770
+-6
+# Resistor
+6 9705 3671 9885 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 9810 3686 9810 3824 9739 3847 9882 3893 9739 3939 9882 3984
+ 9739 4030 9882 4076 9739 4122 9882 4167 9810 4190 9810 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 9675 4230 9945 3735
+-6
+6 8865 3645 9225 4770
+# Resistor
+6 8940 3671 9120 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 9045 3686 9045 3824 8974 3847 9117 3893 8974 3939 9117 3984
+ 8974 4030 9117 4076 8974 4122 9117 4167 9045 4190 9045 4329
+-6
+6 8865 4320 9225 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9225 4590 8865 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9135 4500 8955 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9045 4590 9045 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9045 4500 9045 4320
+-6
+-6
+# Resistor
+6 7318 3585 7993 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 7978 3690 7840 3690 7817 3619 7771 3762 7725 3619 7680 3762
+ 7634 3619 7588 3762 7542 3619 7497 3762 7474 3690 7335 3690
+-6
+# Resistor
+6 10289 3585 10964 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 10949 3690 10811 3690 10788 3619 10742 3762 10696 3619 10651 3762
+ 10605 3619 10559 3762 10513 3619 10468 3762 10445 3690 10306 3690
+-6
+# Non-polar capacitor
+6 8062 3782 8570 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8094 4146 8555 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8325 3800 8325 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8325 4261 8325 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8094 4261 8555 4261
+-6
+# Ground
+6 9090 4725 9405 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9234 4761 9234 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9091 4903 9376 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9162 4975 9305 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9205 5046 9276 5046
+-6
+6 8260 3642 8395 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 8323 3689 28 28 8323 3689 8351 3689
+-6
+6 8981 3642 9116 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9044 3689 28 28 9044 3689 9072 3689
+-6
+6 9746 3642 9881 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9809 3689 28 28 9809 3689 9837 3689
+-6
+6 9169 4723 9304 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9232 4770 28 28 9232 4770 9260 4770
+-6
+6 8623 3374 8758 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 8683 3461 47 47 8683 3461 8731 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 7965 3690 10305 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 3825 8325 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 4590 8325 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 4770 9810 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8685 3510 8685 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 9180 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 9180 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 9990 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 9990 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 8460 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 8780 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 7489 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 10462 3987 Ra/2\001
+-6
+6 8983 4724 9118 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9046 4771 28 28 9046 4771 9074 4771
+-6
+6 8623 3641 8758 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 8686 3688 28 28 8686 3688 8714 3688
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 3285 3690 3510 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 7110 3690 7335 3690
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3420 3240 7245 3240 7245 5130 3420 5130 3420 3240
diff --git a/docs/readthedocs-pip-requirements.txt b/docs/readthedocs-pip-requirements.txt
new file mode 100644
index 0000000000..e05848ed60
--- /dev/null
+++ b/docs/readthedocs-pip-requirements.txt
@@ -0,0 +1,2 @@
+numpydoc
+mock
diff --git a/docs/source/Extensions/hidden_code_block.py b/docs/source/Extensions/hidden_code_block.py
new file mode 100644
index 0000000000..cc307bdda2
--- /dev/null
+++ b/docs/source/Extensions/hidden_code_block.py
@@ -0,0 +1,168 @@
+"""Simple, inelegant Sphinx extension which adds a directive for a
+highlighted code-block that may be toggled hidden and shown in HTML.
+This is possibly useful for teaching courses.
+
+The directive, like the standard code-block directive, takes
+a language argument and an optional linenos parameter. The
+hidden-code-block adds starthidden and label as optional
+parameters.
+
+Examples:
+
+.. hidden-code-block:: python
+ :starthidden: False
+
+ a = 10
+ b = a + 5
+
+.. hidden-code-block:: python
+ :label: --- SHOW/HIDE ---
+
+ x = 10
+ y = x + 5
+
+Thanks to http://www.javascriptkit.com/javatutors/dom3.shtml for
+inspiration on the javascript.
+
+Thanks to Milad 'animal' Fatenejad for suggesting this extension
+in the first place.
+
+Written by Anthony 'el Scopz' Scopatz, January 2012.
+
+Released under the WTFPL (http://sam.zoy.org/wtfpl/).
+"""
+
+from docutils import nodes
+from docutils.parsers.rst import directives
+from sphinx.directives.code import CodeBlock
+
+# Fixes from https://github.com/abakan/ablog/commit/413566341b36d2b855fdebe133e15edcd4542785
+try:
+ from sphinx.util.compat import make_admonition
+except ImportError as e:
+ from docutils.parsers.rst.directives.admonitions import BaseAdmonition as make_admonition
+
+HCB_COUNTER = 0
+
+js_showhide = """\
+
+"""
+
+def nice_bool(arg):
+ tvalues = ('true', 't', 'yes', 'y')
+ fvalues = ('false', 'f', 'no', 'n')
+ arg = directives.choice(arg, tvalues + fvalues)
+ return arg in tvalues
+
+
+class hidden_code_block(nodes.General, nodes.FixedTextElement):
+ pass
+
+
+class HiddenCodeBlock(CodeBlock):
+ """Hidden code block is Hidden"""
+
+ option_spec = dict(starthidden=nice_bool,
+ label=str,
+ **CodeBlock.option_spec)
+
+ def run(self):
+ # Body of the method is more or less copied from CodeBlock
+ code = u'\n'.join(self.content)
+ hcb = hidden_code_block(code, code)
+ hcb['language'] = self.arguments[0]
+ hcb['linenos'] = 'linenos' in self.options
+ hcb['starthidden'] = self.options.get('starthidden', True)
+ hcb['label'] = self.options.get('label', '+ show/hide code')
+ hcb.line = self.lineno
+ return [hcb]
+
+def visit_hcb_tex( self, node ):
+ global HCB_COUNTER
+
+ # We want to use the original highlighter so that we don't
+ # have to reimplement it. However it raises a SkipNode
+ # error at the end of the function call. Thus we intercept
+ # it and raise it again later.
+ try:
+ self.visit_literal_block(node)
+ except nodes.SkipNode:
+ pass
+
+ ## The last element of the body should be the literal code
+ ## block that was just made.
+ #code_block = self.body[-1]
+
+ #fill_header = {'divname': 'hiddencodeblock{0}'.format(HCB_COUNTER),
+ # 'startdisplay': 'none' if node['starthidden'] else 'block',
+ # 'label': node.get('label'),
+ # }
+
+ #divheader = (""""""
+ # """{label} '''
+ # ).format(**fill_header)
+
+ #code_block = js_showhide + divheader + code_block + "
"
+
+ ## reassign and exit
+ #self.body[-1] = code_block
+ raise nodes.SkipNode
+
+def depart_hcb_tex( self, node ):
+ pass
+
+
+def visit_hcb_html(self, node):
+ """Visit hidden code block"""
+ global HCB_COUNTER
+ HCB_COUNTER += 1
+
+ # We want to use the original highlighter so that we don't
+ # have to reimplement it. However it raises a SkipNode
+ # error at the end of the function call. Thus we intercept
+ # it and raise it again later.
+ try:
+ self.visit_literal_block(node)
+ except nodes.SkipNode:
+ pass
+
+ # The last element of the body should be the literal code
+ # block that was just made.
+ code_block = self.body[-1]
+
+ fill_header = {'divname': 'hiddencodeblock{0}'.format(HCB_COUNTER),
+ 'startdisplay': 'none' if node['starthidden'] else 'block',
+ 'label': node.get('label'),
+ }
+
+ divheader = (""""""
+ """{label} '''
+ ).format(**fill_header)
+
+ code_block = js_showhide + divheader + code_block + "
"
+
+ # reassign and exit
+ self.body[-1] = code_block
+ raise nodes.SkipNode
+
+
+def depart_hcb_html(self, node):
+ """Depart hidden code block"""
+ # Stub because of SkipNode in visit
+
+def setup(app):
+ app.add_directive('hidden-code-block', HiddenCodeBlock)
+ app.add_node(hidden_code_block, html=(visit_hcb_html, depart_hcb_html))
+ app.add_node(hidden_code_block, latex=(visit_hcb_tex, depart_hcb_tex))
diff --git a/docs/source/changes/index.rst b/docs/source/changes/index.rst
new file mode 100644
index 0000000000..d3826cd196
--- /dev/null
+++ b/docs/source/changes/index.rst
@@ -0,0 +1,15 @@
+Series `chennapoda`
+===================
+
+Version 3.2.0
+-------------
+
+- Improved SBML support.
+- NeuroML2 support (Thanks to Padraig Glesson)
+- Various bugfixes.
+
+Series `chamcham`
+=================
+
+Version 3.1.3
+-------------
diff --git a/docs/source/conf.py b/docs/source/conf.py
new file mode 100644
index 0000000000..43a10e7d8b
--- /dev/null
+++ b/docs/source/conf.py
@@ -0,0 +1,306 @@
+# -*- coding: utf-8 -*-
+#
+# MOOSE documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 1 19:05:47 2014.
+# updated on Thr Jan 21 00:30:10 2016
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+#Workaround to fix bug where extensions werent added
+from docutils.parsers.rst.directives.admonitions import BaseAdmonition
+from sphinx.util import compat
+compat.make_admonition = BaseAdmonition
+
+import subprocess
+import os
+import sys
+import sphinx_rtd_theme
+import mock
+
+conf_dir_ = os.path.dirname( __file__ )
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath('/home/harsha/MOOSE/FullMoose/moose-core/python'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/snippets'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/tutorials/ChemicalOscillators'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/tutorials/ChemicalBistables'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/tutorials/ExcInhNet'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/neuroml/lobster_pyloric'))
+sys.path.append(os.path.abspath('/home/harsha/MOOSE/moose-examples-july/tutorials/ExcInhNetCaPlasticity'))
+sys.path.append(os.path.join(conf_dir_, 'Extensions') )
+
+# -- General configuration -----------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['sphinx.ext.autodoc',
+ 'sphinx.ext.mathjax',
+ 'sphinx.ext.autosummary',
+ 'sphinx.ext.todo',
+ 'sphinx.ext.viewcode',
+ 'hidden_code_block'
+ ]
+
+todo_include_todos = True
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'MOOSE'
+copyright = u'2018, Upinder Bhalla, Niraj Dudani, Subhasis Ray, ' + \
+ 'Aditya Gilra,Harsha Rani, Aviral Goel, Dilawar Singh,' + \
+ 'Malav Shah, Dhruva Gowda Storz'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '3.2'
+# The full version, including alpha/beta/rc tags.
+release = 'chennapoda (3.2.rc)'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = 'English'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+today = ''
+# Else, today_fmt is used as the format for a strftime call.
+today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = True
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+html_theme = 'sphinx_rtd_theme'
+
+html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+# html_theme_options = {'stickysidebar': 'true',
+# 'sidebarwidth': '300'}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# " v documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+html_logo = 'images/moose_logo.png'
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a ... \endif and \cond
+# ... \endcond blocks.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the
+# initial value of a variable or macro / define can have for it to appear in the
+# documentation. If the initializer consists of more lines than specified here
+# it will be hidden. Use a value of 0 to hide initializers completely. The
+# appearance of the value of individual variables and macros / defines can be
+# controlled using \showinitializer or \hideinitializer command in the
+# documentation regardless of this setting.
+# Minimum value: 0, maximum value: 10000, default value: 30.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at
+# the bottom of the documentation of classes and structs. If set to YES, the
+# list will mention the files that were used to generate the documentation.
+# The default value is: YES.
+
+SHOW_USED_FILES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
+# will remove the Files entry from the Quick Index and from the Folder Tree View
+# (if specified).
+# The default value is: YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
+# page. This will remove the Namespaces entry from the Quick Index and from the
+# Folder Tree View (if specified).
+# The default value is: YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command command input-file, where command is the value of the
+# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided
+# by doxygen. Whatever the program writes to standard output is used as the file
+# version. For an example see the documentation.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. To create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option. You can
+# optionally specify a file name after the option, if omitted DoxygenLayout.xml
+# will be used as the name of the layout file.
+#
+# Note that if you run doxygen from a directory containing a file called
+# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
+# tag is left empty.
+
+LAYOUT_FILE =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
+# the reference definitions. This must be a list of .bib files. The .bib
+# extension is automatically appended if omitted. This requires the bibtex tool
+# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info.
+# For LaTeX the style of the bibliography can be controlled using
+# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the
+# search path. See also \cite for info how to create references.
+
+CITE_BIB_FILES =
+
+#---------------------------------------------------------------------------
+# Configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated to
+# standard output by doxygen. If QUIET is set to YES this implies that the
+# messages are off.
+# The default value is: NO.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES
+# this implies that the warnings are on.
+#
+# Tip: Turn warnings on while writing the documentation.
+# The default value is: YES.
+
+WARNINGS = YES
+
+# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate
+# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
+# will automatically be disabled.
+# The default value is: YES.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some parameters
+# in a documented function, or documenting parameters that don't exist or using
+# markup commands wrongly.
+# The default value is: YES.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
+# are documented, but have no documentation for their parameters or return
+# value. If set to NO, doxygen will only warn about wrong or incomplete
+# parameter documentation, but not about the absence of documentation.
+# The default value is: NO.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that doxygen
+# can produce. The string should contain the $file, $line, and $text tags, which
+# will be replaced by the file and line number from which the warning originated
+# and the warning text. Optionally the format may contain $version, which will
+# be replaced by the version of the file (if it could be obtained via
+# FILE_VERSION_FILTER)
+# The default value is: $file:$line: $text.
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning and error
+# messages should be written. If left blank the output is written to standard
+# error (stderr).
+
+WARN_LOGFILE = cpp/doxygen-logfile
+
+#---------------------------------------------------------------------------
+# Configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag is used to specify the files and/or directories that contain
+# documented source files. You may enter file names like myfile.cpp or
+# directories like /usr/src/myproject. Separate the files or directories with
+# spaces.
+# Note: If this tag is empty the current directory is searched.
+
+INPUT = ../../../moose-core/basecode \
+ ../../../moose-core/biophysics \
+ ../../../moose-core/builtins \
+ ../../../moose-core/device \
+ ../../../moose-core/diffusion \
+ ../../../moose-core/hsolve \
+ ../../../moose-core/intfire \
+ ../../../moose-core/kinetics \
+ ../../../moose-core/ksolve \
+ ../../../moose-core/mesh \
+ ../../../moose-core/mpi \
+ ../../../moose-core/msg \
+ ../../../moose-core/randnum \
+ ../../../moose-core/pymoose \
+ ../../../moose-core/scheduling \
+ ../../../moose-core/shell \
+ ../../../moose-core/signeur \
+ ../../../moose-core/synapse \
+ ../../../moose-core/utility
+
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
+# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
+# documentation (see: http://www.gnu.org/software/libiconv) for the list of
+# possible encodings.
+# The default value is: UTF-8.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank the
+# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii,
+# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp,
+# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown,
+# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf,
+# *.qsf, *.as and *.js.
+
+FILE_PATTERNS = *.cpp \
+ *.hpp \
+ *.c \
+ *.h \
+ *.cc \
+ *.hh \
+ *.cxx \
+ *.hxx
+
+
+# The RECURSIVE tag can be used to specify whether or not subdirectories should
+# be searched for input files as well.
+# The default value is: NO.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+#
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system feature) are excluded
+# from the input.
+# The default value is: NO.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories.
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+#
+# Note that the wildcards are matched against the file with absolute path, so to
+# exclude all test directories use the pattern */test/*
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or directories
+# that contain example code fragments that are included (see the \include
+# command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
+# *.h) to filter out the source-files in the directories. If left blank all
+# files are included.
+
+EXAMPLE_PATTERNS =
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude commands
+# irrespective of the value of the RECURSIVE tag.
+# The default value is: NO.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or directories
+# that contain images that are to be included in the documentation (see the
+# \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command:
+#
+#
+#
+# where is the value of the INPUT_FILTER tag, and is the
+# name of an input file. Doxygen will then use the output that the filter
+# program writes to standard output. If FILTER_PATTERNS is specified, this tag
+# will be ignored.
+#
+# Note that the filter must not add or remove lines; it is applied before the
+# code is scanned, but not when the output code is generated. If lines are added
+# or removed, the anchors will not be placed correctly.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form: pattern=filter
+# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how
+# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
+# patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will also be used to filter the input files that are used for
+# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES).
+# The default value is: NO.
+
+FILTER_SOURCE_FILES = NO
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and
+# it is also possible to disable source filtering for a specific pattern using
+# *.ext= (so without naming a filter).
+# This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
+
+FILTER_SOURCE_PATTERNS =
+
+# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that
+# is part of the input, its contents will be placed on the main page
+# (index.html). This can be useful if you have a project on for instance GitHub
+# and want to reuse the introduction page also for the doxygen output.
+
+USE_MDFILE_AS_MAINPAGE =
+
+#---------------------------------------------------------------------------
+# Configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will be
+# generated. Documented entities will be cross-referenced with these sources.
+#
+# Note: To get rid of all source code in the generated output, make sure that
+# also VERBATIM_HEADERS is set to NO.
+# The default value is: NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body of functions,
+# classes and enums directly into the documentation.
+# The default value is: NO.
+
+INLINE_SOURCES = YES
+
+# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
+# special comment blocks from generated source code fragments. Normal C, C++ and
+# Fortran comments will always remain visible.
+# The default value is: YES.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES then for each documented
+# function all documented functions referencing it will be listed.
+# The default value is: NO.
+
+REFERENCED_BY_RELATION = YES
+
+# If the REFERENCES_RELATION tag is set to YES then for each documented function
+# all documented entities called/used by that function will be listed.
+# The default value is: NO.
+
+REFERENCES_RELATION = YES
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set
+# to YES then the hyperlinks from functions in REFERENCES_RELATION and
+# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will
+# link to the documentation.
+# The default value is: YES.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
+# source code will show a tooltip with additional information such as prototype,
+# brief description and links to the definition and documentation. Since this
+# will make the HTML file larger and loading of large files a bit slower, you
+# can opt to disable this feature.
+# The default value is: YES.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+SOURCE_TOOLTIPS = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code will
+# point to the HTML generated by the htags(1) tool instead of doxygen built-in
+# source browser. The htags tool is part of GNU's global source tagging system
+# (see http://www.gnu.org/software/global/global.html). You will need version
+# 4.8.6 or higher.
+#
+# To use it do the following:
+# - Install the latest version of global
+# - Enable SOURCE_BROWSER and USE_HTAGS in the config file
+# - Make sure the INPUT points to the root of the source tree
+# - Run doxygen as normal
+#
+# Doxygen will invoke htags (and that will in turn invoke gtags), so these
+# tools must be available from the command line (i.e. in the search path).
+#
+# The result: instead of the source browser generated by doxygen, the links to
+# source code will now point to the output of htags.
+# The default value is: NO.
+# This tag requires that the tag SOURCE_BROWSER is set to YES.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a
+# verbatim copy of the header file for each class for which an include is
+# specified. Set to NO to disable this.
+# See also: Section \class.
+# The default value is: YES.
+
+VERBATIM_HEADERS = YES
+
+# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
+# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
+# cost of reduced performance. This can be particularly helpful with template
+# rich C++ code for which doxygen's built-in parser lacks the necessary type
+# information.
+# Note: The availability of this option depends on whether or not doxygen was
+# compiled with the --with-libclang option.
+# The default value is: NO.
+
+CLANG_ASSISTED_PARSING = YES
+
+# If clang assisted parsing is enabled you can provide the compiler with command
+# line options that you would normally use when invoking the compiler. Note that
+# the include paths will already be set by doxygen for the files and directories
+# specified with INPUT and INCLUDE_PATH.
+# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
+
+CLANG_OPTIONS = -std=c++11
+
+#---------------------------------------------------------------------------
+# Configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all
+# compounds will be generated. Enable this if the project contains a lot of
+# classes, structs, unions or interfaces.
+# The default value is: YES.
+
+ALPHABETICAL_INDEX = YES
+
+# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
+# which the alphabetical index list will be split.
+# Minimum value: 1, maximum value: 20, default value: 5.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all classes will
+# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
+# can be used to specify a prefix (or a list of prefixes) that should be ignored
+# while generating the index headers.
+# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output
+# The default value is: YES.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each
+# generated HTML page (for example: .htm, .php, .asp).
+# The default value is: .html.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a user-defined HTML header file for
+# each generated HTML page. If the tag is left blank doxygen will generate a
+# standard header.
+#
+# To get valid HTML the header file that includes any scripts and style sheets
+# that doxygen needs, which is dependent on the configuration options used (e.g.
+# the setting GENERATE_TREEVIEW). It is highly recommended to start with a
+# default header using
+# doxygen -w html new_header.html new_footer.html new_stylesheet.css
+# YourConfigFile
+# and then modify the file new_header.html. See also section "Doxygen usage"
+# for information on how to generate the default header that doxygen normally
+# uses.
+# Note: The header is subject to change so you typically have to regenerate the
+# default header when upgrading to a newer version of doxygen. For a description
+# of the possible markers and block names see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
+# generated HTML page. If the tag is left blank doxygen will generate a standard
+# footer. See HTML_HEADER for more information on how to generate a default
+# footer and what special commands can be used inside the footer. See also
+# section "Doxygen usage" for information on how to generate the default footer
+# that doxygen normally uses.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
+# sheet that is used by each HTML page. It can be used to fine-tune the look of
+# the HTML output. If left blank doxygen will generate a default style sheet.
+# See also section "Doxygen usage" for information on how to generate the style
+# sheet that doxygen normally uses.
+# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as
+# it is more robust and this tag (HTML_STYLESHEET) will in the future become
+# obsolete.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_STYLESHEET =
+
+# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# cascading style sheets that are included after the standard style sheets
+# created by doxygen. Using this option one can overrule certain style aspects.
+# This is preferred over using HTML_STYLESHEET since it does not replace the
+# standard style sheet and is therefore more robust against future updates.
+# Doxygen will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list). For an example see the documentation.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_STYLESHEET =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that the
+# files will be copied as-is; there are no commands or markers available.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_EXTRA_FILES =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
+# will adjust the colors in the style sheet and background images according to
+# this color. Hue is specified as an angle on a colorwheel, see
+# http://en.wikipedia.org/wiki/Hue for more information. For instance the value
+# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
+# purple, and 360 is red again.
+# Minimum value: 0, maximum value: 359, default value: 220.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
+# in the HTML output. For a value of 0 the output will use grayscales only. A
+# value of 255 will produce the most vivid colors.
+# Minimum value: 0, maximum value: 255, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the
+# luminance component of the colors in the HTML output. Values below 100
+# gradually make the output lighter, whereas values above 100 make the output
+# darker. The value divided by 100 is the actual gamma applied, so 80 represents
+# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not
+# change the gamma.
+# Minimum value: 40, maximum value: 240, default value: 80.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting this
+# to NO can help when comparing the output of multiple runs.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
+# shown in the various tree structured indices initially; the user can expand
+# and collapse entries dynamically later on. Doxygen will expand the tree to
+# such a level that at most the specified number of entries are visible (unless
+# a fully collapsed tree already exceeds this amount). So setting the number of
+# entries 1 will produce a full collapsed tree by default. 0 is a special value
+# representing an infinite number of entries and will result in a full expanded
+# tree by default.
+# Minimum value: 0, maximum value: 9999, default value: 100.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+HTML_INDEX_NUM_ENTRIES = 100
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files will be
+# generated that can be used as input for Apple's Xcode 3 integrated development
+# environment (see: http://developer.apple.com/tools/xcode/), introduced with
+# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a
+# Makefile in the HTML output directory. Running make will produce the docset in
+# that directory and running make install will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
+# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_DOCSET = NO
+
+# This tag determines the name of the docset feed. A documentation feed provides
+# an umbrella under which multiple documentation sets from a single provider
+# (such as a company or product suite) can be grouped.
+# The default value is: Doxygen generated docs.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# This tag specifies a string that should uniquely identify the documentation
+# set bundle. This should be a reverse domain-name style string, e.g.
+# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+# The default value is: org.doxygen.Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher.
+# The default value is: Publisher.
+# This tag requires that the tag GENERATE_DOCSET is set to YES.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
+# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
+# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
+# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on
+# Windows.
+#
+# The HTML Help Workshop contains a compiler that can convert all HTML output
+# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
+# files are now used as the Windows 98 help format, and will replace the old
+# Windows help format (.hlp) on all Windows platforms in the future. Compressed
+# HTML files also contain an index, a table of contents, and you can search for
+# words in the documentation. The HTML workshop also contains a viewer for
+# compressed HTML files.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_HTMLHELP = NO
+
+# The CHM_FILE tag can be used to specify the file name of the resulting .chm
+# file. You can add a path in front of the file if the result should not be
+# written to the html output directory.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_FILE =
+
+# The HHC_LOCATION tag can be used to specify the location (absolute path
+# including file name) of the HTML help compiler (hhc.exe). If non-empty,
+# doxygen will try to run the HTML help compiler on the generated index.hhp.
+# The file has to be specified with full path.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+HHC_LOCATION =
+
+# The GENERATE_CHI flag controls if a separate .chi index file is generated
+# (YES) or that it should be included in the master .chm file (NO).
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+GENERATE_CHI = NO
+
+# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc)
+# and project file content.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+CHM_INDEX_ENCODING =
+
+# The BINARY_TOC flag controls whether a binary table of contents is generated
+# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it
+# enables the Previous and Next buttons.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members to
+# the table of contents of the HTML help documentation and to the tree view.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
+# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
+# (.qch) of the generated HTML documentation.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify
+# the file name of the resulting .qch file. The path specified is relative to
+# the HTML output folder.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
+# Project output. For more information please see Qt Help Project / Namespace
+# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace).
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
+# Help Project output. For more information please see Qt Help Project / Virtual
+# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-
+# folders).
+# The default value is: doc.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
+# filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see Qt Help Project / Custom
+# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-
+# filters).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's filter section matches. Qt Help Project / Filter Attributes (see:
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes).
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHP_SECT_FILTER_ATTRS =
+
+# The QHG_LOCATION tag can be used to specify the location of Qt's
+# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
+# generated .qhp file.
+# This tag requires that the tag GENERATE_QHP is set to YES.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be
+# generated, together with the HTML files, they form an Eclipse help plugin. To
+# install this plugin and make it available under the help contents menu in
+# Eclipse, the contents of the directory containing the HTML and XML files needs
+# to be copied into the plugins directory of eclipse. The name of the directory
+# within the plugins directory should be the same as the ECLIPSE_DOC_ID value.
+# After copying Eclipse needs to be restarted before the help appears.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the Eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have this
+# name. Each documentation set should have its own identifier.
+# The default value is: org.doxygen.Project.
+# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# If you want full control over the layout of the generated HTML pages it might
+# be necessary to disable the index and replace it with your own. The
+# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top
+# of each HTML page. A value of NO enables the index and the value YES disables
+# it. Since the tabs in the index contain the same information as the navigation
+# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+DISABLE_INDEX = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information. If the tag
+# value is set to YES, a side panel will be generated containing a tree-like
+# index structure (just like the one that is generated for HTML Help). For this
+# to work a browser that supports JavaScript, DHTML, CSS and frames is required
+# (i.e. any modern browser). Windows users are probably better off using the
+# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
+# further fine-tune the look of the index. As an example, the default style
+# sheet generated by doxygen has an example that shows how to put an image at
+# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
+# the same information as the tab index, you could consider setting
+# DISABLE_INDEX to YES when enabling this option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+GENERATE_TREEVIEW = YES
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
+# doxygen will group on one line in the generated HTML documentation.
+#
+# Note that a value of 0 will completely suppress the enum values from appearing
+# in the overview section.
+# Minimum value: 0, maximum value: 20, default value: 4.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+ENUM_VALUES_PER_LINE = 4
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used
+# to set the initial width (in pixels) of the frame in which the tree is shown.
+# Minimum value: 0, maximum value: 1500, default value: 250.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+TREEVIEW_WIDTH = 250
+
+# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to
+# external symbols imported via tag files in a separate window.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of LaTeX formulas included as images in
+# the HTML documentation. When you change the font size after a successful
+# doxygen run you need to manually remove any form_*.png images from the HTML
+# output directory to force them to be regenerated.
+# Minimum value: 8, maximum value: 50, default value: 10.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are not
+# supported properly for IE 6.0, but are supported on all modern browsers.
+#
+# Note that when changing this option you need to delete any form_*.png files in
+# the HTML output directory before the changes have effect.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+FORMULA_TRANSPARENT = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see
+# http://www.mathjax.org) which uses client side Javascript for the rendering
+# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX
+# installed or if you want to formulas look prettier in the HTML output. When
+# enabled you may also need to install MathJax separately and configure the path
+# to it using the MATHJAX_RELPATH option.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+USE_MATHJAX = YES
+
+# When MathJax is enabled you can set the default output format to be used for
+# the MathJax output. See the MathJax site (see:
+# http://docs.mathjax.org/en/latest/output.html) for more details.
+# Possible values are: HTML-CSS (which is slower, but has the best
+# compatibility), NativeMML (i.e. MathML) and SVG.
+# The default value is: HTML-CSS.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_FORMAT = HTML-CSS
+
+# When MathJax is enabled you need to specify the location relative to the HTML
+# output directory using the MATHJAX_RELPATH option. The destination directory
+# should contain the MathJax.js script. For instance, if the mathjax directory
+# is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
+# Content Delivery Network so you can quickly see the result without installing
+# MathJax. However, it is strongly recommended to install a local copy of
+# MathJax from http://www.mathjax.org before deployment.
+# The default value is: http://cdn.mathjax.org/mathjax/latest.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
+# extension names that should be enabled during MathJax rendering. For example
+# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_EXTENSIONS =
+
+# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
+# of code that will be used on startup of the MathJax code. See the MathJax site
+# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
+# example see the documentation.
+# This tag requires that the tag USE_MATHJAX is set to YES.
+
+MATHJAX_CODEFILE =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box for
+# the HTML output. The underlying search engine uses javascript and DHTML and
+# should work on any modern browser. Note that when using HTML help
+# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET)
+# there is already a search function so this one should typically be disabled.
+# For large projects the javascript based search engine can be slow, then
+# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to
+# search using the keyboard; to jump to the search box use + S
+# (what the is depends on the OS and browser, but it is typically
+# , /, or both). Inside the search box use the to jump into the search results window, the results can be navigated
+# using the . Press to select an item or to cancel
+# the search. The filter options can be selected when the cursor is inside the
+# search box by pressing +. Also here use the
+# to select a filter and or to activate or cancel the filter
+# option.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_HTML is set to YES.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a web server instead of a web client using Javascript. There
+# are two flavors of web server based searching depending on the EXTERNAL_SEARCH
+# setting. When disabled, doxygen will generate a PHP script for searching and
+# an index file used by the script. When EXTERNAL_SEARCH is enabled the indexing
+# and searching needs to be provided by external tools. See the section
+# "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SERVER_BASED_SEARCH = NO
+
+# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
+# script for searching. Instead the search results are written to an XML file
+# which needs to be processed by an external indexer. Doxygen will invoke an
+# external search engine pointed to by the SEARCHENGINE_URL option to obtain the
+# search results.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/).
+#
+# See the section "External Indexing and Searching" for details.
+# The default value is: NO.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH = NO
+
+# The SEARCHENGINE_URL should point to a search engine hosted by a web server
+# which will return the search results when EXTERNAL_SEARCH is enabled.
+#
+# Doxygen ships with an example indexer (doxyindexer) and search engine
+# (doxysearch.cgi) which are based on the open source search engine library
+# Xapian (see: http://xapian.org/). See the section "External Indexing and
+# Searching" for details.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHENGINE_URL =
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
+# search data is written to a file for indexing by an external tool. With the
+# SEARCHDATA_FILE tag the name of this file can be specified.
+# The default file is: searchdata.xml.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+SEARCHDATA_FILE = searchdata.xml
+
+# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the
+# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
+# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
+# projects and redirect the results back to the right project.
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTERNAL_SEARCH_ID =
+
+# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
+# projects other than the one defined by this configuration file, but that are
+# all added to the same external search index. Each project needs to have a
+# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id of
+# to a relative location where the documentation can be found. The format is:
+# EXTRA_SEARCH_MAPPINGS = tagname1=loc1 tagname2=loc2 ...
+# This tag requires that the tag SEARCHENGINE is set to YES.
+
+EXTRA_SEARCH_MAPPINGS =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
+# The default value is: YES.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked.
+#
+# Note that when enabling USE_PDFLATEX this option is only used for generating
+# bitmaps for formulas in the HTML output, but not in the Makefile that is
+# written to the output directory.
+# The default file is: latex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to generate
+# index for LaTeX.
+# The default file is: makeindex.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES, doxygen generates more compact LaTeX
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used by the
+# printer.
+# Possible values are: a4 (210 x 297 mm), letter (8.5 x 11 inches), legal (8.5 x
+# 14 inches) and executive (7.25 x 10.5 inches).
+# The default value is: a4.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PAPER_TYPE = a4
+
+# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
+# that should be included in the LaTeX output. To get the times font for
+# instance you can specify
+# EXTRA_PACKAGES=times
+# If left blank no extra packages will be included.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
+# generated LaTeX document. The header should contain everything until the first
+# chapter. If it is left blank doxygen will generate a standard header. See
+# section "Doxygen usage" for information on how to let doxygen write the
+# default header to a separate file.
+#
+# Note: Only use a user-defined header if you know what you are doing! The
+# following commands have a special meaning inside the header: $title,
+# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
+# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
+# string, for the replacement values of the other commands the user is referred
+# to HTML_HEADER.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HEADER =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
+# generated LaTeX document. The footer should contain everything after the last
+# chapter. If it is left blank doxygen will generate a standard footer. See
+# LATEX_HEADER for more information on how to generate a default footer and what
+# special commands can be used inside the footer.
+#
+# Note: Only use a user-defined footer if you know what you are doing!
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_FOOTER =
+
+# The LATEX_EXTRA_STYLESHEET tag can be used to specify additional user-defined
+# LaTeX style sheets that are included after the standard style sheets created
+# by doxygen. Using this option one can overrule certain style aspects. Doxygen
+# will copy the style sheet files to the output directory.
+# Note: The order of the extra style sheet files is of importance (e.g. the last
+# style sheet in the list overrules the setting of the previous ones in the
+# list).
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_STYLESHEET =
+
+# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the LATEX_OUTPUT output
+# directory. Note that the files will be copied as-is; there are no commands or
+# markers available.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_EXTRA_FILES =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated is
+# prepared for conversion to PDF (using ps2pdf or pdflatex). The PDF file will
+# contain links (just like the HTML output) instead of page references. This
+# makes the output suitable for online browsing using a PDF viewer.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
+# the PDF file directly from the LaTeX files. Set this option to YES, to get a
+# higher quality PDF documentation.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
+# command to the generated LaTeX files. This will instruct LaTeX to keep running
+# if errors occur, instead of asking the user for help. This option is also used
+# when generating formulas in HTML.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BATCHMODE = NO
+
+# If the LATEX_HIDE_INDICES tag is set to YES then doxygen will not include the
+# index chapters (such as File Index, Compound Index, etc.) in the output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_HIDE_INDICES = NO
+
+# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
+# code with syntax highlighting in the LaTeX output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_SOURCE_CODE = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. See
+# http://en.wikipedia.org/wiki/BibTeX and \cite for more info.
+# The default value is: plain.
+# This tag requires that the tag GENERATE_LATEX is set to YES.
+
+LATEX_BIB_STYLE = plain
+
+#---------------------------------------------------------------------------
+# Configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES, doxygen will generate RTF output. The
+# RTF output is optimized for Word 97 and may not look too pretty with other RTF
+# readers/editors.
+# The default value is: NO.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: rtf.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES, doxygen generates more compact RTF
+# documents. This may be useful for small projects and may help to save some
+# trees in general.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated will
+# contain hyperlink fields. The RTF file will contain links (just like the HTML
+# output) instead of page references. This makes the output suitable for online
+# browsing using Word or some other Word compatible readers that support those
+# fields.
+#
+# Note: WordPad (write) and others do not support links.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's config
+# file, i.e. a series of assignments. You only have to provide replacements,
+# missing definitions are set to their default value.
+#
+# See also section "Doxygen usage" for information on how to generate the
+# default style sheet that doxygen normally uses.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an RTF document. Syntax is
+# similar to doxygen's config file. A template extensions file can be generated
+# using doxygen -e rtf extensionFile.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_EXTENSIONS_FILE =
+
+# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
+# with syntax highlighting in the RTF output.
+#
+# Note that which sources are shown also depends on other settings such as
+# SOURCE_BROWSER.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_RTF is set to YES.
+
+RTF_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES, doxygen will generate man pages for
+# classes and files.
+# The default value is: NO.
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it. A directory man3 will be created inside the directory specified by
+# MAN_OUTPUT.
+# The default directory is: man.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to the generated
+# man pages. In case the manual section does not start with a number, the number
+# 3 is prepended. The dot (.) at the beginning of the MAN_EXTENSION tag is
+# optional.
+# The default value is: .3.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_EXTENSION = .3
+
+# The MAN_SUBDIR tag determines the name of the directory created within
+# MAN_OUTPUT in which the man pages are placed. If defaults to man followed by
+# MAN_EXTENSION with the initial . removed.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_SUBDIR =
+
+# If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
+# will generate one additional man file for each entity documented in the real
+# man page(s). These additional files only source the real man page, but without
+# them the man command would be unable to find the correct page.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_MAN is set to YES.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES, doxygen will generate an XML file that
+# captures the structure of the code including all documentation.
+# The default value is: NO.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put. If a
+# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of
+# it.
+# The default directory is: xml.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_OUTPUT = xml
+
+# If the XML_PROGRAMLISTING tag is set to YES, doxygen will dump the program
+# listings (including syntax highlighting and cross-referencing information) to
+# the XML output. Note that enabling this will significantly increase the size
+# of the XML output.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_XML is set to YES.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to the DOCBOOK output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_DOCBOOK tag is set to YES, doxygen will generate Docbook files
+# that can be used to generate PDF.
+# The default value is: NO.
+
+GENERATE_DOCBOOK = NO
+
+# The DOCBOOK_OUTPUT tag is used to specify where the Docbook pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in
+# front of it.
+# The default directory is: docbook.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_OUTPUT = docbook
+
+# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
+# program listings (including syntax highlighting and cross-referencing
+# information) to the DOCBOOK output. Note that enabling this will significantly
+# increase the size of the DOCBOOK output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
+
+DOCBOOK_PROGRAMLISTING = NO
+
+#---------------------------------------------------------------------------
+# Configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
+# AutoGen Definitions (see http://autogen.sf.net) file that captures the
+# structure of the code including all documentation. Note that this feature is
+# still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# Configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES, doxygen will generate a Perl module
+# file that captures the structure of the code including all documentation.
+#
+# Note that this feature is still experimental and incomplete at the moment.
+# The default value is: NO.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES, doxygen will generate the necessary
+# Makefile rules, Perl scripts and LaTeX code to be able to generate PDF and DVI
+# output from the Perl module output.
+# The default value is: NO.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES, the Perl module output will be nicely
+# formatted so it can be parsed by a human reader. This is useful if you want to
+# understand what is going on. On the other hand, if this tag is set to NO, the
+# size of the Perl module output will be much smaller and Perl will parse it
+# just the same.
+# The default value is: YES.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file are
+# prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. This is useful
+# so different doxyrules.make files included by the same Makefile don't
+# overwrite each other's variables.
+# This tag requires that the tag GENERATE_PERLMOD is set to YES.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES, doxygen will evaluate all
+# C-preprocessor directives found in the sources and include files.
+# The default value is: YES.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
+# in the source code. If set to NO, only conditional compilation will be
+# performed. Macro expansion can be done in a controlled way by setting
+# EXPAND_ONLY_PREDEF to YES.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
+# the macro expansion is limited to the macros specified with the PREDEFINED and
+# EXPAND_AS_DEFINED tags.
+# The default value is: NO.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES, the include files in the
+# INCLUDE_PATH will be searched if a #include is found.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by the
+# preprocessor.
+# This tag requires that the tag SEARCH_INCLUDES is set to YES.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will be
+# used.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that are
+# defined before the preprocessor is started (similar to the -D option of e.g.
+# gcc). The argument of the tag is a list of macros of the form: name or
+# name=definition (no spaces). If the definition and the "=" are omitted, "=1"
+# is assumed. To prevent a macro definition from being undefined via #undef or
+# recursively expanded use the := operator instead of the = operator.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
+# tag can be used to specify a list of macro names that should be expanded. The
+# macro definition that is found in the sources will be used. Use the PREDEFINED
+# tag if you want to use a different macro definition that overrules the
+# definition found in the source code.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES then doxygen's preprocessor will
+# remove all references to function-like macros that are alone on a line, have
+# an all uppercase name, and do not end with a semicolon. Such function macros
+# are typically used for boiler-plate code, and will confuse the parser if not
+# removed.
+# The default value is: YES.
+# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration options related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES tag can be used to specify one or more tag files. For each tag
+# file the location of the external documentation should be added. The format of
+# a tag file without this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where loc1 and loc2 can be relative or absolute paths or URLs. See the
+# section "Linking to external documentation" for more information about the use
+# of tag files.
+# Note: Each tag file must have a unique name (where the name does NOT include
+# the path). If a tag file is not located in the directory in which doxygen is
+# run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create a
+# tag file that is based on the input files it reads. See section "Linking to
+# external documentation" for more information about the usage of tag files.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
+# the class index. If set to NO, only the inherited external classes will be
+# listed.
+# The default value is: NO.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will be
+# listed.
+# The default value is: YES.
+
+EXTERNAL_GROUPS = YES
+
+# If the EXTERNAL_PAGES tag is set to YES, all external pages will be listed in
+# the related pages index. If set to NO, only the current project's pages will
+# be listed.
+# The default value is: YES.
+
+EXTERNAL_PAGES = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of 'which perl').
+# The default file (with absolute path) is: /usr/bin/perl.
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
+# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
+# NO turns the diagrams off. Note that this option also works with HAVE_DOT
+# disabled, but it is recommended to install and use dot, since it yields more
+# powerful graphs.
+# The default value is: YES.
+
+CLASS_DIAGRAMS = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see:
+# http://www.mcternan.me.uk/mscgen/)) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# You can include diagrams made with dia in doxygen documentation. Doxygen will
+# then run dia to produce the diagram and insert it in the documentation. The
+# DIA_PATH tag allows you to specify the directory where the dia binary resides.
+# If left empty dia is assumed to be found in the default search path.
+
+DIA_PATH =
+
+# If set to YES the inheritance and collaboration graphs will hide inheritance
+# and usage relations if the target is undocumented or is not a class.
+# The default value is: YES.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz (see:
+# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
+# Bell Labs. The other options in this section have no effect if this option is
+# set to NO
+# The default value is: YES.
+
+HAVE_DOT = YES
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is allowed
+# to run in parallel. When set to 0 doxygen will base this on the number of
+# processors available in the system. You can set it explicitly to a value
+# larger than 0 to get control over the balance between CPU load and processing
+# speed.
+# Minimum value: 0, maximum value: 32, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_NUM_THREADS = 0
+
+# When you want a differently looking font in the dot files that doxygen
+# generates you can specify the font name using DOT_FONTNAME. You need to make
+# sure dot is able to find the font, which can be done by putting it in a
+# standard location or by setting the DOTFONTPATH environment variable or by
+# setting DOT_FONTPATH to the directory containing the font.
+# The default value is: Helvetica.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTNAME = Ubuntu Mono
+
+# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
+# dot graphs.
+# Minimum value: 4, maximum value: 24, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the default font as specified with
+# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
+# the path where dot can find it using this tag.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
+# each documented class showing the direct and indirect inheritance relations.
+# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
+# graph for each documented class showing the direct and indirect implementation
+# dependencies (inheritance, containment, and class references variables) of the
+# class with other documented classes.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
+# groups, showing the direct groups dependencies.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES, doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LOOK = YES
+
+# If the UML_LOOK tag is enabled, the fields and methods are shown inside the
+# class node. If there are many fields or methods and many nodes the graph may
+# become too big to be useful. The UML_LIMIT_NUM_FIELDS threshold limits the
+# number of items for each type to make the size more manageable. Set this to 0
+# for no limit. Note that the threshold may be exceeded by 50% before the limit
+# is enforced. So when you set the threshold to 10, up to 15 fields may appear,
+# but if the number exceeds 15, the total amount of fields shown is limited to
+# 10.
+# Minimum value: 0, maximum value: 100, default value: 10.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+UML_LIMIT_NUM_FIELDS = 10
+
+# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
+# collaboration graphs will show the relations between templates and their
+# instances.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+TEMPLATE_RELATIONS = YES
+
+# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
+# YES then doxygen will generate a graph for each documented file showing the
+# direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDE_GRAPH = YES
+
+# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
+# set to YES then doxygen will generate a graph for each documented file showing
+# the direct and indirect include dependencies of the file with other documented
+# files.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH tag is set to YES then doxygen will generate a call
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable call graphs for selected
+# functions only using the \callgraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH tag is set to YES then doxygen will generate a caller
+# dependency graph for every global function or class method.
+#
+# Note that enabling this option will significantly increase the time of a run.
+# So in most cases it will be better to enable caller graphs for selected
+# functions only using the \callergraph command.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY tag is set to YES then doxygen will graphical
+# hierarchy of all classes instead of a textual one.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
+# dependencies a directory has on other directories in a graphical way. The
+# dependency relations are determined by the #include relations between the
+# files in the directories.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot.
+# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
+# to make the SVG files visible in IE 9+ (other browsers do not have this
+# requirement).
+# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
+# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
+# gif:cairo:gd, gif:gd, gif:gd:gd and svg.
+# The default value is: png.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_IMAGE_FORMAT = svg
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+#
+# Note that this requires a modern browser other than Internet Explorer. Tested
+# and working are Firefox, Chrome, Safari, and Opera.
+# Note: For IE 9+ you need to set HTML_FILE_EXTENSION to xhtml in order to make
+# the SVG files visible. Older versions of IE do not have SVG support.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+INTERACTIVE_SVG = YES
+
+# The DOT_PATH tag can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the \dotfile
+# command).
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOTFILE_DIRS =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the \mscfile
+# command).
+
+MSCFILE_DIRS =
+
+# The DIAFILE_DIRS tag can be used to specify one or more directories that
+# contain dia files that are included in the documentation (see the \diafile
+# command).
+
+DIAFILE_DIRS =
+
+# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
+# path where java can find the plantuml.jar file. If left blank, it is assumed
+# PlantUML is not used or called during a preprocessing step. Doxygen will
+# generate a warning when it encounters a \startuml command in this case and
+# will not generate output for the diagram.
+
+PLANTUML_JAR_PATH =
+
+# When using plantuml, the specified paths are searched for files specified by
+# the !include statement in a plantuml block.
+
+PLANTUML_INCLUDE_PATH =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of nodes
+# that will be shown in the graph. If the number of nodes in a graph becomes
+# larger than this value, doxygen will truncate the graph, which is visualized
+# by representing a node as a red box. Note that doxygen if the number of direct
+# children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note that
+# the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+# Minimum value: 0, maximum value: 10000, default value: 50.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the graphs
+# generated by dot. A depth value of 3 means that only nodes reachable from the
+# root by following a path via at most 3 edges will be shown. Nodes that lay
+# further from the root node will be omitted. Note that setting this option to 1
+# or 2 may greatly reduce the computation time needed for large code bases. Also
+# note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+# Minimum value: 0, maximum value: 1000, default value: 0.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not seem
+# to support this out of the box.
+#
+# Warning: Depending on the platform used, enabling this option may lead to
+# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
+# read).
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10) support
+# this, this feature is disabled by default.
+# The default value is: NO.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
+# explaining the meaning of the various boxes and arrows in the dot generated
+# graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
+# files that are used to generate the various graphs.
+# The default value is: YES.
+# This tag requires that the tag HAVE_DOT is set to YES.
+
+DOT_CLEANUP = YES
diff --git a/docs/source/doxygen/doxy.rst b/docs/source/doxygen/doxy.rst
new file mode 100644
index 0000000000..8d271e7f43
--- /dev/null
+++ b/docs/source/doxygen/doxy.rst
@@ -0,0 +1,7 @@
+Doxygen
+-------
+
+Here you can find all the references necessary for MOOSE.
+
+`Click here <../../../source/doxygen/cpp/html/index.html>`_
+
diff --git a/docs/source/images/MOOSE_MPI_threading.gif b/docs/source/images/MOOSE_MPI_threading.gif
new file mode 100644
index 0000000000..885806f0b0
Binary files /dev/null and b/docs/source/images/MOOSE_MPI_threading.gif differ
diff --git a/docs/source/images/MOOSE_threading.gif b/docs/source/images/MOOSE_threading.gif
new file mode 100644
index 0000000000..e92b7ab8f9
Binary files /dev/null and b/docs/source/images/MOOSE_threading.gif differ
diff --git a/docs/source/images/neuronalcompartment.jpg b/docs/source/images/neuronalcompartment.jpg
new file mode 100644
index 0000000000..6dd6702346
Binary files /dev/null and b/docs/source/images/neuronalcompartment.jpg differ
diff --git a/docs/source/images/neuroncompartment.fig b/docs/source/images/neuroncompartment.fig
new file mode 100644
index 0000000000..fa7e32a22b
--- /dev/null
+++ b/docs/source/images/neuroncompartment.fig
@@ -0,0 +1,369 @@
+#FIG 3.2 Produced by xfig version 3.2.5b
+Portrait
+Center
+Metric
+A4
+200.00
+Single
+-2
+1200 2
+6 3465 3285 7155 5085
+6 3465 3285 7155 5085
+6 5805 3645 6165 4770
+6 5805 3671 6165 4770
+6 5805 4320 6165 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5805 4500 6165 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5895 4590 6075 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5985 4500 5985 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5985 4590 5985 4770
+-6
+# Resistor
+6 5880 3671 6060 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 5985 3686 5985 3824 5914 3847 6057 3893 5914 3939 6057 3984
+ 5914 4030 6057 4076 5914 4122 6057 4167 5985 4190 5985 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 5850 4230 6120 3735
+-6
+6 5040 3645 5400 4770
+# Resistor
+6 5115 3671 5295 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 5220 3686 5220 3824 5149 3847 5292 3893 5149 3939 5292 3984
+ 5149 4030 5292 4076 5149 4122 5292 4167 5220 4190 5220 4329
+-6
+6 5040 4320 5400 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5400 4590 5040 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5310 4500 5130 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5220 4590 5220 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5220 4500 5220 4320
+-6
+-6
+# Resistor
+6 3493 3585 4168 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 4153 3690 4015 3690 3992 3619 3946 3762 3900 3619 3855 3762
+ 3809 3619 3763 3762 3717 3619 3672 3762 3649 3690 3510 3690
+-6
+# Resistor
+6 6464 3585 7139 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 7124 3690 6986 3690 6963 3619 6917 3762 6871 3619 6826 3762
+ 6780 3619 6734 3762 6688 3619 6643 3762 6620 3690 6481 3690
+-6
+# Non-polar capacitor
+6 4237 3782 4745 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4269 4146 4730 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4500 3800 4500 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4500 4261 4500 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 4269 4261 4730 4261
+-6
+# Ground
+6 5265 4725 5580 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5409 4761 5409 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5266 4903 5551 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5337 4975 5480 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 5380 5046 5451 5046
+-6
+6 4435 3642 4570 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4498 3689 28 28 4498 3689 4526 3689
+-6
+6 5156 3642 5291 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5219 3689 28 28 5219 3689 5247 3689
+-6
+6 5921 3642 6056 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5984 3689 28 28 5984 3689 6012 3689
+-6
+6 5344 4723 5479 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5407 4770 28 28 5407 4770 5435 4770
+-6
+6 4798 3374 4933 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 4858 3461 47 47 4858 3461 4906 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4140 3690 6480 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 3825 4500 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 4590 4500 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 4770 5985 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4860 3510 4860 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 5355 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 5355 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 6165 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 6165 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 4635 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 4955 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 3664 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 6637 3987 Ra/2\001
+-6
+6 5158 4724 5293 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5221 4771 28 28 5221 4771 5249 4771
+-6
+6 4798 3641 4933 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4861 3688 28 28 4861 3688 4889 3688
+-6
+-6
+6 -360 3285 3330 5085
+6 -360 3285 3330 5085
+6 1980 3645 2340 4770
+6 1980 3671 2340 4770
+6 1980 4320 2340 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1980 4500 2340 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2070 4590 2250 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2160 4500 2160 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2160 4590 2160 4770
+-6
+# Resistor
+6 2055 3671 2235 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 2160 3686 2160 3824 2089 3847 2232 3893 2089 3939 2232 3984
+ 2089 4030 2232 4076 2089 4122 2232 4167 2160 4190 2160 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 2025 4230 2295 3735
+-6
+6 1215 3645 1575 4770
+# Resistor
+6 1290 3671 1470 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 1395 3686 1395 3824 1324 3847 1467 3893 1324 3939 1467 3984
+ 1324 4030 1467 4076 1324 4122 1467 4167 1395 4190 1395 4329
+-6
+6 1215 4320 1575 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1575 4590 1215 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1485 4500 1305 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1395 4590 1395 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1395 4500 1395 4320
+-6
+-6
+# Resistor
+6 -332 3585 343 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 328 3690 190 3690 167 3619 121 3762 75 3619 30 3762
+ -16 3619 -62 3762 -108 3619 -153 3762 -176 3690 -315 3690
+-6
+# Resistor
+6 2639 3585 3314 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 3299 3690 3161 3690 3138 3619 3092 3762 3046 3619 3001 3762
+ 2955 3619 2909 3762 2863 3619 2818 3762 2795 3690 2656 3690
+-6
+# Non-polar capacitor
+6 412 3782 920 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 444 4146 905 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 675 3800 675 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 675 4261 675 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 444 4261 905 4261
+-6
+# Ground
+6 1440 4725 1755 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1584 4761 1584 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1441 4903 1726 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1512 4975 1655 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 1555 5046 1626 5046
+-6
+6 610 3642 745 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 673 3689 28 28 673 3689 701 3689
+-6
+6 1331 3642 1466 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1394 3689 28 28 1394 3689 1422 3689
+-6
+6 2096 3642 2231 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 2159 3689 28 28 2159 3689 2187 3689
+-6
+6 1519 4723 1654 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1582 4770 28 28 1582 4770 1610 4770
+-6
+6 973 3374 1108 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 1033 3461 47 47 1033 3461 1081 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 315 3690 2655 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 3825 675 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 4590 675 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 4770 2160 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1035 3510 1035 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 1530 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 1530 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 2340 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 2340 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 810 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 1130 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 -161 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 2812 3987 Ra/2\001
+-6
+6 1333 4724 1468 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1396 4771 28 28 1396 4771 1424 4771
+-6
+6 973 3641 1108 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1036 3688 28 28 1036 3688 1064 3688
+-6
+-6
+6 7290 3285 10980 5085
+6 7290 3285 10980 5085
+6 9630 3645 9990 4770
+6 9630 3671 9990 4770
+6 9630 4320 9990 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9630 4500 9990 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9720 4590 9900 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9810 4500 9810 4320
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9810 4590 9810 4770
+-6
+# Resistor
+6 9705 3671 9885 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 9810 3686 9810 3824 9739 3847 9882 3893 9739 3939 9882 3984
+ 9739 4030 9882 4076 9739 4122 9882 4167 9810 4190 9810 4329
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 9675 4230 9945 3735
+-6
+6 8865 3645 9225 4770
+# Resistor
+6 8940 3671 9120 4346
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 9045 3686 9045 3824 8974 3847 9117 3893 8974 3939 9117 3984
+ 8974 4030 9117 4076 8974 4122 9117 4167 9045 4190 9045 4329
+-6
+6 8865 4320 9225 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9225 4590 8865 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9135 4500 8955 4500
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9045 4590 9045 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9045 4500 9045 4320
+-6
+-6
+# Resistor
+6 7318 3585 7993 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 7978 3690 7840 3690 7817 3619 7771 3762 7725 3619 7680 3762
+ 7634 3619 7588 3762 7542 3619 7497 3762 7474 3690 7335 3690
+-6
+# Resistor
+6 10289 3585 10964 3765
+2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 12
+ 10949 3690 10811 3690 10788 3619 10742 3762 10696 3619 10651 3762
+ 10605 3619 10559 3762 10513 3619 10468 3762 10445 3690 10306 3690
+-6
+# Non-polar capacitor
+6 8062 3782 8570 4652
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8094 4146 8555 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8325 3800 8325 4146
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8325 4261 8325 4605
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 8094 4261 8555 4261
+-6
+# Ground
+6 9090 4725 9405 5085
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9234 4761 9234 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9091 4903 9376 4903
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9162 4975 9305 4975
+2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2
+ 9205 5046 9276 5046
+-6
+6 8260 3642 8395 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 8323 3689 28 28 8323 3689 8351 3689
+-6
+6 8981 3642 9116 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9044 3689 28 28 9044 3689 9072 3689
+-6
+6 9746 3642 9881 3732
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9809 3689 28 28 9809 3689 9837 3689
+-6
+6 9169 4723 9304 4813
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9232 4770 28 28 9232 4770 9260 4770
+-6
+6 8623 3374 8758 3509
+1 3 0 1 0 7 1 0 20 0.000 1 0.0000 8683 3461 47 47 8683 3461 8731 3461
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 7965 3690 10305 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 3825 8325 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 4590 8325 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8325 4770 9810 4770
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 8685 3510 8685 3690
+4 0 0 50 -1 0 12 0.0000 4 150 300 9180 4500 Em\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 9180 4050 Rm\001
+4 0 0 50 -1 0 12 0.0000 4 150 270 9990 4050 Gk\001
+4 0 0 50 -1 0 12 0.0000 4 150 240 9990 4590 Ek\001
+4 0 0 50 -1 0 12 0.0000 4 150 315 8460 4500 Cm\001
+4 0 0 50 -1 0 12 0.0000 4 150 300 8780 3452 Vm\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 7489 3978 Ra/2\001
+4 0 0 50 -1 0 12 0.0000 4 180 405 10462 3987 Ra/2\001
+-6
+6 8983 4724 9118 4814
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 9046 4771 28 28 9046 4771 9074 4771
+-6
+6 8623 3641 8758 3731
+1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 8686 3688 28 28 8686 3688 8714 3688
+-6
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 3285 3690 3510 3690
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 7110 3690 7335 3690
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3420 3240 7245 3240 7245 5130 3420 5130 3420 3240
diff --git a/docs/source/images/propBis.gif b/docs/source/images/propBis.gif
new file mode 100644
index 0000000000..b500a387f0
Binary files /dev/null and b/docs/source/images/propBis.gif differ
diff --git a/docs/source/index.rst b/docs/source/index.rst
new file mode 100644
index 0000000000..1f5c7c4e62
--- /dev/null
+++ b/docs/source/index.rst
@@ -0,0 +1,33 @@
+.. MOOSE documentation master file, created by
+ sphinx-quickstart on Tue Jan 31 14:57:39 2017.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+.. toctree::
+ :maxdepth: 2
+
+ /introduction/index_introduction
+ /install/index_install
+ /user/py/quickstart/index_qs
+ /user/py/cookbook/index_ckbk
+ /user/py/rdesigneur/index_rd
+ /user/py/tutorials/index_tut
+ /user/py/graphics/index_graphics
+ /user/py/references/index_ref
+ /doxygen/doxy
+
+.. toctree::
+ :maxdepth: 1
+ :titlesonly:
+
+.. toctree::
+
+ release_notes/index
+ changes/index
+ known_issues/index
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
diff --git a/docs/source/install/index_install.rst b/docs/source/install/index_install.rst
new file mode 100644
index 0000000000..4f35fcae50
--- /dev/null
+++ b/docs/source/install/index_install.rst
@@ -0,0 +1,7 @@
+Installation
+=============
+
+.. toctree::
+ :maxdepth: 1
+
+ install
diff --git a/docs/source/install/install.rst b/docs/source/install/install.rst
new file mode 100644
index 0000000000..cd0fe1f6e0
--- /dev/null
+++ b/docs/source/install/install.rst
@@ -0,0 +1,268 @@
+Use pre-built packages
+-----------------------
+
+pip
+^^^^
+
+If you only need `python` interface, the recommended way is via `pip`.
+::
+ pip install pymoose --user
+
+To install nightly version
+::
+ pip install pymoose --pre --upgrade --user
+
+
+We also have moose package with additional components such as gui and `moogli`.
+
+Linux
+^^^^^^
+
+We recommend that you use our repositories hosted at `Open Build Service
+`_. Packages for most
+linux distributions are available. Visit `this page
+`_
+to pick your distribution and follow instructions.
+
+.. note::
+ ``moogli`` (tool to visualize network activity) is not available for CentOS-6.
+
+.. todo:: Packages for gentoo
+
+Mac OSX
+^^^^^^^^
+
+MacOSX support for moose-gui is not complete yet because moose-gui depends on PyQt4 but that
+world has moved onto PyQt5 (See the status here: https://github.com/BhallaLab/moose-gui/issues/16).
+However, the python-scripting interface can be installed on OSX using ``homebrew``
+::
+ $ brew tap BhallaLab/moose
+ $ brew install moose
+
+Or alternatively, via pip
+::
+ $ pip install pymoose --user
+
+
+Docker Images
+^^^^^^^^^^^^^^
+
+Docker images of stable version are available from public repository.
+::
+ $ docker pull bhallalab/moose
+ $ docker run -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$DISPLAY bhallalab/moose
+
+This will launch `xterm`; run `moosegui` in terminal to lauch the GUI.
+
+
+Building MOOSE
+--------------
+
+In case your distribution is not listed on `our repository page
+`_
+, or if you want to build the latest development code, read on.
+
+First, you need to get the source code. You can use ``git`` (clone the
+repository) or download snapshot of github repo by clicking on `this link
+`__.
+::
+
+ $ git clone https://github.com/BhallaLab/moose
+
+(This will create folder called "moose")
+Or,
+::
+
+ $ wget https://github.com/BhallaLab/moose/archive/master.zip
+ $ unzip master.zip
+
+If you don't want latest snapshot of ``MOOSE``, you can download other released
+versions from `here `__.
+
+Install dependencies
+^^^^^^^^^^^^^^^^^^^^
+
+Next, you need to install required dependencies. Depending on your OS, names of
+following packages may vary.
+
+Core MOOSE
+""""""""""
+- Required:
+ - cmake (version 2.8 or higher)
+ - g++ or clang (with `c++11` support).
+ - gsl-1.16 or higher.
+
+- Optional
+ - HDF5 (>=1.8.x) For reading and writing data into HDF5 based formats. Disabled by default.
+
+Python interface for core MOOSE API (pymoose)
+"""""""""""""""""""""""""""""""""""""""""""""
+- Required
+ - python (Both 2.7 and 3.x versions are supported).
+ - python-dev. Python development headers and libraries, e.g. `python-dev` or `python-devel`
+ - NumPy ( >= 1.6.x) For array interface, e.g. `python-numpy` or `numpy`
+
+- Optional
+ - networkx (>=1.x) For automatical layout
+ - pygraphviz. For automatic layout for chemical models
+ - matplotlib (>=2.x). For plotting simulation results
+ - python-libsbml. For reading and writing chemical models from and into SBML format
+ - pylibsbml
+
+All of these dependencies can be installed using `pip` or your package manager.
+
+On ``Debian/Ubuntu``
+::
+
+ $ sudo apt-get install libhdf5-dev cmake libgsl0-dev libpython-dev python-numpy
+
+
+On ``CentOS/Fedora/RHEL/Scientific Linux``
+::
+
+ $ sudo yum install hdf5-devel cmake libgsl-dev python-devel python-numpy
+
+On ``OpenSUSE``
+::
+
+ $ sudo zypper install hdf5-devel cmake libgsl-dev python-devel python-numpy
+
+Build moose
+^^^^^^^^^^^
+
+.. code-block:: bash
+
+ $ cd /to/moose_directory/moose-core/
+ $ mkdir _build
+ $ cd _build
+ $ cmake ..
+ $ make
+ $ ctest --output-on-failure # optional
+ $ sudo make install
+
+This will build pyMOOSE (MOOSE's python extention), `ctest` will run few tests to
+check if build process was successful.
+
+.. note::
+
+ To install MOOSE into non-standard directory, pass additional argument
+ `-DCMAKE_INSTALL_PREFIX=path/to/install/dir` to cmake
+ ::
+
+ $ cmake -DCMAKE_INSTALL_PREFIC=$HOME/.local ..
+
+ To use different version of python
+ ::
+
+ $ cmake -DPYTHON_EXECUTABLE=/opt/python3/bin/python3 ..
+
+After that installation is pretty easy
+::
+
+ $ sudo make install
+
+If everything went fine, you should be able to import moose in python shell.
+
+.. code-block:: python
+
+ >>> import moose
+
+Graphical User Interface (GUI)
+------------------------------
+
+If you have installed the pre-built package, then you already have the GUI.
+You can launch it by runnung `moosegui` command in terminal.
+
+You can get the source of ``moose-gui`` from `here
+`__. You can download it either by
+clicking on `this link `__
+or by using ``git`` ::
+
+ $ git clone https://github.com/BhallaLab/moose-gui
+
+
+Alternatively the moose-gui folder exists within the moose folder downloaded and built earlier in the installation process. It can be found under ``location_of_moose_folder/moose/moose-gui/``.
+
+Below are packages which you may want to install to use MOOSE Graphical User Interface.
+
+- Required:
+ - PyQt4 (4.8.x). For Python GUI
+ - Matplotlib ( >= 2.x). For plotting simulation results
+ - NetworkX (1.x). For automatical layout
+
+- Optional:
+ - python-libsbml. For reading and writing signalling models from and into SBML format
+
+On ``Ubuntu/Debian``, these can be installed with
+::
+
+ $ sudo apt-get install python-matplotlib python-qt4
+
+On ``CentOS/Fedora/RHEL``
+::
+
+ $ sudo yum install python-matplotlib python-qt4
+
+Now you can fire up the GUI
+::
+
+ $ cd /to/moose-gui
+ $ python mgui.py
+
+.. note::
+
+ If you have installed ``moose`` package, then GUI is launched by
+ running following commnad::
+
+ $ moosegui
+
+Building moogli
+---------------
+
+``moogli`` is subproject of ``MOOSE`` for visualizing models. More details can
+be found `here `__.
+
+`Moogli` is part of `moose` package. Building moogli can be tricky because of
+multiple depednecies it has.
+
+- Required
+ - OSG (3.2.x) For 3D rendering and simulation of neuronal models
+ - Qt4 (4.8.x) For C++ GUI of Moogli
+
+To get the latest source code of ``moogli``, click on `this link `__.
+
+Moogli depends on ``OpenSceneGraph`` (version 3.2.0 or higher) which may not
+be easily available for your operating system.
+For this reason, we distribute required ``OpenSceneGraph`` with ``moogli``
+source code.
+
+Depending on distribution of your operating system, you would need following
+packages to be installed.
+
+On ``Ubuntu/Debian``
+::
+
+ $ sudo apt-get install python-qt4-dev python-qt4-gl python-sip-dev libqt4-dev
+
+On ``Fedora/CentOS/RHEL``
+::
+
+ $ sudo yum install sip-devel PyQt4-devel qt4-devel libjpeg-devel PyQt4
+
+On ``openSUSE``
+::
+
+ $ sudo zypper install python-sip python-qt4-devel libqt4-devel python-qt4
+
+After this, building and installing ``moogli`` should be as simple as
+::
+
+ $ cd /path/to/moogli
+ $ mkdir _build
+ $ cd _build
+ $ cmake ..
+ $ make -j3
+ $ sudo make install
+
+If you run into troubles, please report it on our `github repository
+`_.
diff --git a/docs/source/introduction/index_introduction.rst b/docs/source/introduction/index_introduction.rst
new file mode 100644
index 0000000000..79dae614e2
--- /dev/null
+++ b/docs/source/introduction/index_introduction.rst
@@ -0,0 +1,7 @@
+Introduction
+============
+
+.. toctree::
+ :maxdepth: 1
+
+ introduction
diff --git a/docs/source/introduction/introduction.rst b/docs/source/introduction/introduction.rst
new file mode 100644
index 0000000000..cbb554a17b
--- /dev/null
+++ b/docs/source/introduction/introduction.rst
@@ -0,0 +1,35 @@
+What is MOOSE and what is it good for?
+-------------------------------------
+
+MOOSE is the **Multiscale Object-Oriented Simulation Environment**. It is
+designed to simulate neural systems ranging from subcellular components and
+biochemical reactions to complex models of single neurons, circuits, and large
+networks. MOOSE can operate at many levels of detail, from stochastic chemical
+computations, to multicompartment single-neuron models, to spiking neuron
+network models.
+
+.. figure:: ../images/Gallery_Moose_Multiscale.png
+ :scale: 75%
+ :alt: **multiple scales in moose**
+
+ *Multiple scales can be modelled and simulated in MOOSE*
+
+MOOSE is multiscale: It can do all these calculations together. One of its major
+uses is to make biologically detailed models that combine electrical and
+chemical signaling.
+
+MOOSE is object-oriented. Biological concepts are mapped into classes, and a
+model is built by creating instances of these classes and connecting them by
+messages. MOOSE also has numerical classes whose job is to take over difficult
+computations in a certain domain, and do them fast. There are such solver
+classes for stochastic and deterministic chemistry, for diffusion, and for
+multicompartment neuronal models.
+
+MOOSE is a simulation environment, not just a numerical engine: It provides data
+representations and solvers (of course!), but also a scripting interface with
+Python, graphical displays with Matplotlib, PyQt, and OpenGL, and support for
+many model formats. These include SBML, NeuroML, GENESIS kkit and cell.p
+formats, HDF5 and NSDF for data writing.
+
+.. toctree::
+ :maxdepth: 1
diff --git a/docs/source/known_issues/index.rst b/docs/source/known_issues/index.rst
new file mode 100644
index 0000000000..74f66887ab
--- /dev/null
+++ b/docs/source/known_issues/index.rst
@@ -0,0 +1,9 @@
+Known issues
+============
+
+Full report can be found at the following places
+
+- Related to `build, packages and documentation `_
+- Related to `moose-core `_
+- Related to `MOOSE-GUI `_
+- Related to `moogli `_
diff --git a/docs/source/release_notes/index.rst b/docs/source/release_notes/index.rst
new file mode 100644
index 0000000000..6dccd2d97b
--- /dev/null
+++ b/docs/source/release_notes/index.rst
@@ -0,0 +1,6 @@
+Release Notes
+=============
+
+.. todo::
+
+ Collect release notes from github.
diff --git a/docs/source/user/py/cookbook/chem.rst b/docs/source/user/py/cookbook/chem.rst
new file mode 100644
index 0000000000..3f9571344b
--- /dev/null
+++ b/docs/source/user/py/cookbook/chem.rst
@@ -0,0 +1,11 @@
+****************
+Chemical Aspects
+****************
+
+.. toctree::
+ :maxdepth: 2
+
+ chem_GUI
+ chem_load_save
+ chem_sim_eg
+ chem_tut
diff --git a/docs/source/user/py/cookbook/chem_GUI.rst b/docs/source/user/py/cookbook/chem_GUI.rst
new file mode 100644
index 0000000000..543f48c6b3
--- /dev/null
+++ b/docs/source/user/py/cookbook/chem_GUI.rst
@@ -0,0 +1,407 @@
+*************************************************
+Interface for chemical kinetic models in MOOSEGUI
+*************************************************
+
+
+Upinder Bhalla, Harsha Rani
+
+Nov 8 2016.
+
+--------------
+
+- `Introduction <#introduction>`__
+
+- `**TODO** What are chemical kinetic
+ models? <#todo-what-are-chemical-kinetic-models>`__
+
+ - `Levels of model <#levels-of-model>`__
+ - `Numerical methods <#numerical-methods>`__
+
+- `Using Kinetikit 12 <#using-kinetikit-12>`__
+
+ - `Overview <#overview>`__
+ - `Model layout and icons <#model-layout-and-icons>`__
+
+ - `Compartment <#compartment>`__
+ - `Pool <#pool>`__
+ - `Buffered pools <#buffered-pools>`__
+ - `Reaction <#reaction>`__
+ - `Mass-action enzymes <#mass-action-enzymes>`__
+ - `Michaelis-Menten Enzymes <#michaelis-menten-enzymes>`__
+ - `Summation <#summation>`__
+
+ - `Model operations <#model-operations>`__
+ - `Model Building <#model-building>`__
+
+`Introduction <#TOC>`__
+-----------------------
+
+Kinetikit 12 is a graphical interface for doing chemical kinetic modeling in MOOSE. It is derived in part from Kinetikit, which was the
+graphical interface used in GENESIS for similar models. Kinetikit, also known as kkit, was at version 11 with GENESIS. Here we start with
+Kinetikit 12.
+
+`**TODO** What are chemical kinetic models? <#TOC>`__
+-----------------------------------------------------
+
+Much of neuronal computation occurs through chemical signaling. For
+example, many forms of synaptic plasticity begin with calcium influx
+into the synapse, followed by calcium binding to calmodulin, and then
+calmodulin activation of numerous enzymes. These events can be
+represented in chemical terms:
+
+ 4 Ca\ :sup:`2+`\ + CaM <===> Ca\ :sub:`4`\.CaM
+
+Such chemical equations can be modeled through standard Ordinary
+Differential Equations, if we ignore space::
+
+ d[Ca]/dt = −4Kf ∗ [Ca]4 ∗ [CaM] + 4Kb ∗ [Ca4.CaM] d[CaM]/dt = −Kf ∗ [Ca]4 ∗ [CaM] + Kb ∗ [Ca4.CaM] d[Ca4.CaM]/dt = Kf ∗ [Ca]4 ∗ [CaM] − Kb ∗ [Ca4.CaM]
+
+MOOSE models these chemical systems. This help document describes how to do such modelling using the graphical interface, Kinetikit 12.
+
+`Levels of model <#TOC>`__
+--------------------------
+
+Chemical kinetic models can be simple well-stirred (or point) models, or
+they could have multiple interacting compartments, or they could include
+space explicitly using reaction-diffusion. In addition such models could
+be solved either deterministically, or using a stochastic formulation.
+At present Kinetikit handles compartmental models but does not compute
+diffusion within the compartments, though MOOSE itself can do this at
+the script level. Kkit12 will do deterministic as well as stochastic
+chemical calculations.
+
+`Numerical methods <#TOC>`__
+----------------------------
+
+- **Deterministic**: Adaptive timestep 5th order Runge-Kutta-Fehlberg from the GSL (GNU Scientific Library).
+- **Stochastic**: Optimized Gillespie Stochastic Systems Algorithm, custom implementation.
+
+`Using Kinetikit 12 <#TOC>`__
+-----------------------------
+
+`Overview <#TOC>`__
+^^^^^^^^^^^^^^^^^^^
+
+- Load models using **'File -> Load model'**. A reaction schematic for the chemical system appears in the **'Editor view'** tab.
+- From **'Editor view'** tab
+
+ - View parameters by clicking on icons, and looking at entries in **'Properties'** table to the right.
+ - Edit parameters by changing their values in the **'Properties'** table.
+
+- From **'Run View'**
+
+ - Pools can be plotted by clicking on their icons and dragging the icons onto the plot Window. Presently only concentration v/s time is plottable.
+ - Select simulation, diffusion dt's along updateInterval for plot and Gui with numerical method using options under **'Preferences'** button in simulation control.
+ - Run model using **'Run'** button.
+ - Save plots image using the icons at the top of the **'Plot Window'** or right click on plot to Export to csv.
+
+Most of these operations are detailed in other sections, and are shared
+with other aspects of the MOOSE simulation interface. Here we focus on
+the Kinetikit-specific items.
+
+`Model layout and icons <#TOC>`__
+---------------------------------
+
+When you are in the **'Editor View'** tab you will see a collection of
+icons, arrows, and grey boxes surrounding these. This is a schematic of
+the reaction scheme being modeled. You can view and change parameters,
+and change the layout of the model.
+
+.. figure:: ../../../images/Moose1.png
+ :alt:
+
+Resizing the model layout and icons:
+
+- **Zoom**: Comma and period keys. Alternatively, the mouse scroll wheel or vertical scroll line on the track pad will cause the display to zoom in and out.
+- **Pan**: The arrow keys move the display left, right, up, and down.
+- **Entire Model View**: Pressing the **'a'** key will fit the entire model into the entire field of view.
+- **Resize Icons**: Angle bracket keys, that is, **'<'** and **'>'** or **'+'** and **'-'**. This resizes the icons while leaving their positions on the screen layout more or less the same.
+- **Original Model View**: Pressing the **'A'** key (capital 'A') will revert to the original model view including the original icon scaling.
+
+`Compartment <#TOC>`__
+^^^^^^^^^^^^^^^^^^^^^^
+
+The *compartment* in moose is usually a contiguous domain in which a
+certain set of chemical reactions and molecular species occur. The
+definition is very closely related to that of a cell-biological
+compartment. Examples include the extracellular space, the cell
+membrane, the cytosol, and the nucleus. Compartments can be nested, but
+of course you cannot put a bigger compartment into a smaller one.
+
+- **Icon**: Grey boundary around a set of reactions.
+- **Moving Compartments**: Click and drag on the boundary.
+- **Resizing Compartment boundary**: Happens automatically when contents are repositioned, so that the boundary just contains contents.
+- **Compartment editable parameters**:
+
+ - **'name'**: The name of the compartment.
+ - **'size'**: This is the volume, surface area or length of the compartment, depending on its type.
+
+- **Compartment fixed parameters**:
+
+ - **'numDimensions'**: This specifies whether the compartment is a volume, a 2-D surface, or if it is just being represented as a length.
+
+`Pool <#TOC>`__
+^^^^^^^^^^^^^^^
+
+This is the set of molecules of a given species within a compartment.
+Different chemical states of the same molecule are in different pools.
+
+- **Icon**: |image0| Colored rectangle with pool name in it.
+- **Moving pools**: Click and drag.
+- **Pool editable parameters**:
+
+ - **name**: Name of the pool
+ - **n**: Number of molecules in the pool
+ - **nInit**: Initial number of molecules in the pool. 'n' gets set
+ to this value when the 'reinit' operation is done.
+ - **conc**: Concentration of the molecules in the pool.
+ ``conc = n * unit_scale_factor / (N_A * vol)``
+ - **concInit**: Initial concentration of the molecules in the pool.
+ 'conc' is set to this value when the 'reinit' operation is done.
+
+ ``concInit = nInit * unit_scale_factor / (N_A * vol)``
+
+- **Pool fixed parameters**
+
+ - **size**: Derived from the compartment that holds the pool.
+ Specifies volume, surface area or length of the holding
+ compartment.
+
+`Buffered pools <#TOC>`__
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some pools are set to a fixed 'n', that is number of molecules, and
+therefore a fixed concentration, throughout a simulation. These are
+buffered pools.
+
+- **Icon**: |image1| Colored rectangle with pool name in it.
+- **Moving Buffered pools**: Click and drag.
+- **Buffered Pool editable parameters**
+
+ - **name**: Name of the pool
+ - **nInit**: Fixed number of molecules in the pool. 'n' gets set to
+ this value throughout the run.
+ - **concInit**: Fixed concentration of the molecules in the pool.
+ 'conc' is set to this value throughout the run.
+
+ ``concInit = nInit * unit_scale_factor / (N_A * vol)``
+
+- **Pool fixed parameters**:
+
+ - **n**: Number of molecules in the pool. Derived from 'nInit'.
+ - **conc**: Concentration of molecules in the pool. Derived from
+ 'concInit'.
+ - **size**: Derived from the compartment that holds the pool.
+ Specifies volume, surface area or length of the holding
+ compar'tment.
+
+`Reaction <#TOC>`__
+^^^^^^^^^^^^^^^^^^^
+
+These are conversion reactions between sets of pools. They are
+reversible, but you can set either of the rates to zero to get
+irreversibility. In the illustration below, **'D'** and **'A'** are
+substrates, and **'B'** is the product of the reaction. This is
+indicated by the direction of the green arrow.
+
+.. figure:: ../../../images/KkitReaction.png
+ :alt:
+
+- **Icon**: |image2| Reversible reaction arrow.
+- **Moving Reactions**: Click and drag.
+- **Reaction editable parameters**:
+
+ - **Name** : Name of reaction
+ - **K**\ :sub:`f`\ : 'Forward rate' of reaction, in
+ 'concentration/time' units. This is the normal way to express and
+ manipulate the reaction rate.
+ - **k**\ :sub:`f`\ : Forward rate of reaction, in 'number/time'
+ units. This is used internally for computations, but is
+ volume-dependent and should not be used to manipulate the reaction
+ rate unless you really know what you are doing.
+ - **K**\ :sub:`b`\ : Backward rate' of reaction, in
+ 'concentration/time' units. This is the normal way to express and
+ manipulate the reaction rate.
+ - **k**\ :sub:`b`\ : Backward rate of reaction, in 'number/time'
+ units. This is used internally for computations, but is
+ volume-dependent and should not be used to manipulate the reaction
+ rate unless you really know what you are doing.
+
+- **Reaction fixed parameters**:
+
+ - **numSubstrates**: Number of substrates molecules.
+ - **numProducts**: Number of product molecules.
+
+`Mass-action enzymes <#TOC>`__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These are enzymes that model the chemical equation's
+
+ E + S <===> E.S -> E + P
+
+Note that the second reaction is irreversible. Note also that
+mass-action enzymes include a pool to represent the **'E.S'**
+(enzyme-substrate) complex. In the example below, the enzyme pool is
+named **'MassActionEnz'**, the substrate is **'C'**, and the product is
+**'E'**. The direction of the enzyme reaction is indicated by the red
+arrows.
+
+.. figure:: ../../../images/MassActionEnzReac.png
+ :alt:
+
+- **Icon**: |image3| Colored ellipse atop a small square. The ellipse represents the enzyme. The small square represents **'E.S'**, the enzyme-substrate complex. The ellipse icon has the same color as the enzyme pool **'E'**. It is connected to the enzyme pool **'E'** with a straight line of the same color.
+
+ The ellipse icon sits on a continuous, typically curved arrow in red,
+ from the substrate to the product.
+
+ A given enzyme pool can have any number of enzyme activities, since
+ the same enzyme might catalyze many reactions.
+
+- **Moving Enzymes**: Click and drag on the ellipse.
+- **Enzyme editable parameters**
+
+ - **name** : Name of enzyme.
+ - **K**\ :sub:`m` \ : Michaelis-Menten value for enzyme, in
+ 'concentration' units.
+ - **k**\ :sub:`cat` \ : Production rate of enzyme, in '1/time' units.
+ Equal to k\ :sub:`3`\, the rate of the second, irreversible
+ reaction.
+ - **k**\ :sub:`1` \ : Forward rate of the **E+S** reaction, in number and
+ '1/time' units. This is what is used in the internal calculations.
+ - **k**\ :sub:`2` \ : Backward rate of the **E+S** reaction, in '1/time' units.
+ Used in internal calculations.
+ - **k**\ :sub:`3` \ : Forward rate of the **E.S -> E + P** reaction, in
+ '1/time' units. Equivalent to k\ :sub:`cat`\. Used in internal
+ calculations.
+ - **ratio** : This is equal to k\ :sub:`2`\/k\ :sub:`3`\. Needed to
+ define the internal rates in terms of K\ :sub:`m` and
+ k\ :sub:`cat`\. I usually use a value of 4.
+
+- **Enzyme-substrate-complex editable parameters**: These are identica'l to those of any other pool.
+
+ - **name**: Name of the **E.S** complex. Defaults to \*\*\_cplx\*\*.
+ - **n**: Number of molecules in the pool
+ - **nInit**: Initial number of molecules in the complex. 'n' gets set to this value when the 'reinit' operation is done.
+ - **conc**: Concentration of the molecules in the pool.
+
+ ``conc = n * unit_scale_factor / (N_A * vol)``
+ - **concInit**: Initial concentration of the molecules in the pool.
+ 'conc' is set to this value when the 'reinit' operation is done.
+ ``concI'nit = nInit * unit_scale_factor / (N_A * vol)``
+
+- **Enzyme-substrate-complex fixed parameters**:
+
+ - **size**: Derived from the compartment that holds the pool.
+ Specifies volume, surface area or length of the holding
+ compartment. Note that the Enzyme-substrate-complex is assumed to
+ be in the same compartment as the enzyme molecule.
+
+`Michaelis-Menten Enzymes <#TOC>`__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These are enzymes that obey the Michaelis-Menten equation
+
+``V = V_max * [S] / ( K_m + [S] ) = k_cat * [Etot] * [S] / ( K_m + [S] )``
+where
+- V\ :sub:`max` is the maximum rate of the enzyme
+- [Etot] is the total amount of the enzyme
+- K\ :sub:`m` is the Michaelis-Menten constant
+- S is the substrate.
+
+Nominally these enzymes model the same chemical equation as the mass-action enzyme':
+
+``E + S <===> E.S -> E + P``
+
+but they make the assumption that the **E.S** is in a quasi-steady-state
+with **E** and **S**, and they also ignore sequestration of the enzyme
+into the complex. So there is no representation of the **E.S** complex.
+In the example below, the enzyme pool is named **MM\_Enz**, the
+substrate is **E**, and the product is **P**. The direction of the
+enzyme reaction is indicated by the red arrows.
+
+.. figure:: ../../../images/MM_EnzReac.png
+ :alt:
+
+- **Icon**: |image4| Colored ellipse. The ellipse represents the enzyme
+ The ellipse icon has the same color as the enzyme **'MM\_Enz'**. It
+ is connected to the enzyme pool **'MM\_Enz'** with a straight line of
+ the same color. The ellipse icon sits on a continuous, typically
+ curved arrow in red, from the substrate to the product. A given
+ enzyme pool can have any number of enzyme activities, since the same
+ enzyme might catalyze many reactions.
+- **Moving Enzymes**: Click and drag.
+- **Enzyme editable parameters**:
+
+ - **name**: Name of enzyme.
+ - **K**\ :sub:`m`\: Michaelis-Menten value for enzyme, in 'concentration'
+ units.
+ - **k**\ :sub:`cat`\: Production rate of enzyme, in '1/time' units. Equal to k\ :sub:`3`, the rate of the second, irreversible reaction.
+
+`Summation <#TOC>`__
+^^^^^^^^^^^^^^^^^^^^
+
+Summation object can be used to add specified variable values. The
+variables can be input from pool object.
+
+- **Icon**: This is **Σ** in the example image below. The input pools
+ **'A'** and **'B'** connect to the **Σ** with blue arrows. The
+ function ouput's to BuffPool |image5|
+
+`Model operations <#TOC>`__
+----------------------------
+
+- **Loading models**: **File -> Load Model -> select from dialog**.
+ This operation makes the previously loaded model disable and loads newly selected models in **'Model View'**.
+- **New**: **File -> New -> Model name**. This opens a empty widget for model building
+- **Saving models**: **File -> Save Model -> select from dialog**.
+- **Changing numerical methods**: **Preference->Chemical tab** item from Simulation Control. Currently supports:
+
+1. Runge Kutta: This is the Runge-Kutta-Fehlberg implementation from the GNU Scientific Library (GSL). It is a fifth order variable timestep explicit method. Works well for most reaction systems except if they have very stiff reactions.
+2. Gillespie: Optimized Gillespie stochastic systems algorithm, custom implementation. This uses variable timesteps internally. Note that it slows down with increasing numbers of molecules in each pool. It also slows down, but not so badly, if the number of reactions goes up.
+3. Exponential Euler:This methods computes the solution of partial and ordinary differential equations.
+
+`Model building <#TOC>`__
+-------------------------
+
+- The **Edit Widget** includes various menu options and model icons on
+ the top. Use the mouse buttton to click and drag icons from toolbar
+ to Edit Widget, two things will happen, **icon** will appear in the
+ editor widget and an **object editor** will pop up with lots of
+ parameters with respect to moose object.
+
+.. figure:: ../../../images/chemical_CS.png
+ :alt:
+
+**Rules**:
+::
+
+ * Compartment has to be created firstly(At present only single compartment model is allowed)
+ * Enzyme should be dropped on a pool as parent
+ * function should be dropped on buffPool for output
+
+**Note**:
+::
+
+ * Drag in pool and reaction on to the editor widget, now one can set up a reaction.
+ * Click on mooseObject one can find a little arrow on the top right corner of the object, drag from this little arrow to any object for connection. e.g pool to reaction and reaction to pool. Specific connection type gets specific colored arrow. e.g. Green color arrow for specifying connection between reactant and product for reaction.
+ * Clicking on the object one can rearrange object for clean layout.
+ * Second order reaction can also be done by repeating the connection over again
+ * Each connection can be deleted and using rubberband selection each moose object can be deleted
+
+- From **run widget**, pools are draggable to plot window for plotting.
+ (Currently **conc** is plotted as default field) Plots are
+ color-coded as per in model.
+
+.. figure:: ../../../images/Chemical_run.png
+ :alt:
+
+- Model can be run by clicking **start** button. One can stop button in
+ mid-stream and start up again without affectiong the calculations.
+ The reset button clears the simulation.
+
+.. |image0| image:: ../../../images/Pool.png
+.. |image1| image:: ../../../images/BufPool.png
+.. |image2| image:: ../../../images/KkitReacIcon.png
+.. |image3| image:: ../../../images/MassActionEnzIcon.png
+.. |image4| image:: ../../../images/MM_EnzIcon.png
+.. |image5| image:: ../../../images/func.png
diff --git a/docs/source/user/py/cookbook/chem_load_save.rst b/docs/source/user/py/cookbook/chem_load_save.rst
new file mode 100644
index 0000000000..d5dc9814d4
--- /dev/null
+++ b/docs/source/user/py/cookbook/chem_load_save.rst
@@ -0,0 +1,62 @@
+************************
+Load - Run - Save models
+************************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+
+Load a Kinetic Model
+--------------------
+
+.. automodule:: loadKineticModel
+ :members:
+
+Load an SBML Model
+-------------------
+
+.. automodule:: loadSbmlmodel
+ :members:
+
+Load a CSpace Model
+-------------------
+
+.. automodule:: loadCspaceModel
+ :members:
+
+Save a model into SBML format
+-----------------------------
+
+.. automodule:: convert_Genesis2Sbml
+ :members:
+
+Save a model
+------------
+
+.. automodule:: savemodel
+ :members:
diff --git a/docs/source/user/py/cookbook/chem_sim_eg.rst b/docs/source/user/py/cookbook/chem_sim_eg.rst
new file mode 100644
index 0000000000..c06304a8f3
--- /dev/null
+++ b/docs/source/user/py/cookbook/chem_sim_eg.rst
@@ -0,0 +1,304 @@
+***************
+Simple Examples
+***************
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Set-up a kinetic solver and model
+---------------------------------
+
+with Scripting
+^^^^^^^^^^^^^^
+
+.. automodule:: scriptGssaSolver
+ :members:
+
+With something else
+^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: changeFuncExpression
+ :members:
+
+Building a chemical Model from Parts
+------------------------------------
+
+Disclaimer: Avoid doing this for all but the very simplest models. This
+is error-prone, tedious, and non-portable. For preference use one of the
+standard model formats like SBML, which MOOSE and many other tools can
+read and write.
+
+Nevertheless, it is useful to see how these models are set up.
+There are several tutorials and snippets that build the entire chemical
+model system using the basic MOOSE calls. The sequence of steps is
+typically:
+
+ #. Create container (chemical compartment) for model. This is typically
+ a CubeMesh, a CylMesh, and if you really know what you are doing,
+ a NeuroMesh.
+ #. Create the reaction components: pools of molecules **moose.Pool**;
+ reactions **moose.Reac**; and enzymes **moose.Enz**. Note that when
+ creating an enzyme, one must also create a molecule beneath it to
+ serve as the enzyme-substrate complex. Other less-used
+ components include Michaelis-Menten enzymes **moose.MMenz**, input
+ tables, pulse generators and so on. These are illustrated in other
+ examples. All these reaction components should be child objects
+ of the compartment, since this defines what volume they will occupy.
+ Specifically , a pool or reaction object must be placed somewhere
+ below the compartment in the object tree for the volume to be
+ set correctly and for the solvers to know what to use.
+ #. Assign parameters for the components.
+
+ * Compartments have a **volume**, and each subtype will have
+ quite elaborate options for partitioning the compartment
+ into voxels.
+ * **Pool** s have one key parameter, the initial
+ concentration **concInit**.
+ * **Reac** tions have two parameters: **K**\ :sub:`f`\ and **K**\ :sub:`b`\.
+ * **Enz** ymes have two primary parameters **k**\ :sub:`cat`\ and **K**\ :sub:`m`\.
+ That is enough for **MMenz** ymes. Regular **Enz** ymes have
+ an additional parameter **k**\ :sub:`2`\ which by default is set to 4.0
+ times **k**\ :sub:`cat`\, but you may also wish to explicitly assign it
+ if you know its value.
+
+ #. Connect up the reaction system using moose messaging.
+ #. Create and connect up input and output tables as needed.
+ #. Create and connect up the solvers as needed. This has to be done
+ in a specific order. Examples are linked below, but briefly the
+ order is:
+
+ a. Make the compartment and reaction system.
+ b. Make the Ksolve or Gsolve.
+ c. Make the Stoich.
+ d. Assign **stoich.compartment** to the compartment
+ e. Assign **stoich.ksolve** to either the Ksolve or Gsolve.
+ f. Assign **stoich.path** to finally fill in the reaction system.
+
+An example of manipulating the models is as following:
+
+.. automodule:: scriptKineticSolver
+ :members:
+
+The recommended way to build a chemical model, of course, is to load it
+in from a file format specific to such models. MOOSE understands
+**SBML**, **kkit.g** (a legacy GENESIS format), and **cspace**
+(a very compact format used in a large study of bistables from
+Ramakrishnan and Bhalla, PLoS Comp. Biol 2008).
+
+One key concept is that in MOOSE the components, messaging, and access
+to model components is identical regardless of whether the model was
+built from parts, or loaded in from a file. All that the file loaders do
+is to use the file to automate the steps above. Thus the model components
+and their fields are completely accessible from the script even if
+the model has been loaded from a file.
+
+Cross-Compartment Reaction Systems
+----------------------------------
+
+Frequently reaction systems span cellular (chemical) compartments.
+For example, a membrane-bound molecule may be phosphorylated by a
+cytosolic kinase, using soluble ATP as one of the substrates. Here the
+membrane and the cytsol are different chemical compartments.
+MOOSE supports such reactions. The following snippets illustrate
+cross-compartment chemistry. Note that the interpretation of the rates
+of enzymes and reactions does depend on which compartment they reside in.
+
+.. automodule:: crossComptSimpleReac
+ :members:
+
+.. automodule:: crossComptOscillator
+ :members:
+
+.. automodule:: crossComptNeuroMesh
+ :members:
+
+.. automodule:: crossComptSimpleReacGSSA
+ :members:
+
+Tweaking Parameters
+-------------------
+
+.. automodule:: tweakingParameters
+ :members:
+
+.. figure:: ../../../images/tweakingParameters.png
+ :alt: Three oscillation patterns after tweaking model parameters.
+
+Models' Demonstration
+---------------------
+
+Oscillation Model
+^^^^^^^^^^^^^^^^^
+
+.. automodule:: slowFbOsc
+ :members:
+
+.. automodule:: repressillator
+ :members:
+
+.. automodule:: relaxationOsc
+ :members:
+
+Bistability Models
+^^^^^^^^^^^^^^^^^^
+
+MAPK feedback loop model
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. automodule:: mapkFB
+ :members:
+
+Simple minimal bistable model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. automodule:: scaleVolumes
+ :members:
+
+Strongly bistable Model
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. automodule:: strongBis
+ :members:
+
+Model of bidirectional synaptic plasticity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[showing bistable chemical switch]
+
+.. automodule:: bidirectionalPlasticity
+ :members:
+
+Reaction Diffusion Models
+-------------------------
+
+The MOOSE design for reaction-diffusion is to specify one or
+more cellular 'compartments', and embed reaction systems in each of them.
+
+A 'compartment', in the context of reaction-diffusion, is used in the
+cellular sense of a biochemically defined,
+volume restricted subpart of a cell. Many but not all compartments
+are bounded by a cell membrane, but biochemically the membrane itself
+may form a compartment. Note that this interpretation differs from that
+of a 'compartment' in detailed electrical models of neurons.
+
+A reaction system can be loaded in from any of the supported MOOSE
+formats, or built within Python from MOOSE parts.
+
+The computations for such models are done by a set of objects:
+Stoich, Ksolve and Dsolve. Respectively, these handle the model
+reactions and stoichiometry matrix, the reaction computations for
+each voxel, and the diffusion between voxels. The 'Compartment' specifies
+how the model should be spatially discretized.
+
+[Reaction-diffusion + transport in a tapering cylinder]
+
+.. automodule:: cylinderDiffusion
+ :members:
+
+.. automodule:: cylinderMotor
+ :members:
+
+.. automodule:: gssaCylinderDiffusion
+ :members:
+
+Neuronal Diffusion Reaction
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: rxdFuncDiffusion
+ :members:
+
+.. automodule:: rxdReacDiffusion
+ :members:
+
+.. automodule:: rxdFuncDiffusionStoch
+ :members:
+
+A Turing Model
+--------------
+
+.. automodule:: TuringOneDim
+ :members:
+
+Reaction Diffusion in Neurons
+-----------------------------
+
+.. automodule:: reacDiffConcGradient
+ :members:
+
+.. automodule:: reacDiffBranchingNeuron
+ :members:
+
+.. automodule:: reacDiffSpinyNeuron
+ :members:
+
+.. automodule:: diffSpinyNeuron
+ :members:
+
+Manipulating Chemical Models
+----------------------------
+
+Running with different numerical methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: switchKineticSolvers
+ :members:
+
+Changing volumes
+^^^^^^^^^^^^^^^^
+
+.. automodule:: scaleVolumes
+ :members:
+ :noindex:
+
+Feeding tabulated input to a model
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: analogStimTable
+ :members:
+
+Finding steady states
+^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: findChemSteadyState
+ :members:
+
+Making a dose-response curve
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. figure:: ../../../images/chemDoseResponse.png
+ :alt: Dose-response curve example for a bistable system.
+
+.. automodule:: chemDoseResponse
+ :members:
+
+Transport in branching dendritic tree
+-------------------------------------
+
+.. figure:: ../../../images/reacDiffBranchingNeuron.png
+ :alt: Pseudo-3-D rendition of branching neuron and the concs in it.
+
+.. automodule:: transportBranchingNeuron
+ :members:
diff --git a/docs/source/user/py/cookbook/chem_tut.rst b/docs/source/user/py/cookbook/chem_tut.rst
new file mode 100644
index 0000000000..d9e336f9a2
--- /dev/null
+++ b/docs/source/user/py/cookbook/chem_tut.rst
@@ -0,0 +1,43 @@
+*********
+Tutorials
+*********
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Finding Steady State (CSpace)
+-----------------------------
+
+.. automodule:: cspaceSteadyState
+ :members:
+
+Define a kinetic model using the scripting
+------------------------------------------
+
+.. automodule:: scriptKineticModel
+ :members:
diff --git a/docs/source/user/py/cookbook/elec.rst b/docs/source/user/py/cookbook/elec.rst
new file mode 100644
index 0000000000..aa23f757c6
--- /dev/null
+++ b/docs/source/user/py/cookbook/elec.rst
@@ -0,0 +1,11 @@
+*********************************************
+Single Neuron Electrical Aspects (BioPhysics)
+*********************************************
+
+.. toctree::
+ :maxdepth: 2
+
+ elec_mod
+ elec_GUI
+ elec_load_run
+ elec_sim_eg
diff --git a/docs/source/user/py/cookbook/elec_GUI.rst b/docs/source/user/py/cookbook/elec_GUI.rst
new file mode 100644
index 0000000000..3b98e1c8ad
--- /dev/null
+++ b/docs/source/user/py/cookbook/elec_GUI.rst
@@ -0,0 +1,75 @@
+********************************
+Neuronal simulations in MOOSEGUI
+********************************
+
+Neuronal models in various formats can be loaded and simulated in the
+**MOOSE Graphical User Interface**. The GUI displays the neurons in 3D,
+and allows visual selection and editing of neuronal properties. Plotting
+and visualization of activity proceed concurrently with the simulation.
+Support for creating and editing channels, morphology, and networks is
+planned for the future. MOOSEGUI uses SI units throughout.
+
+moose-examples
+^^^^^^^^^^^^^^^
+
+- **Cerebellar granule cell**
+
+ **File -> Load ->**
+ ~/moose/moose-examples/neuroml/GranuleCell/GranuleCell.net.xml
+
+ This is a single compartment Cerebellar granule cell with a variety
+ of channels `Maex, R. and De Schutter, E.,
+ 1997 `_ (exported from
+ http://www.neuroconstruct.org/). Click on its soma, and **See
+ children** for its list of channels. Vary the Gbar of these
+ channels to obtain regular firing, adapting and bursty behaviour (may
+ need to increase tau of the Ca pool).
+
+
+- **Pyloric rhythm generator in the stomatogastric ganglion of lobster**
+
+ **File -> Load ->**
+ ~/moose/moose-examples/neuroml/pyloric/Generated.net.xml
+
+
+- **Purkinje cell**
+
+ **File -> Load ->**
+ ~/moose/moose-examples/neuroml/PurkinjeCell/Purkinje.net.xml
+
+ This is a purely passive cell, but with extensive morphology [De
+ Schutter, E. and Bower, J. M., 1994] (exported from
+ http://www.neuroconstruct.org/). The channel specifications are in an
+ obsolete ChannelML format which MOOSE does not support.
+
+
+- **Olfactory bulb subnetwork**
+
+ **File -> Load ->**
+ ~/moose/moose-examples/neuroml/OlfactoryBulb/numgloms2_seed100.0_decimated.xml
+
+ This is a pruned and decimated version of a detailed network model
+ of the Olfactory bulb [Gilra A. and Bhalla U., in preparation]
+ without channels and synaptic connections. We hope to post the
+ ChannelML specifications of the channels and synapses soon.
+
+
+- **All channels cell**
+
+ **File -> Load ->**
+ ~/moose/moose-examples/neuroml/allChannelsCell/allChannelsCell.net.xml
+
+ This is the Cerebellar granule cell as above, but with loads of
+ channels from various cell types (exported from
+ http://www.neuroconstruct.org/). Play around with the channel
+ properties to see what they do. You can also edit the ChannelML files
+ in ~/moose/moose-examples/neuroml/allChannelsCell/cells_channels/ to
+ experiment further.
+
+
+- **NeuroML python scripts**
+ In directory ~/moose/moose-examples/neuroml/GranuleCell, you can run
+ python FvsI_Granule98.py which plots firing rate vs injected
+ current for the granule cell. Consult this python script to see how
+ to read in a NeuroML model and to set up simulations. There are ample
+ snippets in ~/moose/moose-examples/snippets too.
diff --git a/docs/source/user/py/cookbook/elec_load_run.rst b/docs/source/user/py/cookbook/elec_load_run.rst
new file mode 100644
index 0000000000..f3503c1b08
--- /dev/null
+++ b/docs/source/user/py/cookbook/elec_load_run.rst
@@ -0,0 +1,55 @@
+**************************
+Load and Run simple models
+**************************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Single Cubicle Compartmental Neuron
+-----------------------------------
+
+.. automodule:: cubeMeshSigNeur
+ :members:
+
+Single Neuron Model
+-------------------
+
+.. automodule:: testSigNeur
+ :members:
+
+Load neuron model from GENESIS
+------------------------------
+
+.. automodule:: neuronFromDotp
+ :members:
+
+Integrate-and-fire models
+-------------------------
+
+.. automodule:: IntegrateFireZoo
+ :members:
diff --git a/docs/source/user/py/cookbook/elec_mod.rst b/docs/source/user/py/cookbook/elec_mod.rst
new file mode 100644
index 0000000000..765a015141
--- /dev/null
+++ b/docs/source/user/py/cookbook/elec_mod.rst
@@ -0,0 +1,158 @@
+****************
+Neuron Modeling
+****************
+
+Neurons are modelled as equivalent electrical circuits. The morphology
+of a neuron can be broken into isopotential compartments connected by
+axial resistances R\ :sub:`a`\ denoting the cytoplasmic
+resistance. In each compartment, the neuronal membrane is represented as
+a capacitance C\ :sub:`m`\ with a shunt leak resistance
+R\ :sub:`m`\ . Electrochemical gradient (due to ion pumps)
+across the leaky membrane causes a voltage drive E\ :sub:`m`\ ,
+that hyperpolarizes the inside of the cell membrane compared to the
+outside.
+
+Each voltage dependent ion channel, present on the membrane, is modelled
+as a voltage dependent conductance G\ :sub:`k`\ with gating
+kinetics, in series with an electrochemical voltage drive (battery)
+E\ :sub:`k`\ , across the membrane capacitance
+C\ :sub:`m`\ , as in the figure below.
+
+--------------------------------------------------------
+
+.. figure:: ../../../images/neuroncompartment.png
+ :align: center
+ :alt: **Equivalent circuit of neuronal compartments**
+
+ **Equivalent circuit of neuronal compartments**
+
+--------------------------------------------------------
+
+Neurons fire action potentials / spikes (sharp rise and fall of membrane
+potential V\ :sub:`m`\ ) due to voltage dependent channels.
+These result in opening of excitatory / inhibitory synaptic channels
+(conductances with batteries, similar to voltage gated channels) on
+other connected neurons in the network.
+
+MOOSE can handle large networks of detailed neurons, each with
+complicated channel dynamics. Further, MOOSE can integrate chemical
+signalling with electrical activity. Presently, creating and simulating
+these requires PyMOOSE scripting, but these will be incorporated into
+the GUI in the future.
+
+To understand channel kinetics and neuronal action potentials, run the
+Squid Axon demo installed along with MOOSEGUI and consult its
+help/tutorial.
+
+Read more about compartmental modelling in the first few chapters of the
+`Book of Genesis `_.
+
+Models can be defined in `NeuroML `_, an XML
+format which is mostly supported across simulators. Channels, neuronal
+morphology (compartments), and networks can be specified using various
+levels of NeuroML, namely ChannelML, MorphML and NetworkML. Importing of
+cell models in the `GENESIS `_
+.p format is supported for backward compatibitility.
+
+Modeling details
+================
+
+Some salient properties of neuronal building blocks in MOOSE are
+described below. Variables that are updated at every simulation time
+step are listed **dynamically**. Rest are parameters.
+
+- **Compartment**
+ When you select a compartment, you can view and edit its properties
+ in the right pane. V\ :sub:`m`\ and I\ :sub:`m`\
+ are plot-able.
+
+ - V\ :sub:`m`\
+ membrane potential (across C\ :sub:`m`\ ) in Volts. It is a
+ dynamical variable.
+ - C\ :sub:`m`\
+ membrane capacitance in Farads.
+ - E\ :sub:`m`\
+ membrane leak potential in Volts due
+ to the electrochemical gradient setup by ion pumps.
+ - I\ :sub:`m`\
+ current in Amperes across the membrane via leak resistance R\
+ :sub:`m`\ .
+ - inject
+ current in Amperes injected externally into the compartment.
+ - initVm
+ initial V\ :sub:`m`\ in Volts.
+ - R\ :sub:`m`\
+ membrane leak resistance in Ohms due to leaky channels.
+ - diameter
+ diameter of the compartment in metres.
+ - length
+ length of the compartment in metres.
+
+- **HHChannel**
+ Hodgkin-Huxley channel with voltage dependent dynamical gates.
+
+ - Gbar
+ peak channel conductance in Siemens.
+ - E\ :sub:`k`\
+ reversal potential of the channel, due to electrochemical
+ gradient of the ion(s) it allows.
+ - G\ :sub:`k`\
+ conductance of the channel in Siemens.
+ G\ :sub:`k`\ (t) = Gbar × X(t)\ :sup:`Xpower`\ ×
+ Y(t)\ :sup:`Ypower`\ × Z(t)\ :sup:`Zpower`\
+
+ - I\ :sub:`k`\
+ current through the channel into the neuron in Amperes.
+ I\ :sub:`k`\ (t) = G\ :sub:`k`\ (t) ×
+ (E\ :sub:`k`\ -V\ :sub:`m`\ (t))
+
+ - X, Y, Z
+ gating variables (range 0.0 to 1.0) that may turn on or off as
+ voltage increases with different time constants.
+
+ dX(t)/dt = X\ :sub:`inf`\ /τ - X(t)/τ
+
+ Here, X\ :sub:`inf`\ and τ are typically
+ sigmoidal/linear/linear-sigmoidal functions of membrane
+ potential V\ :sub:`m`\ , which are described in a ChannelML
+ file and presently not editable from MOOSEGUI. Thus, a gate
+ may open (X\ :sub:`inf`\ (V\ :sub:`m`\ ) → 1) or close (X\
+ :sub:`inf`\ (V\ :sub:`m`\ ) → 0) on increasing V\ :sub:`m`\
+ , with time constant τ(V\ :sub:`m`\ ).
+
+ - Xpower, Ypower, Zpower
+ powers to which gates are raised in the G\ :sub:`k`\ (t)
+ formula above.
+
+- **HHChannel2D**
+ The Hodgkin-Huxley channel2D can have the usual voltage dependent
+ dynamical gates, and also gates that depend on voltage and an
+ ionic concentration, as for say Ca-dependent K conductance. It has
+ the properties of HHChannel above, and a few more, similar to
+ in the `GENESIS tab2Dchannel
+ reference `_.
+
+- **CaConc**
+ This is a pool of Ca ions in each compartment, in a shell volume
+ under the cell membrane. The dynamical Ca concentration increases
+ when Ca channels open, and decays back to resting with a specified
+ time constant τ. Its concentration controls Ca-dependent K channels,
+ etc.
+
+ - Ca
+ Ca concentration in the pool in units mM ( i.e., mol/m\
+ :sup:`3`\ ).
+
+ d[Ca\ :sup:`2+`\ ]/dt = B × I\ :sub:`Ca`\ -
+ [Ca\ :sup:`2+`\ ]/τ
+
+ - CaBasal/Ca_base
+ Base Ca concentration to which the Ca decays
+ - tau
+ time constant with which the Ca concentration decays to the base Ca level.
+ - B
+ constant in the [Ca\ :sup:`2+`\ ] equation above.
+ - thick
+ thickness of the Ca shell within the cell membrane which is
+ used to calculate B (see Chapter 19 of `Book of GENESIS
+ `_.)
diff --git a/docs/source/user/py/cookbook/elec_sim_eg.rst b/docs/source/user/py/cookbook/elec_sim_eg.rst
new file mode 100644
index 0000000000..9f01aa650a
--- /dev/null
+++ b/docs/source/user/py/cookbook/elec_sim_eg.rst
@@ -0,0 +1,89 @@
+***************
+Simple Examples
+***************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Create a Leaky Neuron
+---------------------
+
+.. automodule:: lif
+ :members:
+
+Create a Leaky Compartment
+--------------------------
+
+.. automodule:: lifcomp
+ :members:
+
+Voltage Clamping
+----------------
+
+.. automodule:: vclamp
+ :members:
+
+Generate Pulse
+----------------
+
+.. automodule:: pulsegen
+ :members:
+
+.. automodule:: pulsegen2
+ :members:
+
+Synapse
+-------
+
+.. automodule:: synapse
+ :members:
+
+Message transmission via synapse
+--------------------------------
+
+.. automodule:: intfire
+ :members:
+
+Gap Junction
+------------
+
+.. automodule:: gapjunction
+ :members:
+
+Insert Spine heads
+------------------
+
+.. automodule:: insertSpinesWithoutRdesigneur
+ :members:
+
+.. Multi compartmental Neuron model
+.. --------------------------------
+
+.. automodule: testHsolve
+ :members:
+ (testHsolve no longer exists in any of the appended paths)
diff --git a/docs/source/user/py/cookbook/index_ckbk.rst b/docs/source/user/py/cookbook/index_ckbk.rst
new file mode 100644
index 0000000000..be854b3463
--- /dev/null
+++ b/docs/source/user/py/cookbook/index_ckbk.rst
@@ -0,0 +1,17 @@
+.. MOOSE documentation master file, created by
+ sphinx-quickstart on Tue Jul 1 19:05:47 2014.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Cook Book
+=========
+
+The MOOSE Cookbook contains recipes showing you, how to do specific tasks in MOOSE.
+
+.. toctree::
+ :maxdepth: 2
+
+ elec
+ chem
+ network
+ multiscale
diff --git a/docs/source/user/py/cookbook/multi_sim_eg.rst b/docs/source/user/py/cookbook/multi_sim_eg.rst
new file mode 100644
index 0000000000..104868c2fa
--- /dev/null
+++ b/docs/source/user/py/cookbook/multi_sim_eg.rst
@@ -0,0 +1,53 @@
+***************
+Simple Examples
+***************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Single-compartment multiscale model
+-----------------------------------
+
+.. automodule:: multiscaleOneCompt
+ :members:
+
+Multi compartment Single Neuron Model
+-------------------------------------
+
+.. automodule:: multiComptSigNeur
+ :members:
+
+Modeling chemical reactions in neurons
+--------------------------------------
+
+.. automodule:: gssaRDspiny
+ :members:
+
+.. automodule: rxdSpineSize
+ :members:
+ (rxdSpineSize does not exist in any appended folders -> gives error while building html)
diff --git a/docs/source/user/py/cookbook/multiscale.rst b/docs/source/user/py/cookbook/multiscale.rst
new file mode 100644
index 0000000000..799ee80452
--- /dev/null
+++ b/docs/source/user/py/cookbook/multiscale.rst
@@ -0,0 +1,11 @@
+*******************
+MultiScale Modeling
+*******************
+
+.. toctree::
+ :maxdepth: 2
+
+ multi_sim_eg
+
+
+
diff --git a/docs/source/user/py/cookbook/net_sim_eg.rst b/docs/source/user/py/cookbook/net_sim_eg.rst
new file mode 100644
index 0000000000..6b15acdb7d
--- /dev/null
+++ b/docs/source/user/py/cookbook/net_sim_eg.rst
@@ -0,0 +1,102 @@
+***************
+Simple Examples
+***************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Connecting two cells via a synapse
+----------------------------------
+
+Below is the connectivity diagram for setting up a synaptic connection
+from one neuron to another. The PulseGen object is there for
+stimulating the presynaptic cell as part of experimental setup. The
+cells are defined as single-compartments with Hodgkin-Huxley type Na+
+and K+ channels.
+
+.. figure:: ../../../images/twoCells.png
+ :scale: 50%
+ :alt: Two cells connected via synapse
+
+.. automodule:: twocells
+ :members:
+
+Multi Compartmental Leaky Neurons
+---------------------------------
+
+.. automodule:: multicomp_lif
+ :members:
+
+Providing random input to a cell
+--------------------------------
+
+.. automodule:: randomspike
+ :members:
+
+.. figure:: ../../../images/randomSpike.png
+ :scale: 50%
+ :alt: Random spike input to a cell
+
+Plastic synapse
+---------------
+
+.. automodule:: STDP
+ :members:
+
+Synapse Handler for Spikes
+--------------------------
+
+.. automodule:: RandSpikeStats
+ :members:
+
+Recurrent integrate-and-fire network
+------------------------------------
+
+.. automodule:: recurrentIntFire
+ :members:
+
+Recurrent integrate-and-fire network with plasticity
+----------------------------------------------------
+
+.. automodule:: recurrentLIF
+ :members:
+
+Demonstration Models
+--------------------
+
+.. automodule:: compartment_net
+ :members:
+
+.. automodule:: compartment_net_no_array
+ :members:
+
+Building Models
+---------------
+
+.. automodule:: synapse_tutorial
+ :members:
diff --git a/docs/source/user/py/cookbook/net_tut.rst b/docs/source/user/py/cookbook/net_tut.rst
new file mode 100644
index 0000000000..b784105698
--- /dev/null
+++ b/docs/source/user/py/cookbook/net_tut.rst
@@ -0,0 +1,40 @@
+*********
+Tutorials
+*********
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Network with Ca-based plasticity
+--------------------------------
+
+.. automodule:: GraupnerBrunel2012_STDPfromCaPlasticity
+ :members:
+
+.. automodule:: HigginsGraupnerBrunel2014_LifetimeCaPlasticity
+ :members:
diff --git a/docs/source/user/py/cookbook/network.rst b/docs/source/user/py/cookbook/network.rst
new file mode 100644
index 0000000000..d016e1dcce
--- /dev/null
+++ b/docs/source/user/py/cookbook/network.rst
@@ -0,0 +1,9 @@
+**********
+Networking
+**********
+
+.. toctree::
+ :maxdepth: 2
+
+ net_sim_eg
+ net_tut
diff --git a/docs/source/user/py/graphics/content_g.rst b/docs/source/user/py/graphics/content_g.rst
new file mode 100644
index 0000000000..6080c48ec9
--- /dev/null
+++ b/docs/source/user/py/graphics/content_g.rst
@@ -0,0 +1,32 @@
+.. _graph-moogli:
+
+MOOGLI
+======
+
+Use Moogli for plotting
+-----------------------
+
+.. automodule:: loadMorphology
+ :members:
+ :noindex:
+
+MatPlotLib
+==========
+
+Displaying time-series plots
+----------------------------
+
+.. automodule:: crossComptNeuroMesh
+ :members:
+ :noindex:
+
+Animation of values along axis
+------------------------------
+
+.. automodule:: diffSpinyNeuron
+ :members:
+ :noindex:
+
+.. automodule:: reacDiffBranchingNeuron
+ :members:
+ :noindex:
diff --git a/docs/source/user/py/graphics/index_graphics.rst b/docs/source/user/py/graphics/index_graphics.rst
new file mode 100644
index 0000000000..36dca56e81
--- /dev/null
+++ b/docs/source/user/py/graphics/index_graphics.rst
@@ -0,0 +1,6 @@
+Graphics
+========
+
+.. toctree::
+
+ content_g
diff --git a/docs/source/user/py/quickstart/classes_demos.rst b/docs/source/user/py/quickstart/classes_demos.rst
new file mode 100644
index 0000000000..290c2eb709
--- /dev/null
+++ b/docs/source/user/py/quickstart/classes_demos.rst
@@ -0,0 +1,157 @@
+*************
+MOOSE Classes
+*************
+
+Messages
+^^^^^^^^
+
+One-to-one message
+""""""""""""""""""
+
+.. automodule:: onetoonemsg
+ :members:
+
+Show the message
+""""""""""""""""
+
+.. automodule:: showmsg
+ :members:
+
+Single Message Cross
+""""""""""""""""""""
+
+.. automodule:: singlemsgcross
+ :members:
+
+Time
+^^^^
+
+Clocks
+""""""
+
+.. automodule:: showclocks
+ :members:
+
+Generating Time Data Table
+""""""""""""""""""""""""""
+
+.. automodule:: timetable
+ :members:
+
+Vectors
+^^^^^^^
+
+.. automodule:: vectors
+ :members:
+
+Data Entries
+^^^^^^^^^^^^
+
+.. automodule:: wildcard
+ :members:
+
+Interpolation
+^^^^^^^^^^^^^
+
+1-dimentional Interpolation
+"""""""""""""""""""""""""""
+
+.. automodule:: interpol
+ :members:
+
+2-dimentional interpolation
+"""""""""""""""""""""""""""
+
+.. automodule:: interpol2d
+ :members:
+
+Function
+^^^^^^^^
+
+.. automodule:: func
+ :members:
+ :noindex:
+
+SymCompartment
+^^^^^^^^^^^^^^
+
+.. automodule:: symcompartment
+ :members:
+
+Tables
+^^^^^^
+
+.. automodule:: tabledemo
+ :members:
+
+Data Types
+^^^^^^^^^^
+
+HDF DataType
+""""""""""""
+
+.. automodule:: hdfdemo
+ :members:
+
+NSDF DataType
+"""""""""""""
+
+.. automodule:: nsdf
+ :members:
+
+.. automodule:: nsdf_vec
+ :members:
+
+Threading
+^^^^^^^^^
+
+.. automodule:: threading_demo
+ :members:
+
+PyMoose
+^^^^^^^
+
+.. automodule:: traub_naf
+ :members:
+
+.. _quickstart-maths:
+
+Mathematics with MOOSE
+^^^^^^^^^^^^^^^^^^^^^^
+
+Computing an arbitrary function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: function
+ :members:
+
+.. figure:: ../../../images/function.png
+ :alt: Outputs of Function object calculating z = c0 * exp(c1 * x) * cos(y)
+ :scale: 50%
+
+Differential Equation Solving
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: diffEqSolution
+ :members:
+
+Harmonic Oscillatory Function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: funcRateHarmonicOsc
+ :members:
+
+Lotka-Voltera Model
+^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: funcReacLotkaVolterra
+ :members:
+
+.. automodule:: stochasticLotkaVolterra
+ :members:
+
+Vary Concentration with mathematical function
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: funcInputToPools
+ :members:
diff --git a/docs/source/user/py/quickstart/demos.rst b/docs/source/user/py/quickstart/demos.rst
new file mode 100644
index 0000000000..7fe408f1f0
--- /dev/null
+++ b/docs/source/user/py/quickstart/demos.rst
@@ -0,0 +1,33 @@
+**************************************
+Demonstration of basic functionalities
+**************************************
+
+.. _quickstart-load-run:
+
+Load and Run a Model
+--------------------
+
+.. automodule:: helloMoose
+ :members:
+
+.. _quickstart-timing:
+
+Start, Stop, and setting clocks
+-------------------------------
+
+.. automodule:: startstop
+ :members:
+
+.. automodule:: stimtable
+ :members:
+
+Run Python from MOOSE
+---------------------
+
+.. automodule:: pyrun
+ :members:
+
+.. automodule: pyrun1
+.. :members:
+
+.. _quickstart-classes:
diff --git a/docs/source/user/py/quickstart/index_qs.rst b/docs/source/user/py/quickstart/index_qs.rst
new file mode 100644
index 0000000000..fb4eb5e3e4
--- /dev/null
+++ b/docs/source/user/py/quickstart/index_qs.rst
@@ -0,0 +1,16 @@
+.. MOOSE documentation master file, created by
+ sphinx-quickstart on Tue Jul 1 19:05:47 2014.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Quick Start
+===========
+
+.. toctree::
+ :maxdepth: 2
+
+ qs_inter
+ qs_GUI
+ moose_quickstart
+ demos
+ classes_demos
diff --git a/docs/source/user/py/quickstart/moose_quickstart.rst b/docs/source/user/py/quickstart/moose_quickstart.rst
new file mode 100644
index 0000000000..7b0198449f
--- /dev/null
+++ b/docs/source/user/py/quickstart/moose_quickstart.rst
@@ -0,0 +1,734 @@
+***********************************************
+Getting started with python scripting for MOOSE
+***********************************************
+
+.. figure:: ../../../images/Gallery_Moose_Multiscale.png
+ :alt: **multiple scales in moose**
+ :scale: 100%
+
+ *Multiple scales can be modelled and simulated in MOOSE*
+
+
+
+*To see an interactive version of this page, click the following link*
+
+.. image:: https://mybinder.org/badge.svg
+ :target: https://mybinder.org/v2/gh/BhallaLab/moose-binder/master?filepath=home%2Fmooser%2Fquickstart%2FGetting%20started%20with%20python%20scripting%20for%20MOOSE.ipynb
+
+
+This document describes how to use the ``moose`` module in Python
+scripts or in an interactive Python shell. It aims to give you enough
+overview to help you start scripting using MOOSE and extract farther
+information that may be required for advanced work. Knowledge of
+Python or programming in general will be helpful. If you just want to
+simulate existing models in one of the supported formats, you can fire
+the MOOSE GUI and locate the model file using the ``File`` menu and
+load it. The GUI is described in separate document. If you
+are looking for recipes for specific tasks, take a look at
+`cookbook`. The example code in the boxes can be entered in
+a Python shell.
+
+MOOSE is object-oriented. Biological concepts are mapped into classes, and a model is built by creating instances of these classes and connecting them by messages. MOOSE also has numerical classes whose job is to take over difficult computations in a certain domain, and do them fast. There are such solver classes for stochastic and deterministic chemistry, for diffusion, and for multicompartment neuronal models.
+
+MOOSE is a simulation environment, not just a numerical engine: It provides data representations and solvers (of course!), but also a scripting interface with Python, graphical displays with Matplotlib, PyQt, and OpenGL, and support for many model formats. These include SBML, NeuroML, GENESIS kkit and cell.p formats, HDF5 and NSDF for data writing.
+
+Contents:
+
+.. contents::
+ :local:
+ :depth: 1
+
+Coding basics and how to use this document
+==========================================
+
+This page acts as the first stepping stone for learning how moose works. The tutorials here are intended to be interactive, and are presented as python commands. Python commands are identifiable by the ``>>>`` before the command as opposed to ``$`` which identifies a command-line command.
+
+ >>> this_is_a_python_command
+
+You are encouraged to run a python shell while reading through this documentation and trying out each command for yourself. Python shells are environments within your terminal wherein everything you type is interpreted as a python command. They can be accessed by typing
+::
+
+ $ python
+
+in your command-line terminal.
+
+While individually typing lines of code in a python terminal is useful for practicing using moose and coding in general, note that once you close the python environment all the code you typed is gone and the moose models created are also lost. In order to 'save' models that you create, you would have to type your code in a text file with a ``.py`` extension. The easiest way to do this is to create a text file in command line, open it with a text editor (for example, gedit), and simply type your code in (make sure you indent correctly).
+::
+
+ $ touch code.py
+ $ gedit code.py
+
+Once you have written your code in the file, you can run it through your python environment.
+::
+
+ $ python code.py
+
+Note that apart from this section of the quickstart, most of the moose documentation is in the form of ``snippets``. These are basically ``.py`` files with code that demonstrates a certain functionality in moose. If you see a dialogue box like this one:
+
+.. automodule:: func
+ :members: main
+
+You can view the code by clicking the green source button on the left side of the box. Alternatively, the source code for all of the examples in the documentation can be found in ``moose/moose-examples/snippets``. Once you run each file in python, it is encouraged that you look through the code to understand how it works.
+
+In the quickstart, most of the snippets demonstrate the functionality of specific classes. However, snippets in later sections such as the cookbook show how to do specific things in moose such as creating networks, chemical models, and synaptic channels.
+
+
+Importing moose and accessing documentation
+===========================================
+
+
+In a python script you import modules to access the functionalities they provide. In order to use moose, you need to import it within a python environment or at the beginning of your python script.
+
+ >>> import moose
+
+This make the ``moose`` module available for use in Python. You can use Python's built-in ``help`` function to read the top-level documentation for the moose module.
+
+ >>> help(moose)
+
+This will give you an overview of the module. Press ``q`` to exit the pager and get back to the interpreter. You can also access the documentation for individual classes and functions this way.
+
+ >>> help(moose.connect)
+
+To list the available functions and classes you can use ``dir``
+function [1]_. ::
+
+ >>> dir(moose)
+
+MOOSE has built-in documentation in the C++-source-code independent of
+Python. The ``moose`` module has a separate ``doc`` function to extract
+this documentation. ::
+
+ >>> moose.doc('moose.Compartment')
+
+The class level documentation will show whatever the author/maintainer
+of the class wrote for documentation followed by a list of various kinds
+of fields and their data types. This can be very useful in an
+interactive session.
+
+Each field can have its own detailed documentation, too. ::
+
+ >>> moose.doc('Compartment.Rm')
+
+Note that you need to put the class-name followed by dot followed by
+field-name within quotes. Otherwise, ``moose.doc`` will receive the
+field value as parameter and get confused.
+
+Alternatively, if you want to see a full list of classes, functions and their fields, you can browse through the following pages. This is especially helpful when going through snippets.
+
+* :ref:`genindex`
+* :ref:`modindex`
+
+..
+ :ref:`search`
+
+.. _quickstart-creating:
+
+Creating objects and traversing the object hierarchy
+----------------------------------------------------
+
+Different types of biological entities like neurons, enzymes, etc are
+represented by classes and individual instances of those types are
+objects of those classes. Objects are the building-blocks of models in
+MOOSE. We call MOOSE objects ``element`` and use object and element
+interchangeably in the context of MOOSE. Elements are conceptually laid
+out in a tree-like hierarchical structure. If you are familiar with file
+system hierarchies in common operating systems, this should be simple.
+
+At the top of the object hierarchy sits the ``Shell``, equivalent to the
+root directory in UNIX-based systems and represented by the path ``/``.
+You can list the existing objects under ``/`` using the ``le`` function. ::
+
+ >>> moose.le()
+ Elements under /
+ /Msgs
+ /clock
+ /classes
+ /postmaster
+
+``Msgs``, ``clock`` and ``classes`` are predefined objects in MOOSE. And
+each object can contain other objects inside them. You can see them by
+passing the path of the parent object to ``le`` ::
+
+ >>> moose.le('/Msgs')
+ Elements under /Msgs[0]
+ /Msgs[0]/singleMsg
+ /Msgs[0]/oneToOneMsg
+ /Msgs[0]/oneToAllMsg
+ /Msgs[0]/diagonalMsg
+ /Msgs[0]/sparseMsg
+
+Now let us create some objects of our own. This can be done by invoking
+MOOSE class constructors (just like regular Python classes). ::
+
+ >>> model = moose.Neutral('/model')
+
+The above creates a ``Neutral`` object named ``model``. ``Neutral`` is
+the most basic class in MOOSE. A ``Neutral`` element can act as a
+container for other elements. We can create something under ``model`` ::
+
+ >>> soma = moose.Compartment('/model/soma')
+
+Every element has a unique path. This is a concatenation of the names of
+all the objects one has to traverse starting with the root to reach that
+element. ::
+
+ >>> print soma.path
+ /model/soma
+
+The name of the element can be printed, too. ::
+
+ >>> print soma.name
+ soma
+
+The ``Compartment`` elements model small sections of a neuron. Some
+basic experiments can be carried out using a single compartment. Let us
+create another object to act on the ``soma``. This will be a step
+current generator to inject a current pulse into the soma. ::
+
+ >>> pulse = moose.PulseGen('/model/pulse')
+
+You can use ``le`` at any point to see what is there ::
+
+ >>> moose.le('/model')
+ Elements under /model
+ /model/soma
+ /model/pulse
+
+And finally, we can create a ``Table`` to record the time series of the
+soma's membrane potential. It is good practice to organize the data
+separately from the model. So we do it as below ::
+
+ >>> data = moose.Neutral('/data')
+ >>> vmtab = moose.Table('/data/soma_Vm')
+
+Now that we have the essential elements for a small model, we can go on
+to set the properties of this model and the experimental protocol.
+
+.. _quickstart-properties:
+
+Setting the properties of elements: accessing fields
+====================================================
+
+Elements have several kinds of fields. The simplest ones are the
+``value fields``. These can be accessed like ordinary Python members.
+You can list the available value fields using ``getFieldNames``
+function ::
+
+ >>> soma.getFieldNames('valueFinfo')
+
+Here ``valueFinfo`` is the type name for value fields. ``Finfo`` is
+short form of *field information*. For each type of field there is a
+name ending with ``-Finfo``. The above will display the following
+list ::
+
+ ('this',
+ 'name',
+ 'me',
+ 'parent',
+ 'children',
+ 'path',
+ 'class',
+ 'linearSize',
+ 'objectDimensions',
+ 'lastDimension',
+ 'localNumField',
+ 'pathIndices',
+ 'msgOut',
+ 'msgIn',
+ 'Vm',
+ 'Cm',
+ 'Em',
+ 'Im',
+ 'inject',
+ 'initVm',
+ 'Rm',
+ 'Ra',
+ 'diameter',
+ 'length',
+ 'x0',
+ 'y0',
+ 'z0',
+ 'x',
+ 'y',
+ 'z')
+
+Some of these fields are for internal or advanced use, some give access
+to the physical properties of the biological entity we are trying to
+model. Now we are interested in ``Cm``, ``Rm``, ``Em`` and ``initVm``.
+In the most basic form, a neuronal compartment acts like a parallel
+``RC`` circuit with a battery attached. Here ``R`` and ``C`` are
+resistor and capacitor connected in parallel, and the battery with
+voltage ``Em`` is in series with the resistor, as shown below:
+
+
+
+.. figure:: ../../../images/neuronalcompartment.jpg
+ :alt: **Passive neuronal compartment**
+
+ **Passive neuronal compartment**
+
+
+
+The fields are populated with some defaults. ::
+
+ >>> print soma.Cm, soma.Rm, soma.Vm, soma.Em, soma.initVm
+ 1.0 1.0 -0.06 -0.06 -0.06
+
+
+You can set the ``Cm`` and ``Rm`` fields to something realistic using
+simple assignment (we follow SI unit) [2]_. ::
+
+ >>> soma.Cm = 1e-9
+ >>> soma.Rm = 1e7
+ >>> soma.initVm = -0.07
+
+Instead of writing print statements for each field, you could use the
+utility function showfield to see that the changes took effect ::
+
+ >>> moose.showfield(soma)
+ [ /soma[0] ]
+ diameter = 0.0
+ Ra = 1.0
+ y0 = 0.0
+ Rm = 10000000.0
+ numData = 1
+ inject = 0.0
+ initVm = -0.07
+ Em = -0.06
+ y = 0.0
+ numField = 1
+ path = /soma[0]
+ dt = 5e-05
+ tick = 4
+ z0 = 0.0
+ name = soma
+ Cm = 1e-09
+ x0 = 0.0
+ Vm = -0.06
+ className = Compartment
+ length = 0.0
+ Im = 0.0
+ x = 0.0
+ z = 0.0
+
+Now we can setup the current pulse to be delivered to the soma ::
+
+ >>> pulse.delay[0] = 50e-3
+ >>> pulse.width[0] = 100e-3
+ >>> pulse.level[0] = 1e-9
+ >>> pulse.delay[1] = 1e9
+
+This tells the pulse generator to create a 100 ms long pulse 50 ms after
+the start of the simulation. The amplitude of the pulse is set to 1 nA.
+We set the delay for the next pulse to a very large value (larger than
+the total simulation time) so that the stimulation stops after the first
+pulse. Had we set ``pulse.delay = 0`` , it would have generated a pulse
+train at 50 ms intervals.
+
+.. _quickstart-connections:
+
+Putting them together: setting up connections
+=============================================
+
+In order for the elements to interact during simulation, we need to
+connect them via messages. Elements are connected to each other using
+special source and destination fields. These types are named
+``srcFinfo`` and ``destFinfo``. You can query the available source and
+destination fields on an element using ``getFieldNames`` as before. This
+time, let us do it another way: by the class name ::
+
+ >>> moose.getFieldNames('PulseGen', 'srcFinfo')
+ ('childMsg', 'output')
+
+This form has the advantage that you can get information about a class
+without creating elements of that class.
+
+Here ``childMsg`` is a source field that is used by the MOOSE internals
+to connect child elements to parent elements. The second one is of our
+interest. Check out the built-in documentation here ::
+
+ >>> moose.doc('PulseGen.output')
+ PulseGen.output: double - source field
+ Current output level.
+
+so this is the output of the pulse generator and this must be injected
+into the ``soma`` to stimulate it. But where in the ``soma`` can we send
+it? Again, MOOSE has some introspection built in. ::
+
+ >>> soma.getFieldNames('destFinfo')
+ ('parentMsg',
+ 'setThis',
+ 'getThis',
+ ...
+ 'setZ',
+ 'getZ',
+ 'injectMsg',
+ 'randInject',
+ 'cable',
+ 'process',
+ 'reinit',
+ 'initProc',
+ 'initReinit',
+ 'handleChannel',
+ 'handleRaxial',
+ 'handleAxial')
+
+Now that is a long list. But much of it are fields for internal or
+special use. Anything that starts with ``get`` or ``set`` are internal
+``destFinfo`` used for accessing value fields (we shall use one of those
+when setting up data recording). Among the rest ``injectMsg`` seems to
+be the most likely candidate. Use the ``connect`` function to connect
+the pulse generator output to the soma input ::
+
+ >>> m = moose.connect(pulse, 'output', soma, 'injectMsg')
+
+``connect(source, source_field, dest, dest_field)`` creates a
+``message`` from ``source`` element's ``source_field`` field to ``dest``
+element's ``dest_field`` field and returns that message. Messages are
+also elements. You can print them to see their identity ::
+
+ >>> print m
+
+
+You can print any element as above and the string representation will
+show you the class, two numbers(\ ``id`` and ``dataId``) uniquely
+identifying it among all elements, and its path. You can get some more
+information about a message ::
+
+ >>> print m.e1.path, m.e2.path, m.srcFieldsOnE1, m.destFieldsOnE2
+ /model/pulse /model/soma ('output',) ('injectMsg',)
+
+
+will confirm what you already know.
+
+
+A message element has fields ``e1`` and ``e2`` referring to the elements
+it connects. For single one-directional messages these are source and
+destination elements, which are ``pulse`` and ``soma`` respectively. The
+next two items are lists of the field names which are connected by this
+message.
+
+You could also check which elements are connected to a particular field ::
+
+ >>> print soma.neighbors['injectMsg']
+ []
+
+Notice that the list contains something called vec. We discuss this
+`later <#some-more-details>`__. Also ``neighbors`` is a new kind of
+field: ``lookupFinfo`` which behaves like a dictionary. Next we connect
+the table to the soma to retrieve its membrane potential ``Vm``. This is
+where all those ``destFinfo`` starting with ``get`` or ``set`` come in
+use. For each value field ``X``, there is a ``destFinfo`` ``get{X}`` to
+retrieve the value at simulation time. This is used by the table to
+record the values ``Vm`` takes. ::
+
+ >>> moose.connect(vmtab, 'requestOut', soma, 'getVm')
+
+
+This finishes our model and recording setup. You might be wondering
+about the source-destination relationship above. It is natural to think
+that ``soma`` is the source of ``Vm`` values which should be sent to
+``vmtab``. But here ``requestOut`` is a ``srcFinfo`` acting like a
+reply card. This mode of obtaining data is called *pull* mode. [3]_
+
+You can skip the next section on fine control of the timing of updates
+and read :ref:`quickstart-running`.
+
+.. _quickstart-scheduling:
+
+Scheduling
+==========
+
+With the model all set up, we have to schedule the
+simulation. Different components in a model may have different rates
+of update. For example, the dynamics of electrical components require
+the update intervals to be of the order 0.01 ms whereas chemical
+components can be as slow as 1 s. Also, the results may depend on the
+sequence of the updates of different components. These issues are
+addressed in MOOSE using a clock-based update scheme. Each model
+component is scheduled on a clock tick (think of multiple hands of a
+clock ticking at different intervals and the object being updated at
+each tick of the corresponding hand). The scheduling also guarantees
+the correct sequencing of operations. For example, your Table objects
+should always be scheduled *after* the computations that they are
+recording, otherwise they will miss the outcome of the latest calculation.
+
+MOOSE has a central clock element (``/clock``) to manage
+time. Clock has a set of ``Tick`` elements under it that take care of
+advancing the state of each element with time as the simulation
+progresses. Every element to be included in a simulation must be
+assigned a tick. Each tick can have a different ticking interval
+(``dt``) that allows different elements to be updated at different
+rates.
+
+By default, every object is assigned a clock tick with reasonable default
+timesteps as soon it is created::
+
+ Class type tick dt
+ Electrical computations: 0-7 50 microseconds
+ electrical compartments,
+ V and ligand-gated ion channels,
+ Calcium conc and Nernst,
+ stimulus generators and tables,
+ HSolve.
+
+ Table (to plot elec. signals) 8 100 microseconds
+
+ Diffusion solver 10 0.01 seconds
+ Chemical computations: 11-17 0.1 seconds
+ Pool, Reac, Enz, MMEnz,
+ Func, Function,
+ Gsolve, Ksolve,
+ Stats (to do stats on outputs)
+
+ Table2 (to plot chem. signals) 18 1 second
+
+ HDF5DataWriter 30 1 second
+ Postmaster (for parallel 31 0.01 seconds
+ computations)
+
+There are 32 available clock ticks. Numbers 20 to 29 are
+unassigned so you can use them for whatever purpose you like.
+
+If you want fine control over the scheduling, there are three things
+you can do.
+
+ * Alter the 'tick' field on the object
+ * Alter the dt associated with a given tick, using the
+ **moose.setClock( tick, newdt)** command
+ * Go through a wildcard path of objects reassigning there clock ticks,
+ using **moose.useClock( path, newtick, function)**.
+
+Here we discuss these in more detail.
+
+**Altering the 'tick' field**
+
+Every object knows which tick and dt it uses::
+
+ >>> a = moose.Pool( '/a' )
+ >>> print a.tick, a.dt
+ 13 0.1
+
+The ``tick`` field on every object can be changed, and the object will
+adopt whatever clock dt is used for that tick. The ``dt`` field is
+readonly, because changing it would have side-effects on every object
+associated with the current tick.
+
+Ticks **-1** and **-2** are special: They both tell the object that it is
+disabled (not scheduled for any operations). An object with a
+tick of **-1** will be left alone entirely. A tick of **-2** is used in
+solvers to indicate that should the solver be removed, the object will
+revert to its default tick.
+
+**Altering the dt associated with a given tick**
+
+We initialize the ticks and set their ``dt`` values using the
+``setClock`` function. ::
+
+ >>> moose.setClock(0, 0.025e-3)
+ >>> moose.setClock(1, 0.025e-3)
+ >>> moose.setClock(2, 0.25e-3)
+
+This will initialize tick #0 and tick #1 with ``dt = 25`` μs and tick #2
+with ``dt = 250`` μs. Thus all the elements scheduled on ticks #0 and 1
+will be updated every 25 μs and those on tick #2 every 250 μs. We use
+the faster clocks for the model components where finer timescale is
+required for numerical accuracy and the slower clock to sample the
+values of ``Vm``.
+
+Note that if you alter the dt associated with a given tick, this will
+affect the update time for *all* the objects using that clock tick. If
+you're unsure that you want to do this, use one of the vacant ticks.
+
+
+**Assigning clock ticks to all objects in a wildcard path**
+
+To assign tick #2 to the table for recording ``Vm``, we pass its
+whole path to the ``useClock`` function. ::
+
+ >>> moose.useClock(2, '/data/soma_Vm', 'process')
+
+Read this as "use tick # 2 on the element at path ``/data/soma_Vm`` to
+call its ``process`` method at every step". Every class that is supposed
+to update its state or take some action during simulation implements a
+``process`` method. And in most cases that is the method we want the
+ticks to call at every time step. A less common method is ``init``,
+which is implemented in some classes to interleave actions or updates
+that must be executed in a specific order [4]_. The ``Compartment``
+class is one such case where a neuronal compartment has to know the
+``Vm`` of its neighboring compartments before it can calculate its
+``Vm`` for the next step. This is done with: ::
+
+ >>> moose.useClock(0, soma.path, 'init')
+
+Here we used the ``path`` field instead of writing the path explicitly.
+
+Next we assign tick #1 to process method of everything under ``/model``. ::
+
+ >>> moose.useClock(1, '/model/##', 'process')
+
+Here the second argument is an example of wild-card path. The ``##``
+matches everything under the path preceding it at any depth. Thus if we
+had some other objects under ``/model/soma``, ``process`` method of
+those would also have been scheduled on tick #1. This is very useful for
+complex models where it is tedious to scheduled each element
+individually. In this case we could have used ``/model/#`` as well for
+the path. This is a single level wild-card which matches only the
+children of ``/model`` but does not go farther down in the hierarchy.
+
+.. _quickstart-running:
+
+Running the simulation
+======================
+
+Once the model is all set up, we can put the model to its
+initial state using ::
+
+ >>> moose.reinit()
+
+You may remember that we had changed initVm from ``-0.06`` to ``-0.07``.
+The reinit call we initialize ``Vm`` to that value. You can verify that ::
+
+ >>> print soma.Vm
+ -0.07
+
+Finally, we run the simulation for 300 ms ::
+
+ >>> moose.start(300e-3)
+
+The data will be recorded by the ``soma_vm`` table, which is referenced
+by the variable ``vmtab``. The ``Table`` class provides a numpy array
+interface to its content. The field is ``vector``. So you can easily plot
+the membrane potential using the `matplotlib
+ /model[0]/comp[1]
+ /model[0]/comp[2]
+
+Thus elements are instances of class ``melement``. All elements in an
+``vec`` share the ``id_`` of the ``vec`` which can retrieved by
+``melement.getId()``.
+
+A frequent use case is that after loading a model from a file one knows
+the paths of various model components but does not know the appropriate
+class name for them. For this scenario there is a function called
+``element`` which converts ("casts" in programming jargon) a path or any
+moose object to its proper MOOSE class. You can create additional
+references to ``soma`` in the example this way ::
+
+ x = moose.element('/model/soma')
+
+Any MOOSE class can be extended in Python. But any additional attributes
+added in Python are invisible to MOOSE. So those can be used for
+functionalities at the Python level only. You can see
+``moose-examples/squid/squid.py`` for an example.
+
+``Finfos``
+----------
+
+The following kinds of ``Finfo`` are accessible in Python
+
+- **``valueFinfo``** : simple values. For each readable ``valueFinfo``
+ ``XYZ`` there is a ``destFinfo`` ``getXYZ`` that can be used for
+ reading the value at run time. If ``XYZ`` is writable then there will
+ also be ``destFinfo`` to set it: ``setXYZ``. Example:
+ ``Compartment.Rm``
+- **``lookupFinfo``** : lookup tables. These fields act like Python
+ dictionaries but iteration is not supported. Example:
+ ``Neutral.neighbors``.
+- **``srcFinfo``** : source of a message. Example:
+ ``PulseGen.output``.
+- **``destFinfo``** : destination of a message. Example:
+ ``Compartment.injectMsg``. Apart from being used in setting up
+ messages, these are accessible as functions from Python.
+ ``HHGate.setupAlpha`` is an example.
+- **``sharedFinfo``** : a composition of source and destination fields.
+ Example: ``Compartment.channel``.
+
+.. _quickstart-moving-on:
+
+Moving on
+=========
+
+Now you know the basics of pymoose and how to access the help
+system. You can figure out how to do specific things by looking at the
+'cookbook`. In addition, the ``moose-examples/snippets`` directory
+in your MOOSE installation has small executable python scripts that
+show usage of specific classes or functionalities. Beyond that you can
+browse the code in the ``moose-examples`` directory to see some more complex
+models.
+
+MOOSE is backward compatible with GENESIS and most GENESIS classes have
+been reimplemented in MOOSE. There is slight change in naming (MOOSE
+uses CamelCase), and setting up messages are different. But `GENESIS
+documentation `__
+is still a good source for documentation on classes that have been
+ported from GENESIS.
+
+If the built-in MOOSE classes do not satisfy your needs entirely, you
+are welcome to add new classes to MOOSE. The API documentation will
+help you get started.
+
+
+.. [1]
+ To list the classes only, use ``moose.le('/classes')``
+
+.. [2]
+ MOOSE is unit agnostic and things should work fine as long as you use
+ values all converted to a consistent unit system.
+
+.. [3]
+ This apparently convoluted implementation is for performance reason.
+ Can you figure out why? *Hint: the table is driven by a slower clock
+ than the compartment.*
+
+.. [4]
+ In principle any function available in a MOOSE class can be executed
+ periodically this way as long as that class exposes the function for
+ scheduling following the MOOSE API. So you have to consult the class'
+ documentation for any nonstandard methods that can be scheduled this
+ way.
diff --git a/docs/source/user/py/quickstart/qs_GUI.rst b/docs/source/user/py/quickstart/qs_GUI.rst
new file mode 100644
index 0000000000..c8bd99cb80
--- /dev/null
+++ b/docs/source/user/py/quickstart/qs_GUI.rst
@@ -0,0 +1,234 @@
+****************************************
+MOOSE GUI: Graphical interface for MOOSE
+****************************************
+
+Upinder Bhalla, Harsha Rani, Aviral Goel
+
+MOOSE is the Multiscale Object-Oriented Simulation Environment. It can do all these calculations together. One of its major uses is to make biologically detailed models that combine electrical and chemical signaling.
+
+This document describes the salient features of the GUI and Kinetickit of MOOSE.
+
+---------------------------------------------------------------------------------
+
+Contents
+--------
+
+- `Introduction <#introduction>`__
+- `Interface <#interface>`__
+
+ - `Menu Bar <#menu-bar>`__
+
+ - `File <#menu-file>`__
+
+ - `New <#file-new>`__
+ - `Load Model <#file-load-model>`__
+ - `Connect BioModels <#file-connect-biomodels>`__
+ - `Quit <#file-quit>`__
+
+ - `View <#menu-view>`__
+
+ - `Editor View <#editor-view>`__
+ - `Run View <#run-view>`__
+ - `Dock Widgets <#dock-widgets>`__
+ - `SubWindows <#subwindows>`__
+
+ - `Help <#menu-help>`__
+
+ - `About MOOSE <#about-moose>`__
+ - `Built-in Documentation <#built-in-documentation>`__
+ - `Report a bug <#report-a-bug>`__
+
+ - `Editor View <#editor-view>`__
+
+ - `Model Editor <#model-editor>`__
+ - `Property Editor <#property-editor>`__
+
+ - `Run View <#run-view>`__
+
+ - `Simulation Controls <#simulation-controls>`__
+ - `Plot Widget <#plot-widget>`__
+
+ - `Toolbar <#plot-widget-toolbar>`__
+ - `Context Menu <#plot-widget-context-menu>`__
+
+Introduction
+------------
+
+The Moose GUI currently allow you work on
+:doc:`chemical <../cookbook/chem_GUI>` and :doc:`electrical <../cookbook/elec_GUI>` models using a interface. This
+document describes the salient features of the GUI.
+
+Interface
+---------
+
+The interface layout consists of a `menu bar <#menu-bar>`_ and two
+views, `editor view <#editor-view>`_ and `run view <#run-view>`_.
+
+Menu Bar
+~~~~~~~~
+
+.. figure:: ../../../images/MooseGuiMenuImage.png
+ :align: center
+ :alt:
+
+The menu bar appears at the top of the main window. In Ubuntu 12.04, the
+menu bar appears only when the mouse is in the top menu strip of the
+screen. It consists of the following options -
+
+File
+^^^^
+
+The File menu option provides the following sub options
+
+- `New <#file-new>`_ - Create a new chemical signalling model.
+- `Load Model <#file-load-model>`_ - Load a chemical signalling or compartmental neuronal model from a file.
+- `Paper\_2015\_Demos Model <#paper-2015-demos-model>`_ - Loads and Runs chemical signalling or compartmental neuronal model from a file.
+- `Recently Loaded Models <#recently-loaded-models>`_ - List of models loaded in MOOSE. (Atleast one model should be loaded)
+- `Connect BioModels <#file-connect-biomodels>`_ - Load chemical signaling models from the BioModels database.
+- `Save <#file-quit>`_ - Saves chemical model to Genesis/SBML format.
+- `Quit <#file-quit>`_ - Quit the interface.
+
+View
+^^^^
+
+View menu option provides the following sub options -
+
+- `Editor View <#editor-view>`_ - Switch to the editor view for editing models.
+- `Run View <#run-view>`_ - Switch to run view for running models.
+- `Dock Widgets <#dock-widgets>`_ - Following dock widgets are provided
+
+ - `Python <#dock-widget-python>`_ - Brings up a full fledged python
+ interpreter integrated with MOOSE GUI. You can interact with
+ loaded models and load new models through the PyMoose API. The
+ entire power of python language is accessible, as well as
+ MOOSE-specific functions and classes.
+ - `Edit <#dock-widget-edit>`_ - A property editor for viewing and
+ editing the fields of a selected object such as a pool, enzyme,
+ function or compartment. Editable field values can be changed by
+ clicking on them and overwriting the new values. Please be sure to
+ press enter once the editing is complete, in order to save your changes.
+
+- `SubWindows <#subwindows>`_ - This allows you to tile or tabify the run and editor views.
+
+Help
+^^^^
+
+- `About Moose <#about-moose>`_ - Version and general information about MOOSE.
+- `Built-in documentation <#butilt-in-documentation>`_ - Documentation of MOOSE GUI.
+- `Report a bug <#report-a-bug>`_ - Directs to the github bug tracker for reporting bugs.
+
+Editor View
+~~~~~~~~~~~
+
+The editor view provides two windows -
+
+- `Model Editor <#model-editor>`_ - The model editor is a workspace to
+ edit and create models. Using click-and-drag from the icons in the
+ menu bar, you can create model entities such as chemical pools,
+ reactions, and so on. A click on any object brings its property
+ editor on screen (see below). In objects that can be interconnected,
+ a click also brings up a special arrow icon that is used to connect
+ objects together with messages. You can move objects around within
+ the edit window using click-and-drag. Finally, you can delete objects
+ by selecting one or more, and then choosing the delete option from
+ the pop-up menu. The links below is the screenshots point to the
+ details for the chemical signalling model editor.
+
+.. figure:: ../../../images/ChemicalSignallingEditor.png
+ :align: center
+ :alt: Chemical Signalling Model Editor
+
+ Chemical Signalling Model Editor
+
+- `Property Editor <#property-editor>`_ - The property editor provides a way of viewing and editing the properties of objects selected in the model editor.
+
+.. figure:: ../../../images/PropertyEditor.png
+ :align: center
+ :alt: Property Editor
+
+ Property Editor
+
+Run View
+~~~~~~~~
+
+The Run view, as the name suggests, puts the GUI into a mode where the
+model can be simulated. As a first step in this, you can click-and-drag
+an object to the graph window in order to create a time-series plot for
+that object. For example, in a chemical reaction, you could drag a pool
+into the graph window and subsequent simulations will display a graph of
+the concentration of the pool as a function of time. Within the Run View
+window, the time-evolution of the simulation is displayed as an
+animation. For chemical kinetic models, the size of the icons for
+reactant pools scale to indicate concentration. Above the Run View
+window, there is a special tool bar with a set of simulation controls to
+run the simulation.
+
+Simulation Controls
+^^^^^^^^^^^^^^^^^^^
+
+.. figure:: ../../../images/SimulationControl.png
+ :align: center
+ :alt: Simulation Control
+
+ Simulation Control
+
+This panel allows you to control the various aspects of the simulation.
+
+- `Run Time <#run-time>`_ - Determines duration for which simulation is to run. A simulation which has already run, runs further for the specified additional period.
+- `Reset <#reset>`_ - Restores simulation to its initial state; re-initializes all variables to t = 0.
+- `Stop <#stop>`_ - This button halts an ongoing simulation.
+- `Current time <#current-time>`_ - This reports the current simulation time.
+- `Preferences <#preferences>`_ - Allows you to set simulation and visualization related preferences.
+
+Plot Widget
+^^^^^^^^^^^
+
+Toolbar
+'''''''
+
+On top of plot window there is a little row of icons:
+
+.. figure:: ../../../images/PlotWindowIcons.png
+ :align: center
+ :alt:
+
+These are the plot controls. If you hover the mouse over them for a few
+seconds, a tool-tip pops up. The icons represent the following functions:
+
+- |image0| - Add a new plot window
+
+- |image1| - Deletes current plot window
+
+- |image2| - Toggle X-Y axis grid
+
+- |image3| - Returns the plot display to its default position
+
+- |image4| - Undoes or re-does manipulations you have done to the display.
+
+- |image5| - The plots will pan around with the mouse when you hold the left button down. The plots will zoom with the mouse when you hold the right button down.
+
+- |image6| - With the **``left mouse button``**, this will zoom in to the specified rectangle so that the plots become bigger. With the **``right mouse button``**, the entire plot display will be shrunk to fit into the specified rectangle.
+
+- |image7| - You don't want to mess with these .
+
+- |image8| - Save the plot.
+
+Context Menu
+''''''''''''
+
+The context menu is enabled by right clicking on the plot window. It has
+the following options -
+
+- **Export to CSV** - Exports the plotted data to CSV format
+- **Toggle Legend** - Toggles the plot legend
+- **Remove** - Provides a list of plotted entities. The selected entity will not be plotted.
+
+.. |image0| image:: ../../../images/Addgraph.png
+.. |image1| image:: ../../../images/delgraph.png
+.. |image2| image:: ../../../images/grid.png
+.. |image3| image:: ../../../images/MatPlotLibHomeIcon.png
+.. |image4| image:: ../../../images/MatPlotLibDoUndo.png
+.. |image5| image:: ../../../images/MatPlotLibPan.png
+.. |image6| image:: ../../../images/MatPlotLibZoom.png
+.. |image7| image:: ../../../images/MatPlotLibConfigureSubplots.png
+.. |image8| image:: ../../../images/MatPlotLibSave.png
diff --git a/docs/source/user/py/quickstart/qs_inter.rst b/docs/source/user/py/quickstart/qs_inter.rst
new file mode 100644
index 0000000000..88e147c891
--- /dev/null
+++ b/docs/source/user/py/quickstart/qs_inter.rst
@@ -0,0 +1,12 @@
+*********************
+Interactive Tutorials
+*********************
+
+Some of the pages in the documentation, such as the python scripting page and teaching tutorials are available in interactive form.
+
+These interactive tutorials serve as fully executable python environments that can run moose. Therefore, it is a great place to both learn about and play around with MOOSE.
+
+All the currently available interactive tutorials are available by clicking the link below:
+
+.. image:: https://mybinder.org/badge.svg
+ :target: https://mybinder.org/v2/gh/BhallaLab/moose-binder/master?filepath=home%2Fmooser%2FIndex.ipynb
diff --git a/docs/source/user/py/rdesigneur/index_rd.rst b/docs/source/user/py/rdesigneur/index_rd.rst
new file mode 100644
index 0000000000..a729cb8b0a
--- /dev/null
+++ b/docs/source/user/py/rdesigneur/index_rd.rst
@@ -0,0 +1,13 @@
+.. MOOSE documentation master file, created by
+ sphinx-quickstart on Tue Jul 31 19:05:47 2018.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Rdesignuer
+===========
+
+.. toctree::
+ :maxdepth: 2
+
+ rdes
+ multi_rdes
diff --git a/docs/source/user/py/rdesigneur/multi_rdes.rst b/docs/source/user/py/rdesigneur/multi_rdes.rst
new file mode 100644
index 0000000000..d240f1b1cb
--- /dev/null
+++ b/docs/source/user/py/rdesigneur/multi_rdes.rst
@@ -0,0 +1,52 @@
+************************
+Rdesigneur Examples
+************************
+
+.. hidden-code-block:: reStructuredText
+ :label: How to run these examples
+
+ Each of the following examples can be run by clicking on the green source button
+ on the right side of each example, and running from within a ``.py`` python file
+ on a computer where moose is installed.
+
+ Alternatively, all the files mentioned on this page can be found in the main
+ moose directory. They can be found under
+
+ (...)/moose/moose-examples/snippets
+
+ They can be run by typing
+
+ $ python filename.py
+
+ in your command line, where filename.py is the python file you want to run.
+
+ All of the following examples show one or more methods within each python file.
+ For example, in the ``cubeMeshSigNeur`` section, there are two blue tabs
+ describing the ``cubeMeshSigNeur.createSquid()`` and ``cubeMeshSigNeur.main()``
+ methods.
+
+ The filename is the bit that comes before the ``.`` in the blue boxes, with
+ ``.py`` added at the end of it. In this case, the file name would be
+ ``cubeMeshSigNeur.py``.
+|
+
+Building Chemical-Electrical Signalling Models
+----------------------------------------------
+
+Building a compartment
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: testRdesigneur
+ :members:
+
+Inserting Spines and viewing
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: insertSpines
+ :members:
+
+Proceeding with Spines
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. automodule:: testWigglySpines
+ :members:
diff --git a/docs/source/user/py/rdesigneur/rdes.rst b/docs/source/user/py/rdesigneur/rdes.rst
new file mode 100644
index 0000000000..cb92642795
--- /dev/null
+++ b/docs/source/user/py/rdesigneur/rdes.rst
@@ -0,0 +1,3427 @@
+**Rdesigneur: Building multiscale models**
+==========================================
+
+Author: Upi Bhalla
+
+Date: Aug 26 2016,
+
+Last-Updated: Nov 08 2018
+
+By: Upi Bhalla
+
+.. --------------
+
+Contents
+--------
+
+.. contents::
+ :depth: 3
+
+Introduction
+------------
+
+**Rdesigneur** (Reaction Diffusion and Electrical SIGnaling in NEURons)
+is an interface to the multiscale modeling capabilities in MOOSE. It is
+designed to build models incorporating biochemical signaling pathways in
+dendrites and spines, coupled to electrical events in neurons.
+Rdesigneur assembles models from predefined parts: it delegates the
+details to specialized model definition formats. Rdesigneur combines one
+or more of the following cell parts to build models:
+
+- Neuronal morphology
+- Dendritic spines
+- Ion channels
+- Reaction systems
+- Adaptors that couple between these for multiscale models
+
+It also folds in simulation input and output
+
+- Time-series stimuli for molecular concentration change and reaction rates
+- Current and voltage clamp
+- Synaptic input.
+- Time-series plots
+- File dumps
+- 3-D neuronal graphics
+
+Rdesigneur's main role is to specify how these are put together,
+including assigning parameters for the model. Using Rdesigneur one can compactly
+and quickly put together quite complex multiscale models.
+
+Rdesigneur examples
+-------------------
+
+Here we provide a few use cases, building up from a minimal model to a
+reasonably complete multiscale model spanning chemical and electrical
+signaling. The files for these examples are also available in
+``moose-examples/tutorials/Rdesigneur``, and the file names are mentioned
+as we go along.
+
+.. _`building rdesigneur without arguments`:
+
+Bare Rdesigneur: single passive compartment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex1_minimalModel.py*
+
+If we don't provide any arguments at all to the Rdesigneur, it makes a
+model with a single passive electrical compartment in the MOOSE path
+``/model/elec/soma``. Here is how to do this:
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur()
+ rdes.buildModel()
+
+To confirm that it has made a compartment with some default values we
+can add a line:
+
+::
+
+ moose.showfields( rdes.soma )
+
+This should produce the output:
+
+::
+
+ [ /model[0]/elec[0]/soma[0] ]
+ diameter = 0.0005
+ fieldIndex = 0
+ Ra = 7639437.26841
+ y0 = 0.0
+ Rm = 424413.177334
+ index = 0
+ numData = 1
+ inject = 0.0
+ initVm = -0.065
+ Em = -0.0544
+ y = 0.0
+ numField = 1
+ path = /model[0]/elec[0]/soma[0]
+ dt = 0.0
+ tick = -2
+ z0 = 0.0
+ name = soma
+ Cm = 7.85398163398e-09
+ x0 = 0.0
+ Vm = -0.06
+ className = ZombieCompartment
+ idValue = 465
+ length = 0.0005
+ Im = 1.3194689277e-08
+ x = 0.0005
+ z = 0.0
+
+Simulate and display current pulse to soma
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex2.0_currentPulse.py*
+
+A more useful script would run and display the model. Rdesigneur can
+help with the stimulus and the plotting. This simulation has the same
+passive compartment, and current is injected as the simulation runs.
+This script displays the membrane potential of the soma as it charges
+and discharges.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ stimList = [['soma', '1', '.', 'inject', '(t>0.1 && t<0.2) * 2e-8']],
+ plotList = [['soma', '1', '.', 'Vm', 'Soma membrane potential']],
+ )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+The *stimList* defines a stimulus. Each entry has five arguments:
+
+::
+
+ `[region_in_cell, region_expression, moose_object, parameter, expression_string]`
+
+- ``region_in_cell`` specifies the objects to stimulate. Here it is
+ just the soma.
+- ``region_expression`` specifies a geometry based calculation to
+ decide whether to apply the stimulus. The value must be >0 for the
+ stimulus to be present. Here it is just 1. ``moose_object`` specifies
+ the simulation object to operate upon during the stimulus. Here the
+ ``.`` means that it is the soma itself. In other models it might be a
+ channel on the soma, or a synapse, and so on.
+- ``parameter`` specifies the simulation parameter on the moose object
+ that the stimulus will modify. Here it is the injection current to
+ the soma compartment.
+- ``expression_string`` calculates the value of the parameter,
+ typically as a function of time. Here we use the function
+ ``(t>0.1 && t<0.2) * 2e-8`` which evaluates as 2e-8 between the times
+ of 0.1 and 0.2 seconds.
+
+To summarise this, the *stimList* here means *inject a current of 20nA
+to the soma between the times of 0.1 and 0.2 s*.
+
+The *plotList* defines what to plot. It has a similar set of arguments:
+
+::
+
+ `[region_in_cell, region_expression, moose_object, parameter, title_of_plot]`
+
+These mean the same thing as for the stimList except for the title of
+the plot.
+
+The *rdes.display()* function causes the plots to be displayed.
+
+.. figure:: ../../../../images/rdes2_passive_squid.png
+ :alt: Plot for current input to passive compartment
+
+ Plot for current input to passive compartment
+
+When we run this we see an initial depolarization as the soma settles
+from its initial -65 mV to a resting Em = -54.4 mV. These are the
+original HH values, see the example above. At t = 0.1 seconds there is
+another depolarization due to the current injection, and at t = 0.2
+seconds this goes back to the resting potential.
+
+Simulate and display voltage clamp stimulus to soma
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex2.1_vclamp.py*
+
+This model introduces the voltage clamp stimulus on a passive compartment.
+As before, we add a few lines to define the stimulus and plot.
+This script displays both the membrane potential, and the holding current
+of the voltage clamp circuit as
+it charges and discharges the passive compartment model.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ stimList = [['soma', '1', '.', 'vclamp', '-0.065 + (t>0.1 && t<0.2) * 0.02' ]],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Soma membrane potential'],
+ ['soma', '1', 'vclamp', 'current', 'Soma holding current'],
+ ]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+Here the *stimList* line tells the system to deliver a voltage clamp (vclamp)
+on the soma, starting at -65 mV and jumping up by 20 mV between 0.1 and 0.2
+seconds. The *plotList* now includes two entries, and will generate two plots.
+The first is for plotting the soma membrane potential, just to be sure that
+the voltage clamp is doing its job.
+
+.. figure:: ../../../../images/ex2.1_vclamp_a.png
+ :alt: Plot for membrane potential in voltage clamp
+
+ Plot for membrane potential in voltage clamp
+
+The second graph plots the holding current. Note the capacitive transients.
+
+.. figure:: ../../../../images/ex2.1_vclamp_b.png
+ :alt: Plot for holding current for voltage clamp
+
+ Plot for holding current for voltage clamp
+
+HH Squid model in a single compartment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex3.0_squid_currentPulse.py*
+
+Here we put the Hodgkin-Huxley squid model channels into a passive
+compartment. The HH channels are predefined as prototype channels for
+Rdesigneur,
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '1200' ],
+ ['K', 'soma', 'Gbar', '360' ]],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.1 && t<0.2) * 1e-8' ]],
+ plotList = [['soma', '1', '.', 'Vm', 'Membrane potential']]
+ )
+
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+Here we introduce two new model specification lines:
+
+- **chanProto**: This specifies which ion channels will be used in the
+ model. Each entry here has two fields: the source of the channel
+ definition, and (optionally) the name of the channel. In this example
+ we specify two channels, an Na and a K channel using the original
+ Hodgkin-Huxley parameters. As the source of the channel definition we
+ use the name of the Python function that builds the channel. The
+ *make\_HH\_Na()* and *make\_HH\_K()* functions are predefined but we
+ can also specify our own functions for making prototypes. We could
+ also have specified the channel prototype using the name of a channel
+ definition file in ChannelML (a subset of NeuroML) format.
+- **chanDistrib**: This specifies *where* the channels should be placed
+ over the geometry of the cell. Each entry in the chanDistrib list
+ specifies the distribution of parameters for one channel using four
+ entries:
+
+ ``[object_name, region_in_cell, parameter, expression_string]``
+
+ In this case the job is almost trivial, since we just have a single
+ compartment named *soma*. So the line
+
+ ``['Na', 'soma', 'Gbar', '1200' ]``
+
+ means *Put the Na channel in the soma, and set its maximal
+ conductance density (Gbar) to 1200 Siemens/m^2*.
+
+As before we apply a somatic current pulse. Since we now have HH
+channels in the model, this generates action potentials.
+
+.. figure:: ../../../../images/rdes3_squid.png
+ :alt: Plot for HH squid simulation
+
+ Plot for HH squid simulation
+
+There are several interesting things to do with the model by varying stimulus
+parameters:
+
+ - Change injection current.
+ - Put in a protocol to get rebound action potential.
+ - Put in a current ramp, and run it for a different duration
+ - Put in a frequency chirp, and see how the squid model is tuned
+ to a certain frequency range.
+ - Modify channel or passive parameters. See if it still fires.
+ - Try the frequency chirp on the cell with parameters changed. Does
+ the tuning change?
+
+
+HH Squid model with voltage clamp
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex3.1_squid_vclamp.py*
+
+This is the same squid model, but now we add a voltage clamp to the squid
+and monitor the holding current. This stimulus line is identical to ex2.1.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '1200' ],
+ ['K', 'soma', 'Gbar', '360' ]],
+ stimList = [['soma', '1', '.', 'vclamp', '-0.065 + (t>0.1 && t<0.2) * 0.02' ]],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Membrane potential'],
+ ['soma', '1', 'vclamp', 'current', 'Soma holding current']
+ ]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+Here we see the classic HH current response, a downward brief deflection due to
+the Na channel, and a slower upward sustained current due to the K delayed
+rectifier.
+
+.. figure:: ../../../../images/ex3.1_squid_vclamp.png
+ :alt: Plot for HH squid voltage clamp pulse.
+
+ Plot for HH squid voltage clamp pulse.
+
+Here are some suggestions for further exploration:
+
+ - Monitor individual channel currents through additional plots.
+ - Convert this into a voltage clamp series. Easiest way to do this is
+ to complete the rdes.BuildModel, then delete the Function object
+ on the */model/elec/soma/vclamp*. Now you can simply set the 'command'
+ field of the vclamp in a for loop, going from -ve to +ve voltages.
+ Remember, SI units. You may wish to capture the plot vectors each
+ cycle. The plot vectors are accessed by something like
+
+ ``moose.element( '/model/graphs/plot1' ).vector``
+
+
+HH Squid model in an axon
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex3.2_squid_axon_propgn.py*
+
+Here we put the Hodgkin-Huxley squid model into a long compartment that
+is subdivided into many segments, so that we can watch action potentials
+propagate. Most of this example is boilerplate code to build a spiral
+axon. There is a short *rdesigneur* segment that takes the spiral axon
+prototype and populates it with channels, and sets up the display. Later
+examples will show you how to read morphology files to specify the
+neuronal geometry.
+
+::
+
+ import numpy as np
+ import moose
+ import pylab
+ import rdesigneur as rd
+
+ numAxonSegments = 200
+ comptLen = 10e-6
+ comptDia = 1e-6
+ RM = 1.0
+ RA = 10.0
+ CM = 0.01
+
+ def makeAxonProto():
+ axon = moose.Neuron( '/library/axon' )
+ prev = rd.buildCompt( axon, 'soma', RM = RM, RA = RA, CM = CM, dia = 10e-6, x=0, dx=comptLen)
+ theta = 0
+ x = comptLen
+ y = 0.0
+
+ for i in range( numAxonSegments ):
+ dx = comptLen * np.cos( theta )
+ dy = comptLen * np.sin( theta )
+ r = np.sqrt( x * x + y * y )
+ theta += comptLen / r
+ compt = rd.buildCompt( axon, 'axon' + str(i), RM = RM, RA = RA, CM = CM, x = x, y = y, dx = dx, dy = dy, dia = comptDia )
+ moose.connect( prev, 'axial', compt, 'raxial' )
+ prev = compt
+ x += dx
+ y += dy
+
+ return axon
+
+ moose.Neutral( '/library' )
+ makeAxonProto()
+
+ rdes = rd.rdesigneur(
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ cellProto = [['elec','axon']],
+ chanDistrib = [
+ ['Na', '#', 'Gbar', '1200' ],
+ ['K', '#', 'Gbar', '360' ]],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.01 && t<0.2) * 2e-11' ]],
+ plotList = [['soma', '1', '.', 'Vm', 'Membrane potential']],
+ moogList = [['#', '1', '.', 'Vm', 'Vm (mV)']]
+ )
+
+ rdes.buildModel()
+ moose.reinit()
+
+ rdes.displayMoogli( 0.00005, 0.05, 0.0 )
+
+.. figure:: ../../../../images/ex3.2_axon_propagating_AP.png
+ :alt: Axon with propagating action potential
+
+ Axon with propagating action potential
+
+Note how we explicitly create the prototype axon on '/library', and then
+specify it using the *cellProto* line in the rdesigneur. The moogList
+specifies the 3-D display. See below for how to set up and use these
+displays.
+
+Action potential collision in HH Squid axon model
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex3.3_AP_collision.py*
+
+This is identical to the previous example, except that now we deliver current
+injection at at two points, the soma and a point along the axon. The modified
+stimulus line is:
+
+::
+
+ ...
+ stimList = [['soma', '1', '.', 'inject', '(t>0.01 && t<0.2) * 2e-11' ],
+ ['axon100', '1', '.', 'inject', '(t>0.01 && t<0.2) * 3e-11' ]],
+ ...
+
+Watch how the AP is triggered bidirectionally from the stimulus point on the
+100th segment of the axon, and observe what happens when two action potentials
+bump into each other.
+
+.. figure:: ../../../../images/ex3.3_AP_collision.png
+ :alt: Colliding action potentials
+
+ Colliding action potentials
+
+
+
+HH Squid model in a myelinated axon
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex3.4_myelinated_axon.py*
+
+This is a curious cross-species chimera model, where we embed the HH
+equations into a myelinated example model. As for the regular axon
+above, most of the example is boilerplate setup code. Note how we
+restrict the HH channels to the nodes of Ranvier using a conditional
+test for the diameter of the axon segment.
+
+::
+
+ import numpy as np
+ import moose
+ import pylab
+ import rdesigneur as rd
+
+ numAxonSegments = 405
+ nodeSpacing = 100
+ comptLen = 10e-6
+ comptDia = 2e-6 # 2x usual
+ RM = 100.0 # 10x usual
+ RA = 5.0
+ CM = 0.001 # 0.1x usual
+
+ nodeDia = 1e-6
+ nodeRM = 1.0
+ nodeCM = 0.01
+
+ def makeAxonProto():
+ axon = moose.Neuron( '/library/axon' )
+ x = 0.0
+ y = 0.0
+ prev = rd.buildCompt( axon, 'soma', RM = RM, RA = RA, CM = CM, dia = 10e-6, x=0, dx=comptLen)
+ theta = 0
+ x = comptLen
+
+ for i in range( numAxonSegments ):
+ r = comptLen
+ dx = comptLen * np.cos( theta )
+ dy = comptLen * np.sin( theta )
+ r = np.sqrt( x * x + y * y )
+ theta += comptLen / r
+ if i % nodeSpacing == 0:
+ compt = rd.buildCompt( axon, 'axon' + str(i), RM = nodeRM, RA = RA, CM = nodeCM, x = x, y = y, dx = dx, dy = dy, dia = nodeDia )
+ else:
+ compt = rd.buildCompt( axon, 'axon' + str(i), RM = RM, RA = RA, CM = CM, x = x, y = y, dx = dx, dy = dy, dia = comptDia )
+ moose.connect( prev, 'axial', compt, 'raxial' )
+ prev = compt
+ x += dx
+ y += dy
+
+ return axon
+
+ moose.Neutral( '/library' )
+ makeAxonProto()
+
+ rdes = rd.rdesigneur(
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ cellProto = [['elec','axon']],
+ chanDistrib = [
+ ['Na', '#', 'Gbar', '12000 * (dia < 1.5e-6)' ],
+ ['K', '#', 'Gbar', '3600 * (dia < 1.5e-6)' ]],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.01 && t<0.2) * 1e-10' ]],
+ plotList = [['soma,axon100,axon200,axon300,axon400', '1', '.', 'Vm', 'Membrane potential']],
+ moogList = [['#', '1', '.', 'Vm', 'Vm (mV)']]
+ )
+
+ rdes.buildModel()
+
+ for i in moose.wildcardFind( "/model/elec/#/Na" ):
+ print i.parent.name, i.Gbar
+
+ moose.reinit()
+
+ rdes.displayMoogli( 0.00005, 0.05, 0.0 )
+
+When you run the example, keep an eye out for a few things:
+
+- **saltatory conduction:** This is the way the action potential jumps
+ from one node of Ranvier to the next. Between the nodes it is just
+ passive propagation.
+- **Failure to propagate:** Observe that the second and fourth action
+ potentials fails to trigger propagation along the axon. Here we have
+ specially tuned the model properties so that this happens. With a
+ larger RA of 10.0, the model will be more reliable.
+- **Speed:** Compare the propagation speed with the previous,
+ unmyelinated axon. Note that the current model is larger!
+
+.. figure:: ../../../../images/rdes3.2_myelinated_axon.png
+ :alt: Myelinated axon with propagating action potential
+
+ Myelinated axon with propagating action potential
+
+Alternate (non-squid) way to define soma
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex4.0_scaledSoma.py*
+
+The default HH-squid axon is not a very convincing soma. Rdesigneur offers a
+somewhat more general way to define the soma in the cell prototype line.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ # cellProto syntax: ['somaProto', 'name', dia, length]
+ cellProto = [['somaProto', 'soma', 20e-6, 200e-6]],
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '1200' ],
+ ['K', 'soma', 'Gbar', '360' ]],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.01 && t<0.05) * 1e-9' ]],
+ plotList = [['soma', '1', '.', 'Vm', 'Membrane potential']],
+ moogList = [['#', '1', '.', 'Vm', 'Vm (mV)']]
+ )
+
+ rdes.buildModel()
+ soma = moose.element( '/model/elec/soma' )
+ print( 'Soma dia = {}, length = {}'.format( soma.diameter, soma.length ) )
+ moose.reinit()
+
+ rdes.displayMoogli( 0.0005, 0.06, 0.0 )
+
+Here the crucial line is the *cellProto* line. There are four arguments here:
+
+ ``['somaProto', 'name', dia, length]``
+
+ - The first argument tells the system to use a prototype soma, that is
+ a single cylindrical compartment.
+ - The second argument is the name to give the cell.
+ - The third argument is the diameter. Note that this is a double,
+ not a string.
+ - The fourth argument is the length of the cylinder that makes up the
+ soma. This too is a double, not a string.
+ The cylinder is oriented along the x axis, with one end at (0,0,0)
+ and the other end at (length, 0, 0).
+
+This is what the soma looks like:
+
+.. figure:: ../../../../images/ex4.0_scaledSoma.png
+ :alt: Image of soma.
+
+ Image of soma.
+
+It a somewhat elongated soma, being a cylinder 10 times as long as it is wide.
+
+Ball-and-stick model of a neuron
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex4.1_ballAndStick.py*
+
+A somewhat more electrically reasonable model of a neuron has a soma and a
+single dendrite, which can itself be subdivided into segments so that it
+can exhibit voltage gradients, have channel and receptor distributions,
+and so on. This is accomplished in *rdesigneur* using a variant of the
+cellProto syntax.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ # cellProto syntax: ['ballAndStick', 'name', somaDia, somaLength, dendDia, dendLength, numDendSegments ]
+ # The numerical arguments are all optional
+ cellProto = [['ballAndStick', 'soma', 20e-6, 20e-6, 4e-6, 500e-6, 10]],
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '1200' ],
+ ['K', 'soma', 'Gbar', '360' ],
+ ['Na', 'dend#', 'Gbar', '400' ],
+ ['K', 'dend#', 'Gbar', '120' ]
+ ],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.01 && t<0.05) * 1e-9' ]],
+ plotList = [['soma', '1', '.', 'Vm', 'Membrane potential']],
+ moogList = [['#', '1', '.', 'Vm', 'Vm (mV)']]
+ )
+ rdes.buildModel()
+ soma = moose.element( '/model/elec/soma' )
+ moose.reinit()
+ rdes.displayMoogli( 0.0005, 0.06, 0.0 )
+
+As before, the *cellProto* line plays a key role. Here, because we have a long
+dendrite, we have a few more numerical arguments. All of the numerical
+arguments are optional.
+
+ ``['ballAndStick', 'name', somaDia, somaLength, dendDia, dendLength, numDendSegments ]``
+
+ - The first argument specifies a ballAndStick model: soma + dendrite.
+ The length of the dendrite is along the x axis. The soma is a single
+ segment, the dendrite can be more than one.
+ - The second argument is the name to give the cell.
+ - Arg 3 is the soma diameter, as a double.
+ - Arg 4 is the length of the soma, as a double.
+ - Arg 5 is the diameter of the dendrite, as a double.
+ - Arg 6 is the length of the dendrite, as a double.
+ - Arg 7 is the number of segments into which the dendrite should be
+ divided. This is a positive integer greater than 0.
+
+This is what the ball-and-stick cell looks like:
+
+.. figure:: ../../../../images/ex4.1_ballAndStick.png
+ :alt: Image of ball and stick cell.
+
+ Image of ball and stick cell.
+
+In this version of the 3-D display, the soma is displayed as a bit blocky
+rather than round.
+Note that we have populated the dendrite with Na and K channels and it has
+10 segments, so it supports action potential propagation. The snapshot
+illustrates this.
+
+Here are some things to try:
+
+ - Change the length of the dendrite
+ - Change the number of segments. Explore what it does to accuracy. How
+ will you know that you have an accurate model?
+
+Benchmarking simulation speed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex4.2_ballAndStickSpeed.py*
+
+The ball-and-stick model gives us an opportunity to check out your system
+and how computation scales with model size. While we're at it we'll deliver
+a sine-wave stimulus just to see how it can be done. The test model is
+very similar to the previous one, ex4.1:
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ import time
+ rdes = rd.rdesigneur(
+ cellProto = [['ballAndStick', 'soma', 20e-6, 20e-6, 4e-6, 500e-6, 10]],
+ chanProto = [['make_HH_Na()', 'Na'], ['make_HH_K()', 'K']],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '1200' ],
+ ['K', 'soma', 'Gbar', '360' ],
+ ['Na', 'dend#', 'Gbar', '400' ],
+ ['K', 'dend#', 'Gbar', '120' ]
+ ],
+ stimList = [['soma', '1', '.', 'inject', '(1+cos(t/10))*(t>31.4 && t<94) * 0
+ .2e-9' ]],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Membrane potential'],
+ ['soma', '1', '.', 'inject', 'Stimulus current']
+ ],
+ )
+ rdes.buildModel()
+ runtime = 100
+ moose.reinit()
+ t0= time.time()
+ moose.start( runtime )
+ print "Real time to run {} simulated seconds = {} seconds".format( runtime, time
+ .time() - t0 )
+
+ rdes.display()
+
+While the real point of this simulation is to check speed, it does illustrate
+how to deliver a stimulus shaped like a sine wave:
+
+.. figure:: ../../../../images/ex4.2_sine_stim.png
+ :alt: Sine-wave shaped stimulus.
+
+ Sine-wave shaped stimulus.
+
+We can see that the cell has a peculiar response to this. Not surprising, as
+the cell uses HH channels which are not good at rate coding.
+
+.. figure:: ../../../../images/ex4.2_spiking.png
+ :alt: Spiking response to sine-wave shaped stimulus.
+
+ Spiking response to sine-wave shaped stimulus.
+
+As a reference point, on a fast 2018 laptop this benchmark runs in 5.4 seconds.
+Some more things to try for benchmarking:
+
+ - How slow does it get if you turn on the 3-D moogli display?
+ - Is it costlier to run 2 compartments for 1000 seconds, or
+ 200 compartments for 10 seconds?
+
+Synaptic stimulus: random (Possion)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex5.0_random_syn_input.py*
+
+In this example we introduce synaptic inputs: both the receptor channels
+and a means for stimulating the channels. We do this in a passive model.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ cellProto = [['somaProto', 'soma', 20e-6, 200e-6]],
+ chanProto = [['make_glu()', 'glu']],
+ chanDistrib = [['glu', 'soma', 'Gbar', '1' ]],
+ stimList = [['soma', '0.5', 'glu', 'randsyn', '50' ]],
+ # Deliver stimulus to glu synapse on soma, at mean 50 Hz Poisson.
+ plotList = [['soma', '1', '.', 'Vm', 'Soma membrane potential']]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+Most of the rdesigneur setup uses familiar syntax.
+
+Novelty 1: we use the default built-in glutamate receptor model, in chanProto.
+We just put it in the soma at a max conductance of 1 Siemen/sq metre.
+
+Novelty 2: We specify a new kind of stimulus in the stimList:
+
+ ``['soma', '0.5', 'glu', 'randsyn', '50' ]``
+
+Most of this is similar to previous stimLists.
+
+ - arg0: 'soma': the named compartments in the cell to populate with
+ the *glu* receptor
+ - arg1: '0.5': Tell the system to use a uniform synaptic weight of 0.5.
+ This argument could be a more complicated expression incorporating
+ spatial arguments. Here it is just uniform.
+ - arg2: 'glu': Which receptor to stimulate
+ - arg3: 'randsyn': Apply random (Poisson) synaptic input.
+ - arg4: '50': Mean firing rate of the Poisson input. Note that this last
+ argument could be a function of time and hence is quite versatile.
+
+As the model has no voltage-gated channels, we do not see spiking.
+
+.. figure:: ../../../../images/ex5.0_random_syn_input.png
+ :alt: Random synaptic input with a Poisson distribution.
+
+ Random synaptic input with a Poisson distribution.
+
+Things to try: Vary the rate and the weight of the synaptic input.
+
+Synaptic stimulus: periodic
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex5.1_periodic_syn_input.py*
+
+This is almost identical to 5.0, except that the input is now perfectly
+periodic. The one change is of an argument in the stimList to say
+``periodicsyn`` rather than ``randsyn``.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ cellProto = [['somaProto', 'soma', 20e-6, 200e-6]],
+ chanProto = [['make_glu()', 'glu']],
+ chanDistrib = [['glu', 'soma', 'Gbar', '1' ]],
+
+ # Deliver stimulus to glu synapse on soma, periodically at 50 Hz.
+ stimList = [['soma', '0.5', 'glu', 'periodicsyn', '50' ]],
+ plotList = [['soma', '1', '.', 'Vm', 'Soma membrane potential']]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 0.3 )
+ rdes.display()
+
+As designed, we get periodically firing synaptic input.
+
+.. figure:: ../../../../images/ex5.1_periodic_syn_input.png
+ :alt: Periodic synaptic input
+
+ Periodic synaptic input
+
+
+Reaction system in a single compartment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex6_chem_osc.py*
+
+Here we use the compartment as a place in which to embed a chemical
+model. The chemical oscillator model is predefined in the rdesigneur
+prototypes. Its general form is:
+
+::
+
+ s ---a---> a // s goes to a, catalyzed by a.
+ s ---a---> b // s goes to b, catalyzed by a.
+ a ---b---> s // a goes to s, catalyzed by b.
+ b -------> s // b is degraded irreversibly to s
+
+Here is the script:
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ diffusionLength = 1e-3, # Default diffusion length is 2 microns
+ chemProto = [['makeChemOscillator()', 'osc']],
+ chemDistrib = [['osc', 'soma', 'install', '1' ]],
+ plotList = [['soma', '1', 'dend/a', 'conc', 'a Conc'],
+ ['soma', '1', 'dend/b', 'conc', 'b Conc']]
+ )
+ rdes.buildModel()
+ b = moose.element( '/model/chem/dend/b' )
+ b.concInit *= 5
+ moose.reinit()
+ moose.start( 200 )
+
+ rdes.display()
+
+In this special case we set the turnOffElec flag to True, so that
+Rdesigneur only sets up chemical and not electrical calculations. This
+makes the calculations much faster, since we disable electrical
+calculations and delink chemical calculations from them.
+
+We also have a line which sets the ``diffusionLength`` to 1 mm, so that
+it is bigger than the 0.5 mm squid axon segment in the default
+compartment. If you don't do this the system will subdivide the
+compartment into the default 2 micron voxels for the purposes of putting
+in a reaction-diffusion system. We discuss this case below.
+
+Note how the *plotList* is done here. To remind you, each entry has five
+arguments
+
+::
+
+ [region_in_cell, region_expression, moose_object, parameter, title_of_plot]
+
+The change from the earlier usage is that the ``moose_object`` now
+refers to a chemical entity, in this example the molecule *dend/a*. The
+simulator builds a default chemical compartment named *dend* to hold the
+reactions defined in the *chemProto*. What we do in this plot is to
+select molecule *a* sitting in *dend*, and plot its concentration. Then
+we do this again for molecule *b*.
+
+After the model is built, we add a couple of lines to change the initial
+concentration of the molecular pool *b*. Note its full path within
+MOOSE: */model/chem/dend/b*. It is scaled up 5x to give rise to slowly
+decaying oscillations.
+
+.. figure:: ../../../../images/rdes4_osc.png
+ :alt: Plot for single-compartment reaction simulation
+
+ Plot for single-compartment reaction simulation
+
+Reaction-diffusion system
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.0_spatial_chem_osc.py*
+
+In order to see what a reaction-diffusion system looks like, we assign the
+``diffusionLength`` expression in the previous example to a much shorter
+length, and add a couple of lines to set up 3-D graphics for the
+reaction-diffusion product:
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ #This subdivides the length of the soma into 2 micron voxels
+ diffusionLength = 2e-6,
+ chemProto = [['makeChemOscillator()', 'osc']],
+ chemDistrib = [['osc', 'soma', 'install', '1' ]],
+ plotList = [['soma', '1', 'dend/a', 'conc', 'Concentration of a'],
+ ['soma', '1', 'dend/b', 'conc', 'Concentration of b']],
+ moogList = [['soma', '1', 'dend/a', 'conc', 'a Conc', 0, 360 ]]
+ )
+
+ rdes.buildModel()
+ bv = moose.vec( '/model/chem/dend/b' )
+ bv[0].concInit *= 2
+ bv[-1].concInit *= 2
+ moose.reinit()
+
+ rdes.displayMoogli( 1, 400, rotation = 0, azim = np.pi/2, elev = 0.0 )
+
+This is the new value for diffusion length.
+
+::
+
+ diffusionLength = 2e-3,
+
+With this change we tell *rdesigneur* to use the diffusion length of 2 microns.
+This happens to be the default too. The 500-micron axon segment is now
+subdivided into 250 voxels, each of which has a reaction system and
+diffusing molecules.
+To make it more picturesque, we have added a line after the plotList, to
+display the outcome in 3-D:
+
+::
+
+ moogList = [['soma', '1', 'dend/a', 'conc', 'a Conc', 0, 360 ]]
+
+This line says: take the model compartments defined by ``soma`` as the
+region to display, do so throughout the the geometry (the ``1``
+signifies this), and over this range find the chemical entity defined by
+``dend/a``. For each ``a`` molecule, find the ``conc`` and dsiplay it.
+There are two optional arguments, ``0`` and ``360``, which specify the
+low and high value of the displayed variable.
+
+In order to initially break the symmetry of the system, we change the
+initial concentration of molecule b at each end of the cylinder:
+
+::
+
+ bv[0].concInit *= 2
+ bv[-1].concInit *= 2
+
+If we didn't do this the entire system would go through a few cycles of
+decaying oscillation and then reach a boring, spatially uniform, steady
+state. Try putting an initial symmetry break elsewhere to see what
+happens.
+
+To display the concenctration changes in the 3-D soma as the simulation
+runs, we use the line
+
+::
+
+ rdes.displayMoogli( 1, 400, rotation = 0, azim = np.pi/2, elev = 0.0 )
+
+The arguments mean: *displayMoogli( frametime, runtime, rotation, azimuth, elevation )*
+Here,
+
+::
+
+ frametime = time by which simulation advances between display updates
+ runtime = Total simulated time
+ rotation = angle by which display rotates in each frame, in radians.
+ azimuth = Azimuth angle of view point, in radians
+ elevation = elevation angle of view point, in radians
+
+When we run this, we first get a 3-D display with the oscillating
+reaction-diffusion system making its way inward from the two ends. After
+the simulation ends the plots for all compartments for the whole run
+come up.
+
+.. figure:: ../../../../images/rdes5_reacdiff.png
+ :alt: Display for oscillatory reaction-diffusion simulation
+
+ Display for oscillatory reaction-diffusion simulation
+
+For those who would rather use the much simpler matplotlib 3-D display option,
+this is what the same simulation looks like:
+
+.. figure:: ../../../../images/ex7.0_spatial_chem_osc.png
+ :alt: Display for oscillatory reac-diff simulation using matplotlib
+
+ Display for oscillatory reac-diff simulation using matplotlib
+
+
+.. _`moogli primer`:
+
+Primer on using the 3-D MOOGLI display
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are two variants of the MOOGLI display. The first, named Moogli,
+uses OpenGL and OpenSceneGraph. It is fast to display, slow to load, and
+difficult to compile. It produces much better looking 3-D graphics.
+The second is a fallback interface using mplot3d, which is a library of
+Matplotlib and so should be generally available. It is slower to display,
+faster to load, but needs no special compilation. It uses stick graphics
+and though it conveys much the same information, isn't as nice to look at
+as the original Moogli. Its controls are more or less the same but less
+smooth than the original Moogli.
+
+Here is a short primer on the 3-D display controls.
+
+- *Roll, pitch, and yaw*: Use the letters *r*, *p*, and *y*. To rotate
+ backwards, use capitals.
+- *Zoom out and in*: Use the *,* and *.* keys, or their upper-case
+ equivalents, *<* and *>*. Easier to remember if you think in terms of
+ the upper-case.
+- *Left/right/up/down*: Arrow keys.
+- *Quit*: control-q or control-w.
+- You can also use the mouse or trackpad to control most of the above.
+- By default rdesigneur gives Moogli a small rotation each frame. It is
+ the *rotation* argument in the line:
+
+ ``displayMoogli( frametime, runtime, rotation )``
+
+These controls operate over and above this rotation, but the rotation
+continues. If you set the rotation to zero you can, with a suitable
+flick of the mouse, get the image to rotate in any direction you choose
+as long as the window is updating.
+
+Diffusion of a single molecule
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.1_diffusive_gradient.py*
+
+This is simply a test model to confirm that simple diffusion happens as
+expected. While the model is just that of a single pool, we spend a few lines
+taking snapshots of the spatial profile of this pool.
+
+::
+
+ import moose
+ import pylab
+ import re
+ import rdesigneur as rd
+ import matplotlib.pyplot as plt
+ import numpy as np
+
+ moose.Neutral( '/library' )
+ moose.Neutral( '/library/diffn' )
+ moose.CubeMesh( '/library/diffn/dend' )
+ A = moose.Pool( '/library/diffn/dend/A' )
+ A.diffConst = 1e-10
+
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ diffusionLength = 1e-6,
+ chemProto = [['diffn', 'diffn']],
+ chemDistrib = [['diffn', 'soma', 'install', '1' ]],
+ moogList = [
+ ['soma', '1', 'dend/A', 'conc', 'A Conc', 0, 360 ]
+ ]
+ )
+ rdes.buildModel()
+
+ rdes.displayMoogli( 1, 2, rotation = 0, azim = -np.pi/2, elev = 0.0, block = False )
+ av = moose.vec( '/model/chem/dend/A' )
+ for i in range(10):
+ av[i].concInit = 1
+ moose.reinit()
+ plist = []
+ for i in range( 20 ):
+ plist.append( av.conc[:200] )
+ moose.start( 2 )
+ fig = plt.figure( figsize = ( 10, 12 ) )
+ plist = np.array( plist ).T
+ plt.plot( range( 0, 200 ), plist )
+ plt.xlabel( "position ( microns )" )
+ plt.ylabel( "concentration ( mM )" )
+ plt.show( block = True )
+
+
+Here are the snapshots, overlaid in a single plot:
+
+.. figure:: ../../../../images/ex7.1_diffusive_gradient.png
+ :alt: Display of how a molecule A spreads through the inter
+
+ Display for simple time-series of spread of a diffusing molecule
+ using matplotlib
+
+Calcium-induced calcium release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _`models of calcium-induced calcium release`:
+
+*ex7.2_CICR.py*
+
+This is a somewhat more complex reaction-diffusion system, involving calcium
+release from intracellular stores that propagates in a wave of activity along
+a dendrite. This example demonstrates the use of endo compartments.
+
+Endo-compartments, as the name suggests, represent compartments that sit
+within other cellular compartments. If the surround compartment is subdivided
+into N voxels, so is the endo- compartment. The rdesigneur system looks at the
+provided model, and if there are 2 compartments and the *addEndoChemCompt* flag
+is True, then the chemistry contained in the smaller of the two compartments is
+positioned in an endo compartment surrounded by the first compartment.
+Here we use the endo-compartment to represent the endoplasmic reticulum sitting
+inside the dendrite.
+
+In the chemical model, we also introduce a new MOOSE class,
+ConcChan. These act as membrane pores whose permeability scales with
+number of channels in the open state. The IP3 receptor in this model is
+implemented as a ConcChan which opens due to binding to IP3 and Calcium.
+This leads to the release of more calcium from the ER, and this feedback
+loop develops into a propagating-wave oscillation.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ chemDt = 0.005,
+ chemPlotDt = 0.02,
+ diffusionLength = 1e-6,
+ useGssa = False,
+ addSomaChemCompt = False,
+ addEndoChemCompt = True,
+ # cellProto syntax: ['somaProto', 'name', dia, length]
+ cellProto = [['somaProto', 'soma', 2e-6, 10e-6]],
+ chemProto = [['./chem/CICRwithConcChan.g', 'chem']],
+ chemDistrib = [['chem', 'soma', 'install', '1' ]],
+ plotList = [
+ ['soma', '1', 'dend/CaCyt', 'conc', 'Dendritic Ca'],
+ ['soma', '1', 'dend/CaCyt', 'conc', 'Dendritic Ca', 'wave'],
+ ['soma', '1', 'dend_endo/CaER', 'conc', 'ER Ca'],
+ ['soma', '1', 'dend/ActIP3R', 'conc', 'active IP3R'],
+ ],
+ )
+ rdes.buildModel()
+ IP3 = moose.element( '/model/chem/dend/IP3' )
+ IP3.vec.concInit = 0.004
+ IP3.vec[0].concInit = 0.02
+ moose.reinit()
+ moose.start( 40 )
+ rdes.display()
+
+Note how the dendritic calcium is displayed both as a time-series plot and
+as a wave plot, which presents the time-evolution of the calcium as a function
+of position in successive image frames.
+
+.. figure:: ../../../../images/ex7.2_CICR_static.png
+ :alt: Time-series plot of dendritic calcium. Different colors represent
+ different voxels in the dendrite.
+
+ Time-series plot of dendritic calcium. Different colors represent
+ different voxels in the dendrite.
+
+.. figure:: ../../../../images/ex7.2_CICR_wave_lastFrame.png
+
+ Place holder for time-evolving movie of dendritic calcium as a function of
+ position along the dendrite.
+
+
+Intracellular transport
+~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.3_simple_transport.py*
+
+This illustrates how intracellular transport works in MOOSE. We have a
+an elongated soma in which molecules start out at the left and are transported
+to the right. Note that they spread out as they go along,
+This is because the transport is implemented as drift-diffusion, in which a
+fraction of the molecules move to the next location each timestep. The
+equation is
+
+ ``flux = motorConst * conc / spacing``
+
+for a uniform cylinder. MOOSE applies suitable scaling terms if the neuronal
+geometry is non-uniform.
+
+::
+
+ import moose
+ import numpy as np
+ import pylab
+ import rdesigneur as rd
+
+ moose.Neutral( '/library' )
+ moose.Neutral( '/library/transp' )
+ moose.CubeMesh( '/library/transp/dend' )
+ A = moose.Pool( '/library/transp/dend/A' )
+ A.diffConst = 0
+ A.motorConst = 1e-6 # Metres/sec
+
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ #This subdivides the length of the soma into 0.5 micron voxels
+ diffusionLength = 0.5e-6,
+ cellProto = [['somaProto', 'soma', 2e-6, 50e-6]],
+ chemProto = [['transp', 'transp']],
+ chemDistrib = [['transp', 'soma', 'install', '1' ]],
+ plotList = [
+ ['soma', '1', 'dend/A', 'conc', 'Concentration of A'],
+ ['soma', '1', 'dend/A', 'conc', 'Concentration of A', 'wave'],
+ ],
+ moogList = [['soma', '1', 'dend/A', 'conc', 'A Conc', 0, 20 ]]
+ )
+ rdes.buildModel()
+ moose.element( '/model/chem/dend/A[0]' ).concInit = 0.1
+ moose.reinit()
+ rdes.displayMoogli( 1, 80, rotation = 0, azim = -np.pi/2, elev = 0.0 )
+
+In this example we explicitly create the single-molecule reaction system,
+and assign a motorConst of 1 micron/sec to the molecule A. We start off with
+all the molecules in a single voxel on the left of the cylinder, and then
+watch the molecules move.
+Once the molecules reach the end of the cylindrical soma, they have nowhere
+further to go so they pile up.
+
+.. figure:: ../../../../images/ex7.3_1.png
+ :alt: Transport frame 1.
+.. figure:: ../../../../images/ex7.3_2.png
+ :alt: Transport frame 2.
+.. figure:: ../../../../images/ex7.3_3.png
+ :alt: Transport frame 3.
+.. figure:: ../../../../images/ex7.3_4.png
+ :alt: Transport frame 4.
+.. figure:: ../../../../images/ex7.3_5.png
+ :alt: Transport frame 5.
+.. figure:: ../../../../images/ex7.3_6.png
+ :alt: Transport frame 6.
+
+ Frames at increasing intervals from the transport simulation showing
+ spreading and piling up of the molecule at the right end of the cylinder.
+
+Suggestions:
+
+ - Play with different motor rates.
+ - The motor constant sign detemines the direction of transport. See
+ what happens if you get it going in the opposite direction.
+ - Consider how you could avoid the buildup in the last voxel.
+ - Consider how to achieve a nice exponential falloff over a
+ much longer range than possible with diffusion.
+
+Travelling oscillator
+~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.4_travelling_osc.py*
+
+Here we put a chemical oscillator into a cylinder, and activate motor transport
+in one of the molecules. The oscillatory zone slowly moves to the right, with
+an amplification in the last compartment due to end-effects.
+
+::
+
+ import moose
+ import numpy as np
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ diffusionLength = 2e-6,
+ chemProto = [['makeChemOscillator()', 'osc']],
+ chemDistrib = [['osc', 'soma', 'install', '1' ]],
+ plotList = [
+ ['soma', '1', 'dend/a', 'conc', 'Concentration of a'],
+ ['soma', '1', 'dend/b', 'conc', 'Concentration of b'],
+ ['soma', '1', 'dend/a', 'conc', 'Concentration of a', 'wave'],
+ ],
+ moogList = [['soma', '1', 'dend/a', 'conc', 'a Conc', 0, 360 ]]
+ )
+ a = moose.element( '/library/osc/kinetics/a' )
+ b = moose.element( '/library/osc/kinetics/b' )
+ s = moose.element( '/library/osc/kinetics/s' )
+ a.diffConst = 0
+ b.diffConst = 0
+ a.motorConst = 1e-6
+
+ rdes.buildModel()
+ moose.reinit()
+
+ rdes.displayMoogli( 1, 400, rotation = 0, azim = -np.pi/2, elev = 0.0 )
+
+.. figure:: ../../../../images/ex7.4_travelling_osc.png
+ :alt: Travelling Oscillator
+
+ Snapshot of travelling oscillator waveform at t = 198.
+
+Suggestions:
+
+ - What happens if all molecules undergo transport?
+ - What happens if b is transported opposite to a?
+ - What happens if there is also diffusion?
+
+Bidirectional transport
+~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.5_bidirectional_transport.py*
+
+This is almost identical to ex7.4, except that we implement bidirectional
+transport. Molecule a goes from left to right, and b and s go from
+right to left. Here we see that the system builds up with large oscillations
+in the middle as the molecules converge, then the peaks collapse when
+the molecules go away.
+
+::
+
+ import moose
+ import numpy as np
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ diffusionLength = 2e-6,
+ numWaveFrames = 50,
+ chemProto = [['makeChemOscillator()', 'osc']],
+ chemDistrib = [['osc', 'soma', 'install', '1' ]],
+ plotList = [
+ ['soma', '1', 'dend/a', 'conc', 'Concentration of a', 'wave', 0, 1800],
+ ['soma', '1', 'dend/b', 'conc', 'Concentration of b', 'wave', 0, 500],
+ ['soma', '1', 'dend/s', 'conc', 'Concentration of s', 'wave', 0, 1200],
+ ],
+ moogList = [['soma', '1', 'dend/a', 'conc', 'a Conc', 0, 600 ]]
+ )
+ a = moose.element( '/library/osc/kinetics/a' )
+ b = moose.element( '/library/osc/kinetics/b' )
+ s = moose.element( '/library/osc/kinetics/s' )
+ a.diffConst = 0
+ b.diffConst = 0
+ a.motorConst = 2e-6
+ b.motorConst = -2e-6
+ s.motorConst = -2e-6
+
+ rdes.buildModel()
+ moose.reinit()
+
+ rdes.displayMoogli( 1, 250, rotation = 0, azim = -np.pi/2, elev = 0.0 )
+
+.. figure:: ../../../../images/ex7.5_a.png
+ :alt: Travelling Oscillator molecule a
+
+.. figure:: ../../../../images/ex7.5_b.png
+ :alt: Travelling Oscillator molecule b
+
+.. figure:: ../../../../images/ex7.5_s.png
+ :alt: Travelling Oscillator molecule
+
+Above we see *a*, *b*, *s* at a point where the transport has collected the
+molecules toward the middle of the cylinder, so the oscillations are large.
+Below we see molecule *a* later, when it has gone past the *b* and *s* pools
+and so the reaction system is depleted and does not oscillate.
+
+.. figure:: ../../../../images/ex7.5_a_later.png
+ :alt: Travelling Oscillator molecule a later.
+
+Controlling a reaction by a function
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex7.6_func_controls_reac_rate.py*
+
+This example illustrates how a function can be used to control a reaction
+rate. This kind of calculation is appropriate when we need to link
+different kinds of physical processses with chemical reactions, for
+example, membrane curvature with molecule accumulation. The use of
+functions to modify reaction rates should be avoided in purely chemical
+systems since they obscure the underlying chemistry, and do not map
+cleanly to stochastic calculations.
+
+In this example we simply have a molecule C that controls the forward
+rate of a reaction that converts A to B. C is a function of location
+on the cylinder, and is fixed. In more elaborate computations we could
+have a function of multiple molecules, some of which could be changing and
+others could be buffered.
+
+::
+
+ import numpy as np
+ import moose
+ import pylab
+ import rdesigneur as rd
+
+
+ def makeFuncRate():
+ model = moose.Neutral( '/library' )
+ model = moose.Neutral( '/library/chem' )
+ compt = moose.CubeMesh( '/library/chem/compt' )
+ compt.volume = 1e-15
+ A = moose.Pool( '/library/chem/compt/A' )
+ B = moose.Pool( '/library/chem/compt/B' )
+ C = moose.Pool( '/library/chem/compt/C' )
+ reac = moose.Reac( '/library/chem/compt/reac' )
+ func = moose.Function( '/library/chem/compt/reac/func' )
+ func.x.num = 1
+ func.expr = "(x0/1e8)^2"
+ moose.connect( C, 'nOut', func.x[0], 'input' )
+ moose.connect( func, 'valueOut', reac, 'setNumKf' )
+ moose.connect( reac, 'sub', A, 'reac' )
+ moose.connect( reac, 'prd', B, 'reac' )
+
+ A.concInit = 1
+ B.concInit = 0
+ C.concInit = 0
+ reac.Kb = 1
+
+ makeFuncRate()
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ #This subdivides the 50-micron cylinder into 2 micron voxels
+ diffusionLength = 2e-6,
+ cellProto = [['somaProto', 'soma', 5e-6, 50e-6]],
+ chemProto = [['chem', 'chem']],
+ chemDistrib = [['chem', 'soma', 'install', '1' ]],
+ plotList = [['soma', '1', 'dend/A', 'conc', 'A conc', 'wave'],
+ ['soma', '1', 'dend/C', 'conc', 'C conc', 'wave']],
+ )
+ rdes.buildModel()
+ C = moose.element( '/model/chem/dend/C' )
+ C.vec.concInit = [ 1+np.sin(x/5.0) for x in range( len(C.vec) ) ]
+ moose.reinit()
+ moose.start(10)
+ rdes.display()
+
+We plot the controlling molecule C and the substrate molecule A as
+functions of position, using a waveplot. C remains fixed, and A
+decreases with time and space. A is smallest at about voxel 8, where the
+reaction rate, as controlled by C, is highest.
+
+.. figure:: ../../../../images/ex7.6_C.png
+ :alt: Concentration of control molecule C
+.. figure:: ../../../../images/ex7.6_A.png
+ :alt: Concentration of substrate molecule A
+
+
+
+Multiscale models: single compartment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex8.0_multiscale_KA_phosph.py*
+
+The next few examples are for the multiscale modeling that is the main purpose
+of rdesigneur and MOOSE as a whole. These are 'toy' examples in that the
+chemical and electrical signaling is simplified, but they exhibit dynamics
+that are of real interest.
+
+The first example is of a bistable system where the feedback loop comprises of
+
+`calcium influx -> chemical activity -> channel modulation -> electrical activity -> calcium influx.`
+
+Calcium enters through voltage gated calcium channels, leads to enzyme
+activation and phosphorylation of a KA channel, which depolarizes the cell,
+so it spikes more, so more calcium enters.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ elecDt = 50e-6,
+ chemDt = 0.002,
+ chemPlotDt = 0.002,
+ # cellProto syntax: ['somaProto', 'name', dia, length]
+ cellProto = [['somaProto', 'soma', 12e-6, 12e-6]],
+ chemProto = [['./chem/chanPhosphByCaMKII.g', 'chem']],
+ chanProto = [
+ ['make_Na()', 'Na'],
+ ['make_K_DR()', 'K_DR'],
+ ['make_K_A()', 'K_A' ],
+ ['make_Ca()', 'Ca' ],
+ ['make_Ca_conc()', 'Ca_conc' ]
+ ],
+ # Some changes to the default passive properties of the cell.
+ passiveDistrib = [['soma', 'CM', '0.03', 'Em', '-0.06']],
+ chemDistrib = [['chem', 'soma', 'install', '1' ]],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '300' ],
+ ['K_DR', 'soma', 'Gbar', '250' ],
+ ['K_A', 'soma', 'Gbar', '200' ],
+ ['Ca_conc', 'soma', 'tau', '0.0333' ],
+ ['Ca', 'soma', 'Gbar', '40' ]
+ ],
+ adaptorList = [
+ [ 'dend/chan', 'conc', 'K_A', 'modulation', 0.0, 70 ],
+ [ 'Ca_conc', 'Ca', 'dend/Ca', 'conc', 0.00008, 2 ]
+ ],
+ # Give a + pulse from 5 to 7s, and a - pulse from 20 to 21.
+ stimList = [['soma', '1', '.', 'inject', '((t>5 && t<7) - (t>20 && t<21)) * 1.0e-12' ]],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Membrane potential'],
+ ['soma', '1', '.', 'inject', 'current inj'],
+ ['soma', '1', 'K_A', 'Ik', 'K_A current'],
+ ['soma', '1', 'dend/chan', 'conc', 'Unphosph K_A conc'],
+ ['soma', '1', 'dend/Ca', 'conc', 'Chem Ca'],
+ ],
+ )
+
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 30 )
+
+ rdes.display()
+
+There is only one fundamentally new element in this script:
+
+**adaptor List:** `[source, sourceField, dest, destField, offset, scale]`
+The adaptor list maps between molecular, electrical or even structural
+quantities in the simulation. At present it is linear mapping, in due course
+it may evolve to an arbitrary function.
+
+The two adaptorLists in the above script do the following:
+
+ ``[ 'dend/chan', 'conc', 'K_A', 'modulation', 0.0, 70 ]``:
+
+Use the concentration of the 'chan' molecule in the 'dend' compartment,
+to modulate the conductance of the 'K_A' channel such that the basal
+conductance is zero and 1 millimolar of 'chan' results in a conductance that is
+70 times greater than the baseline conductance of the channel, *Gbar*.
+
+It is advisable to use the field *'modulation'* on channels undergoing scaling,
+rather than to directly assign the conductance *'Gbar'*. This is because
+*Gbar* is an absolute conductance, and therefore it is scaled to the area of
+the electrical segment. This makes it difficult to keep track of. *Modulation*
+is a simple multiplier term onto *Gbar*, and is therefore easier to work with.
+
+ ``[ 'Ca_conc', 'Ca', 'dend/Ca', 'conc', 0.00008, 2 ]``:
+
+Use the concentration of *Ca* as computed in the electrical model, to assign
+the concentration of molecule *Ca* on the dendrite compartment. There is a
+basal level of 80 nanomolar, and every unit of electrical *Ca* maps to 2
+millimolar of chemical *Ca*.
+
+The arguments in the adaptorList are:
+
+ * **Source and Dest**: Strings. These can be either a molecular or an
+ electrical object. To identify a molecular object, it should be
+ prefixed with the name of the chemical compartment, which is one
+ of *dend, spine, psd*. Thus *dend/chan* specifies a molecule
+ named *'chan'* sitting in the *'dend'* compartment.
+
+ To identify an electrical object, just pass in its path,
+ such as '.' or *'Ca_conc'*.
+
+ Note that the adaptors do **not** need to know anything about the
+ location. It is assumed that the adaptors do their job wherever
+ the specified source and dest coexist. There is a subtlety here
+ due to the different length and time scales. The rule of thumb
+ is that the adaptor averages whichever one is subdivided more finely.
+
+ - Example 1: Molecules are typically spatially partitioned into
+ short voxels (micron-scale) compared to typical 100-micron
+ electrical
+ segments. So an adaptor going from molecules to, say, channel
+ conductance, would average all the molecular voxels that fit
+ in the electrical segment.
+ - Example 2: Electrical activity is typically much faster than
+ chemical.
+ So an adaptor going from an electrical entity (Ca computed from
+ channel opening) to molecules (Chemical Ca concentration) would
+ average all the time-steps between updates to the molecule.
+
+ * **Fields**: Strings. These are simply the field names on the
+ objects coupled by the adaptors.
+
+ * **offset and scale**: Doubles. At present the adaptor is just a
+ straight-line conversion, obeying ``y = mx + c``. The computed
+ output is *y*, averaged input is *x*, offset is *c* and scale is *m*.
+
+There is a handy new line to specify cellular passive properties:
+
+**passiveDistrib:** `[path, field, value, field, value, ... ]`,
+
+ * path: String. Specifies the object whose parameters are to be changed.
+ * field: String. Name of the field on the object.
+ * value: String, that is the value has to be enclosed in quotes. The
+ value to be assigned to the object.
+
+With these in place, the model behavior is rather neat. It starts out silent,
+then we apply 2 seconds of +ve current injection.
+
+.. figure:: ../../../../images/ex8.0_multiscale_currInj.png
+ :alt: Current injection stimuli for multiscale model.
+
+ Current injection stimuli for multiscale model.
+
+The cell fires briskly, and keeps firing even when the current injection
+drops to zero.
+
+.. figure:: ../../../../images/ex8.0_multiscale_cell_spiking.png
+ :alt: Firing responses of cell with multiscale signaling.
+
+ Firing responses of cell with multiscale signaling.
+
+The firing of the neuron leads to Ca influx.
+
+.. figure:: ../../../../images/ex8.0_multiscale_Ca.png
+ :alt: Calcium buildup in cell due to firing.
+
+ Calcium buildup in cell due to firing.
+
+The chemical reactions downstream of Ca lead to phosphorylation of the K_A
+channel. Only the unphosphorylated K_A channel is active, so the net effect
+is to reduce K_A conductance while the Ca influx persists.
+
+.. figure:: ../../../../images/ex8.0_multiscale_KA_conc.png
+ :alt: Removal of KA channel due to phosphorylation.
+
+ Removal of KA channel due to phosphorylation.
+
+
+Since the phosphorylated form has low conductance, the cell becomes more
+excitable and keeps firing even when the current injection is stopped. It takes
+a later, -ve current injection to turn the firing off again.
+
+Suggestions for things to do with the model:
+
+ - Vary the adaptor settings, which couple electrical to chemical
+ signaling and vice versa.
+ - Play with the channel densities
+ - Open the chem model in moosegui and vary its parameters too.
+
+Multiscale model of CICR in dendrite triggered by synaptic input
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex8.1_synTrigCICR.py*
+
+In this model synaptic input arrives at a dendritic spine, leading to calcium
+influx through the NMDA receptor. An adaptor converts this influx to the
+concentration of a chemical species, and this then diffuses into the dendrite
+and sets off the CICR.
+
+This example models Calcium events in three compartments: dendrite, ER
+inside dendrite, and spine. The signaling is a slight change from the
+toy model used
+in *ex7.2_CICR.py*. Note how the range of CICR wave propagation
+is limited by a domain of the dendrite in which the level of IP3 is elevated.
+
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ turnOffElec = False,
+ chemDt = 0.002,
+ chemPlotDt = 0.02,
+ diffusionLength = 1e-6,
+ numWaveFrames = 50,
+ useGssa = False,
+ addSomaChemCompt = False,
+ addEndoChemCompt = True,
+ # cellProto syntax: ['ballAndStick', 'name', somaDia, somaLength, dendDia, dendLength, numDendSeg]
+ cellProto = [['ballAndStick', 'soma', 10e-6, 10e-6, 2e-6, 40e-6, 4]],
+ spineProto = [['makeActiveSpine()', 'spine']],
+ chemProto = [['./chem/CICRspineDend.g', 'chem']],
+ spineDistrib = [['spine', '#dend#', '10e-6', '0.1e-6']],
+ chemDistrib = [['chem', 'dend#,spine#,head#', 'install', '1' ]],
+ adaptorList = [
+ [ 'Ca_conc', 'Ca', 'spine/Ca', 'conc', 0.00008, 8 ]
+ ],
+ stimList = [
+ ['head0', '0.5', 'glu', 'periodicsyn', '1 + 40*(t>5 && t<6)'],
+ ['head0', '0.5', 'NMDA', 'periodicsyn', '1 + 40*(t>5 && t<6)'],
+ ['dend#', 'g>10e-6 && g<=31e-6', 'dend/IP3', 'conc', '0.0006' ],
+ ],
+ plotList = [
+ ['head#', '1', 'spine/Ca', 'conc', 'Spine Ca conc'],
+ ['dend#', '1', 'dend/Ca', 'conc', 'Dend Ca conc'],
+ ['dend#', '1', 'dend/Ca', 'conc', 'Dend Ca conc', 'wave'],
+ ['dend#', '1', 'dend_endo/CaER', 'conc', 'ER Ca conc', 'wave'],
+ ['soma', '1', '.', 'Vm', 'Memb potl'],
+ ],
+ )
+ moose.seed( 1234 )
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 16 )
+ rdes.display()
+
+The demo illustrates how to specify the range of elevated IP3 in the *stimList*
+using the second argument, which selects a geometric range of electrical
+compartments.
+
+::
+
+ ['dend#', 'g>10e-6 && g<=31e-6', 'dend/IP3', 'conc', '0.0006' ]
+
+This means to look at all dendrite compartments (first argument), and select
+those which are between a geometrical distance *g* of 10 to 31 microns
+from the soma (second argument). The system then
+sets the IP3 concentration (third and fourth arguments) to 0.6 uM
+(last argument) for all the chemical voxels embedded in these dendrite
+compartments.
+
+A note on defining the endo compartments: In cases like this, where the
+compartment identity isn't built into the chemical model definition, we need
+a heuristic to decide which compartment is which. The heuristic used in
+rdesigneur goes like this:
+
+ - Sort chemical compartments in decreasing order by volume
+ - If the addSomaChemCompt flag is **true**, they are assigned to
+ *soma, dendrite, spine-head, spine-psd*, depending on how many
+ compartments are specified. If the flag is **false**, the soma is
+ omitted.
+ - If the addEndoChemCompt is **true**, then alternate compartments are
+ assigned to the endo_compartment. Here it is
+ *dend, dend_endo, spine-head*.
+ If we had six compartments defined (no soma) it would have been:
+ *dend, dend_endo, spine-head, spine-endo, psd, psd-endo*.
+ The psd-endo doesn't make a lot of biological sense, though.
+
+When we run this model, we trigger a propagating Ca wave from about voxel
+number 16 of 40. It spreads in both directions, and comes to a halt at voxels
+10 and 30, which mark the limits of the IP3 elevation zone.
+
+.. figure:: ../../../../images/ex8.1_dend_Ca.png
+ :alt: Calcium wave propagation along the dendrite
+
+ Calcium wave propagation along the dendrite
+
+Note two subtle effects on the ER Ca concentration: first, there is a
+periodic small influx of calcium at voxel 16 due to synaptic input. Second,
+there is a slow restoration of the ER Ca level toward baseline due to
+diffusion in the dendrite and the action of pumps to within the ER, and
+out of the cell. Note also that the gradient within the ER is actually quite
+small, being about a 12% deviation from the resting calcium.
+
+.. figure:: ../../../../images/ex8.1_ER_Ca.png
+ :alt: Calcium depletion and buildup in the ER due to CICR wave.
+
+ Calcium depletion and buildup in the ER due to CICR wave.
+
+
+Multiscale model spanning PSD, spine head and dendrite
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex8.2_multiscale_glurR_phosph_3compt.py*
+
+This is another multiscale model on similar lines to 8.0. It is structurally
+and computationally more complicated, because the action is distributed between
+spines and dendrites, but formally it does the same thing: it turns on and
+stays on after a strong stimulus, due to phosphorylation of a (receptor)
+channel leading to greater excitability.
+
+`calcium influx -> chemical activity -> channel modulation -> electrical activity -> calcium influx.`
+
+The model is bistable as long as synaptic input keeps coming along at a basal
+rate, in this case 1 Hz.
+
+Here we have two new lines, to do with addition of spines. These are discussed
+in detail in a later example. For now it is enough to know that the
+**spineProto** line defines one of the prototype spines to be used to put into
+the model, and the **spineDistrib** line tells the system where to put them,
+and how widely to space them.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ elecDt = 50e-6,
+ chemDt = 0.002,
+ diffDt = 0.002,
+ chemPlotDt = 0.02,
+ useGssa = False,
+ # cellProto syntax: ['ballAndStick', 'name', somaDia, somaLength, dendDia, d
+ endLength, numDendSegments ]
+ cellProto = [['ballAndStick', 'soma', 12e-6, 12e-6, 4e-6, 100e-6, 2 ]],
+ chemProto = [['./chem/chanPhosph3compt.g', 'chem']],
+ spineProto = [['makeActiveSpine()', 'spine']],
+ chanProto = [
+ ['make_Na()', 'Na'],
+ ['make_K_DR()', 'K_DR'],
+ ['make_K_A()', 'K_A' ],
+ ['make_Ca()', 'Ca' ],
+ ['make_Ca_conc()', 'Ca_conc' ]
+ ],
+ passiveDistrib = [['soma', 'CM', '0.01', 'Em', '-0.06']],
+ spineDistrib = [['spine', '#dend#', '50e-6', '1e-6']],
+ chemDistrib = [['chem', '#', 'install', '1' ]],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '300' ],
+ ['K_DR', 'soma', 'Gbar', '250' ],
+ ['K_A', 'soma', 'Gbar', '200' ],
+ ['Ca_conc', 'soma', 'tau', '0.0333' ],
+ ['Ca', 'soma', 'Gbar', '40' ]
+ ],
+ adaptorList = [
+ [ 'psd/chan_p', 'n', 'glu', 'modulation', 0.1, 1.0 ],
+ [ 'Ca_conc', 'Ca', 'spine/Ca', 'conc', 0.00008, 8 ]
+ ],
+ # Syn input basline 1 Hz, and 40Hz burst for 1 sec at t=20. Syn weight
+ # is 0.5, specified in 2nd argument as a special case stimLists.
+ stimList = [['head#', '0.5','glu', 'periodicsyn', '1 + 40*(t>10 && t<11)']],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Membrane potential'],
+ ['#', '1', 'spine/Ca', 'conc', 'Ca in Spine'],
+ ['#', '1', 'dend/DEND/Ca', 'conc', 'Ca in Dend'],
+ ['#', '1', 'spine/Ca_CaM', 'conc', 'Ca_CaM'],
+ ['head#', '1', 'psd/chan_p', 'conc', 'Phosph gluR'],
+ ['head#', '1', 'psd/Ca_CaM_CaMKII', 'conc', 'Active CaMKII'],
+ ]
+ )
+ moose.seed(123)
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 25 )
+ rdes.display()
+
+
+This is how it works:
+
+This is a ball-and-stick model with a couple of spines sitting on the dendrite.
+The spines get synaptic input onto NMDARs and gluRs. There is a baseline
+input rate of 1 Hz thoughout, and there is a burst at 40 Hz for 1 second at
+t = 10s.
+
+.. figure:: ../../../../images/ex8.2_Vm.png
+ :alt: Membrane potential responses of cell with synaptic input and multiscale signaling
+
+ Membrane potential responses of cell with synaptic input and multiscale signaling
+
+
+At baseline, we just have small EPSPs and little Ca influx. A burst of
+strong synaptic input causes Ca entry into the spine via NMDAR.
+
+.. figure:: ../../../../images/ex8.2_Ca_spine.png
+ :alt: Calcium influx into spine.
+
+ Calcium influx into spine.
+
+Ca diffuses from the spine into the dendrite and spreads. In the graph below
+we see how Calcium goes into the 50-odd voxels of the dendrite.
+
+.. figure:: ../../../../images/ex8.2_Ca_dend.png
+ :alt: Calcium influx and diffusion in dendrite.
+
+ Calcium influx and diffusion in dendrite.
+
+
+The Ca influx into the spine
+triggers activation of CaMKII and its translocation to the PSD, where
+it phosphorylates and increases the conductance of gluR. We have two spines
+with slightly different geometry, so the CaMKII activity differs slightly.
+
+.. figure:: ../../../../images/ex8.2_active_CaMKII.png
+ :alt: Activation of CaMKII and translocation to PSD
+
+ Activation of CaMKII and translocation to PSD
+
+
+Now that gluR has a greater weight, the baseline synaptic input keeps
+Ca trickling in enough to keep the CaMKII active.
+
+Here are the reactions:
+
+::
+
+ Ca+CaM <===> Ca_CaM; Ca_CaM + CaMKII <===> Ca_CaM_CaMKII (all in
+ spine head, except that the Ca_CaM_CaMKII translocates to the PSD)
+
+ chan ------Ca_CaM_CaMKII-----> chan_p; chan_p ------> chan (all in PSD)
+
+Suggestions:
+
+ - Add GABAR using make_GABA(), put it on soma or dendrite. Stimulate it
+ after 20 s to see if you can turn off the sustained activation
+ - Replace the 'periodicsyn' in stimList with 'randsyn'. This gives
+ Poisson activity at the specified mean frequency. Does the switch
+ remain reliable?
+ - What are the limits of various parameters for this switching? You
+ could try basal synaptic rate, burst rate, the various scaling factors
+ for the adaptors, the densities of various channels, synaptic weight,
+ and so on.
+ - In real life an individual synaptic EPSP is tiny, under a millivolt.
+ How many synapses would you need to achieve this kind of switching?
+ You can play with # of synapses by altering the spacing between
+ spines as the third argument of spineDistrib.
+
+Multiscale model in which spine geometry changes due to signaling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex8.3_spine_vol_change.py*
+
+This model is very similar to 8.2. The main design difference is that
+*adaptor*, instead of just modulating the gluR conductance, scales the
+entire spine cross-section area, with all sorts of electrical and chemical
+ramifications. There are a lot of plots, to illustrate some of these outcomes.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ elecDt = 50e-6,
+ chemDt = 0.002,
+ diffDt = 0.002,
+ chemPlotDt = 0.02,
+ useGssa = False,
+ stealCellFromLibrary = True, # Simply move library model to use for sim
+ cellProto = [['ballAndStick', 'soma', 12e-6, 12e-6, 4e-6, 100e-6, 2 ]],
+ chemProto = [['./chem/chanPhosph3compt.g', 'chem']],
+ spineProto = [['makeActiveSpine()', 'spine']],
+ chanProto = [
+ ['make_Na()', 'Na'],
+ ['make_K_DR()', 'K_DR'],
+ ['make_K_A()', 'K_A' ],
+ ['make_Ca()', 'Ca' ],
+ ['make_Ca_conc()', 'Ca_conc' ]
+ ],
+ passiveDistrib = [['soma', 'CM', '0.01', 'Em', '-0.06']],
+ spineDistrib = [['spine', '#dend#', '50e-6', '1e-6']],
+ chemDistrib = [['chem', '#', 'install', '1' ]],
+ chanDistrib = [
+ ['Na', 'soma', 'Gbar', '300' ],
+ ['K_DR', 'soma', 'Gbar', '250' ],
+ ['K_A', 'soma', 'Gbar', '200' ],
+ ['Ca_conc', 'soma', 'tau', '0.0333' ],
+ ['Ca', 'soma', 'Gbar', '40' ]
+ ],
+ adaptorList = [
+ # This scales the psdArea of the spine by # of chan_p. Note that
+ # the cross-section area of the spine head is identical to psdArea.
+ [ 'psd/chan_p', 'n', 'spine', 'psdArea', 0.1e-12, 0.01e-12 ],
+ [ 'Ca_conc', 'Ca', 'spine/Ca', 'conc', 0.00008, 8 ]
+ ],
+ # Syn input basline 1 Hz, and 40Hz burst for 1 sec at t=20. Syn wt=10
+ stimList = [['head#', '10','glu', 'periodicsyn', '1 + 40*(t>10 && t<11)']],
+ plotList = [
+ ['soma', '1', '.', 'Vm', 'Membrane potential'],
+ ['#', '1', 'spine/Ca', 'conc', 'Ca in Spine'],
+ ['#', '1', 'dend/DEND/Ca', 'conc', 'Ca in Dend'],
+ ['head#', '1', 'psd/chan_p', 'n', 'Amount of Phospho-chan'],
+ ['head#', '1', 'spine/CaMKII', 'conc', 'Conc of CaMKII in spine'],
+ ['head#', '1', '.', 'Cm', 'Capacitance of spine head'],
+ ['head#', '1', '.', 'Rm', 'Membrane res of spine head'],
+ ['head#', '1', '.', 'Ra', 'Axial res of spine head'],
+ ['head#', '1', 'glu', 'Gbar', 'Conductance of gluR'],
+ ['head#', '1', 'NMDA', 'Gbar', 'Conductance of NMDAR'],
+ ]
+ )
+ moose.seed(123)
+ rdes.buildModel()
+ moose.reinit()
+ moose.start( 25 )
+ rdes.display()
+
+
+The key *adaptor* line is as follows:
+
+``[ 'psd/chan_p', 'n', 'spine', 'psdArea', 0.1e-12, 0.01e-12 ]``
+
+Here, we use the phosphorylated *chan_p* molecule in the PSD as a proxy for
+processes that control spine size. We operate on a special object called
+*spine* which manages many aspects of spines in the model (see below). Here
+we control the *psdArea*, which defines the cross-section area of the spine
+head and by extension of the PSD too. We keep a minimum spine area of 0.1 um^2,
+and a scaling factor of 0.01um^2 per phosphorylated molecule.
+
+The reaction system is identical to the one in *ex8.2*:
+
+::
+
+ Ca+CaM <===> Ca_CaM; Ca_CaM + CaMKII <===> Ca_CaM_CaMKII (all in
+ spine head, except that the Ca_CaM_CaMKII translocates to the PSD)
+
+ chan ------Ca_CaM_CaMKII-----> chan_p; chan_p ------> chan (all in PSD)
+
+Rather than list all the 10 plots, here are a few to show what is going on.
+
+First, just the spiking activity of the cell. Here the burst of activity is
+followed by a few seconds of enhanced synaptic weight, followed by subthreshold
+EPSPs:
+
+.. figure:: ../../../../images/ex8.3_Vm.png
+ :alt: Membrane potential and spiking.
+
+ Membrane potential and spiking.
+
+Then, we fast-forward to the amount of *chan_p* which is the molecule that
+controls spine size scaling:
+
+.. figure:: ../../../../images/ex8.3_chan_p.png
+ :alt: Molecule that controles spine size
+
+ Molecule that controles spine size
+
+This causes some obvious outcomes. One of them is to increase the synaptic
+conductance of the glutamate receptor. The system assumes that the conductance
+of all channels in the PSD scales linearly with the psdArea.
+
+.. figure:: ../../../../images/ex8.3_gluR.png
+ :alt: Conductance of glutamate receptor
+
+ Conductance of glutamate receptor
+
+Here is one of several non-intuitive outcomes. Because the spine volume has
+increased, the concentration of molecules in the spine is diluted out. So
+the concentration of active CaMKII actually falls when the spine gets bigger.
+In a more detailed model, this would be a race between the increase in spine
+size and the time taken for diffusion and further reactions to replenish
+CaMKII. In the current model we don't have a diffusive coupling of CaMKII to
+the dendrite, so this replenishment doesn't happen.
+
+.. figure:: ../../../../images/ex8.3_CaMKII_spine.png
+ :alt: Concentration of CaMKII in the spine
+
+ Concentration of CaMKII in the spine
+
+In the simulation we display several other electrical and chemical properties
+that change with spine size. The diffusion properties also change since the
+cross-section areas are altered. This is harder to visualize but has large
+effects on coupling to the dendrite,
+especially if the *shaftDiameter* is the parameter scaled by the signaling.
+
+
+Suggestions:
+
+ - The Spine class (instance: spine) manages several possible scaling
+ targets on the spine geometry: shaftLength, shaftDiameter,
+ headLength, headDiameter, psdArea, headVolume, totalLength. Try them
+ out. Think about mechanisms by which molecular concentrations might
+ affect each.
+ - When volume changes, we assume that the molecular numbers stay
+ fixed, so concentration changes. Except for buffered molecules, where
+ we assume concentration remains fixed. Use this to design a bistable
+ simply relying on molecules and spine geometry terms.
+ - Even more interesting, use it to design an oscillator. You could look
+ at Bhalla, BiophysJ 2011 for some ideas.
+
+
+
+Morphology: Load .swc morphology file and view it
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex9.0_load_neuronal_morphology_file.py*
+
+Here we build a passive model using a morphology file in the .swc file
+format (as used by NeuroMorpho.org). The morphology file is predefined
+for Rdesigneur and resides in the directory ``./cells``. We apply a
+somatic current pulse, and view the somatic membrane potential in a
+plot, as before. To make things interesting we display the morphology in
+3-D upon which we represent the membrane potential as colors.
+
+::
+
+ import sys
+ import moose
+ import rdesigneur as rd
+
+ if len( sys.argv ) > 1:
+ fname = sys.argv[1]
+ else:
+ fname = './cells/h10.CNG.swc'
+ rdes = rd.rdesigneur(
+ cellProto = [[fname, 'elec']],
+ stimList = [['soma', '1', '.', 'inject', 't * 25e-9' ]],
+ plotList = [['#', '1', '.', 'Vm', 'Membrane potential'],
+ ['#', '1', 'Ca_conc', 'Ca', 'Ca conc (uM)']],
+ moogList = [['#', '1', '.', 'Vm', 'Soma potential']]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ rdes.displayMoogli( 0.001, 0.1, rotation = 0.02 )
+
+
+Here the new concept is the cellProto line, which loads in the specified
+cell model:
+
+::
+
+ `[ filename, cellname ]`
+
+The system recognizes the filename extension and builds a model from the
+swc file. It uses the cellname **elec** in this example.
+
+We use a similar line as in the reaction-diffusion example, to build up
+a Moogli display of the cell model:
+
+::
+
+ `moogList = [['#', '1', '.', 'Vm', 'Soma potential']]`
+
+Here we have:
+
+::
+
+ # : the path to use for selecting the compartments to display.
+ This wildcard means use all compartments.
+ 1 : The expression to use for the compartments. Again, `1` means use
+ all of them.
+ . : Which object in the compartment to display. Here we are using the
+ compartment itself, so it is just a dot.
+ Vm : Field to display
+ Soma potential : Title for display.
+
+.. figure:: ../../../../images/ex9.0_passive_cell_morpho.png
+ :alt: 3-D display for passive neuron
+
+ 3-D display for passive neuron
+
+Suggestions:
+
+ - The tutorial directory already has a number of pre-loaded files from
+ NeuroMorpho. Pass them in to ex9.0 on the command line:
+
+ `python ex9.0_load_neuronal_morphology_file.py `
+ - Grab other morphology files from NeuroMorpho.org, try them out.
+
+Build an active neuron model by putting channels into a morphology file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex9.1_chans_in_neuronal_morph.py*
+
+Here we load in a morphology file and distribute voltage-gated ion channels
+over the neuron. The voltage-gated channels are obtained from a
+number of channelML files, located in the ``./channels`` subdirectory.
+Since we have a spatially extended neuron, we need to specify the
+spatial distribution of channel densities too.
+
+::
+
+ import moose
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ chanProto = [
+ ['./chans/hd.xml'],
+ ['./chans/kap.xml'],
+ ['./chans/kad.xml'],
+ ['./chans/kdr.xml'],
+ ['./chans/na3.xml'],
+ ['./chans/nax.xml'],
+ ['./chans/CaConc.xml'],
+ ['./chans/Ca.xml']
+ ],
+ cellProto = [['./cells/h10.CNG.swc', 'elec']],
+ chanDistrib = [ \
+ ["hd", "#dend#,#apical#", "Gbar", "50e-2*(1+(p*3e4))" ],
+ ["kdr", "#", "Gbar", "p < 50e-6 ? 500 : 100" ],
+ ["na3", "#soma#,#dend#,#apical#", "Gbar", "850" ],
+ ["nax", "#soma#,#axon#", "Gbar", "1250" ],
+ ["kap", "#axon#,#soma#", "Gbar", "300" ],
+ ["kap", "#dend#,#apical#", "Gbar",
+ "300*(H(100-p*1e6)) * (1+(p*1e4))" ],
+ ["Ca_conc", "#", "tau", "0.0133" ],
+ ["kad", "#soma#,#dend#,#apical#", "Gbar", "50" ],
+ ["Ca", "#", "Gbar", "50" ]
+ ],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.02) * 1e-9' ]],
+ plotList = [['#', '1', '.', 'Vm', 'Membrane potential'],
+ ['#', '1', 'Ca_conc', 'Ca', 'Ca conc (uM)']],
+ moogList = [['#', '1', 'Ca_conc', 'Ca', 'Calcium conc (uM)', 0, 120],
+ ['#', '1', '.', 'Vm', 'Soma potential']]
+ )
+
+ rdes.buildModel()
+
+ moose.reinit()
+ rdes.displayMoogli( 0.0002, 0.052 )
+
+Here we make more extensive use of two concepts which we've already seen
+from the single compartment squid model:
+
+1. *chanProto*: This defines numerous channels, each of which is of the
+ form:
+
+ ``[ filename ]``
+
+ or
+
+ ``[ filename, channelname ]``
+
+ or
+
+ ``[ channelFunction(), channelname ]``
+
+If the *channelname* is not specified the system uses the last part of
+the channel name, before the filetype suffix.
+
+2. *chanDistrib*: This defines the spatial distribution of each channel
+ type. Each line is of a form that should be familiar now:
+
+ ``[channelname, region_in_cell, parameter, expression_string]``
+
+- The *channelname* is the name of the prototype from *chanproto*. This
+ is usually an ion channel, but in the example above you can also see
+ a calcium concentration pool defined.
+- The *region\_in\_cell* is typically defined using wildcards, so that
+ it generalizes to any cell morphology. For example, the plain
+ wildcard ``#`` means to consider all cell compartments. The wildcard
+ ``#dend#`` means to consider all compartments with the string
+ ``dend`` somewhere in the name. Wildcards can be comma-separated, so
+ ``#soma#,#dend#`` means consider all compartments with either soma or
+ dend in their name. The naming in MOOSE is defined by the model file.
+ Importantly, in **.swc** files MOOSE generates names that respect the
+ classification of compartments into axon, soma, dendrite, and apical
+ dendrite compartments respectively. SWC files generate compartment
+ names such as:
+
+ ::
+
+ soma_
+ dend_
+ apical_
+ axon_
+
+where the number is automatically assigned by the reader. In order to
+select all dendritic compartments, for example, one would use *"#dend#"*
+where the *"#"* acts as a wildcard to accept any string. - The
+*parameter* is usually Gbar, the channel conductance density in *S/m^2*.
+If *Gbar* is zero or less, then the system economizes by not
+incorporating this channel mechanism in this part of the cell.
+Similarly, for calcium pools, if the *tau* is below zero then the
+calcium pool object is simply not inserted into this part of the cell. -
+The *expression\_string* defines the value of the parameter, such as
+Gbar. This is typically a function of position in the cell. The
+expression evaluator knows about several parameters of cell geometry.
+All units are in metres:
+
+- *x*, *y* and *z* coordinates.
+- *g*, the geometrical distance from the soma
+- *p*, the path length from the soma, measured along the dendrites.
+- *dia*, the diameter of the dendrite.
+- *L*, The electrotonic length from the soma (no units).
+
+Along with these geometrical arguments, we make liberal use of the
+ternary expressions like *p < 50e-6 ? 500 : 100* or multiplying a channel
+density with a logical function or Heaviside function H(x) to set up the
+channel distributions. The
+expression evaluator also knows about pretty much all common algebraic,
+trignometric, and logarithmic functions, should you wish to use these.
+
+Also note the two Moogli displays. The first is the calcium
+concentration. The second is the membrane potential in each compartment.
+Easy!
+
+.. figure:: ../../../../images/rdes8_active.png
+ :alt: 3-D display for active neuron
+
+ 3-D display for active neuron
+
+Suggestions:
+
+ - Try another morphology file.
+ - Try different channel distributions by editing the chanDistrib lines.
+ - There are numerous predefined channels available within Rdesigneur.
+ These can be defined using the following chanProto options:
+
+ ::
+
+ ['make_HH_Na()', 'HH_Na']
+ ['make_HH_K_DR()', 'HH_K']
+ ['make_Na()', 'Na']
+ ['make_K_DR()', 'K_DR']
+ ['make_K_A()', 'K_A']
+ ['make_K_AHP()', 'K_AHP']
+ ['make_K_C()', 'K_C']
+ ['make_Ca()', 'Ca']
+ ['make_Ca_conc()', 'Ca_conc']
+ ['make_glu()', 'glu']
+ ['make_GABA()', 'GABA']
+
+ Then the chanDistrib can refer to these channels instead.
+ - Deliver stimuli on the dendrites rather than the soma.
+
+
+Build a spiny neuron from a morphology file and put active channels in it.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex9.2_spines_in_neuronal_morpho.py*
+
+This model is one step elaborated from the previous one, in that we now
+also have dendritic spines. MOOSE lets one decorate a bare neuronal
+morphology file with dendritic spines, specifying various geometric
+parameters of their location. As before, we use an swc file for the
+morphology, and the same ion channels and distribution.
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ chanProto = [
+ ['./chans/hd.xml'],
+ ['./chans/kap.xml'],
+ ['./chans/kad.xml'],
+ ['./chans/kdr.xml'],
+ ['./chans/na3.xml'],
+ ['./chans/nax.xml'],
+ ['./chans/CaConc.xml'],
+ ['./chans/Ca.xml']
+ ],
+ cellProto = [['./cells/h10.CNG.swc', 'elec']],
+ spineProto = [['makeActiveSpine()', 'spine']],
+ chanDistrib = [
+ ["hd", "#dend#,#apical#", "Gbar", "50e-2*(1+(p*3e4))" ],
+ ["kdr", "#", "Gbar", "p < 50e-6 ? 500 : 100" ],
+ ["na3", "#soma#,#dend#,#apical#", "Gbar", "850" ],
+ ["nax", "#soma#,#axon#", "Gbar", "1250" ],
+ ["kap", "#axon#,#soma#", "Gbar", "300" ],
+ ["kap", "#dend#,#apical#", "Gbar",
+ "300*(H(100-p*1e6)) * (1+(p*1e4))" ],
+ ["Ca_conc", "#", "tau", "0.0133" ],
+ ["kad", "#soma#,#dend#,#apical#", "Gbar", "50" ],
+ ["Ca", "#", "Gbar", "50" ]
+ ],
+ spineDistrib = [['spine', '#dend#,#apical#', '20e-6', '1e-6']],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.02) * 1e-9' ]],
+ plotList = [['#', '1', '.', 'Vm', 'Membrane potential'],
+ ['#', '1', 'Ca_conc', 'Ca', 'Ca conc (uM)']],
+ moogList = [['#', '1', 'Ca_conc', 'Ca', 'Calcium conc (uM)', 0, 120],
+ ['#', '1', '.', 'Vm', 'Soma potential']]
+ )
+
+ rdes.buildModel()
+
+ moose.reinit()
+ rdes.displayMoogli( 0.0002, 0.023 )
+
+Spines are set up in a familiar way: we first define one (or more)
+prototype spines, and then distribute these around the cell. Here is the
+prototype string:
+
+::
+
+ [spine_proto, spinename]
+
+*spineProto*: This is typically a function. One can define one's own,
+but there are several predefined ones in rdesigneur. All these define a
+spine with the following parameters:
+
+- head diameter 0.5 microns
+- head length 0.5 microns
+- shaft length 1 micron
+- shaft diameter of 0.2 microns
+- RM = 1.0 ohm-metre square
+- RA = 1.0 ohm-meter
+- CM = 0.01 Farads per square metre.
+
+Here are the predefined spine prototypes:
+
+- *makePassiveSpine()*: This just makes a passive spine with the
+ default parameters
+- *makeExcSpine()*: This makes a spine with NMDA and glu receptors, and
+ also a calcium pool. The NMDA channel feeds the Ca pool.
+- *makeActiveSpine()*: This adds a Ca channel to the exc\_spine. and
+ also a calcium pool.
+
+The spine distributions are specified in a familiar way for the first
+few arguments, and then there are multiple (optional) spine-specific
+parameters:
+
+*[spinename, region\_in\_cell, spacing, spacing\_distrib, size,
+size\_distrib, angle, angle\_distrib ]*
+
+Only the first two arguments are mandatory.
+
+- *spinename*: The prototype name
+- *region\_in\_cell*: Usual wildcard specification of names of
+ compartments in which to put the spines.
+- *spacing*: Math expression to define spacing between spines. In the
+ current implementation this evaluates to
+ ``1/probability_of_spine_per_unit_length``. Defaults to 10 microns.
+ Thus, there is a 10% probability of a spine insertion in every
+ micron. This evaluation method has the drawback that it is possible
+ to space spines rather too close to each other. If spacing is zero or
+ less, no spines are inserted.
+- *spacing\_distrib*: Math expression for distribution of spacing. In
+ the current implementation, this specifies the interval at which the
+ system samples from the spacing probability above. Defaults to 1
+ micron.
+- *size*: Linear scale factor for size of spine. All dimensions are
+ scaled by this factor. The default spine head here is 0.5 microns in
+ diameter and length. If the scale factor were to be 2, the volume
+ would be 8 times as large. Defaults to 1.0.
+- *size\_distrib*: Range for size of spine. A random number R is
+ computed in the range 0 to 1, and the final size used is
+ ``size + (R - 0.5) * size_distrib``. Defaults to 0.5
+- *angle*: This specifies the initial angle at which the spine sticks
+ out of the dendrite. If all angles were zero, they would all point
+ away from the soma. Defaults to 0 radians.
+- *angle\_distrib*: Specifies a random number to add to the initial
+ angle. Defaults to 2 PI radians, so the spines come out in any
+ direction.
+
+.. figure:: ../../../../images/rdes9_spiny_active.png
+ :alt: 3-D display for spiny active neuron
+
+ 3-D display for spiny active neuron
+
+Suggestions:
+
+ - Try different spine settings. Warning: if you put in too many spines
+ it will take much longer to load and run!
+ - Try different spine geometry layouts.
+ - See if you can deliver the current injection to the spine. Hint: the
+ name of the spine compartments is 'head#' where # is the index of the
+ spine.
+
+Place spines in a spiral along a dendrite
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*ex9.3_spiral_spines.py*
+
+Just for fun. Illustrates how to place spines in a spiral around the dendrite.
+For good measure the spines get bigger the further they are from the soma.
+
+Note that the uniform spacing of spines is signified
+by the negative minSpacing term, the fourth argument to spineDistrib.
+
+
+::
+
+ import moose
+ import pylab
+ import rdesigneur as rd
+ rdes = rd.rdesigneur(
+ cellProto = [['ballAndStick', 'elec', 10e-6, 10e-6, 2e-6, 300e-6, 50]],
+ spineProto = [['makePassiveSpine()', 'spine']],
+ spineDistrib = [['spine', '#dend#', '3e-6', '-1e-6', '1+p*2e4', '0', 'p*6.28e7', '0']],
+ stimList = [['soma', '1', '.', 'inject', '(t>0.02) * 1e-9' ]],
+ moogList = [['#', '1', '.', 'Vm', 'Soma potential']]
+ )
+ rdes.buildModel()
+ moose.reinit()
+ rdes.displayMoogli( 0.0002, 0.025, 0.02 )
+
+Note that the uniform spacing of spines is signified
+by the negative minSpacing term, the fourth argument to spineDistrib.
+
+spineDistrib = [['spine', '#dend#', '3e-6', **'-1e-6'**, '1+p*2e4', '0', 'p*6.28e7', '0']]
+
+
+.. figure:: ../../../../images/ex9.3_spiral_spines.png
+ :alt: 3-D display of spines in a spiral
+
+ 3-D display of spines in a spiral
+
+Suggestions:
+
+ - Play with expressions for spine size and angular placement.
+ - See what happens if the segment size gets smaller than the
+ spine spacing.
+
+
+Rdesigneur command reference
+----------------------------
+
+Rdesigneur is a Python class used to build multiscale neuronal models
+involving Reaction-Diffusion and Electrical SIGnaling in NEURons.
+The stages in its use are illustrated in the following dummy code snippet:
+
+::
+
+ # 1. Load in the libraries
+ import moose
+ import rdesigneur as rd
+
+ # 2. Define the arguments. This does most of the model setup
+ rdes = rd.rdesigneur( args )
+
+ # 3. Tweak parameters of model building-blocks, for example:
+ a = moose.element( '/library/chem/kinetics/a' )
+ a.diffConst = 0
+
+ # 4. Build the model
+ rdes.buildModel()
+
+ # 5. Tweak values in the constructed model, for example
+ bv = moose.vec( '/model/chem/dend/b' )
+ bv[0].concInit *= 2
+
+ # 6. Run the model
+ moose.reinit()
+ moose.start( runtime )
+
+ # 7. Display and/or save model output
+ rdes.dispay()
+
+The rdesigneur arguments are provided in the standard Python keyword-argument
+format. For example:
+
+::
+
+ rdes = rd.rdesigneur(
+ turnOffElec = True,
+ chemDt = 0.05,
+ ...
+ chemProto = [ ['makeChemOscillator()', 'osc'] ],
+ ...
+ plotList = [ rd.rplot( relpath = 'dend/a', field = 'conc', title = '[a] (uM)' ) ],
+ ...
+ )
+
+Each argument has a default, hence even
+`building rdesigneur without arguments`_ will produce a correct, if not very
+interesting model.
+
+**Rdesigneur and Prototypes:** Rdesigneur assembles models by taking prototype
+objects and replicating them into the model. These prototypes can be chemical
+reaction systems, ion channels, spines, or entire neurons. All the prototypes
+are placed under the MOOSE object */library*. When building the model, it looks
+up prototypes by name and places them into the resulting model. The rdesigneur
+constructor (step 2 above) builds all these prototypes. Once they are in place,
+the *BuildModel()* method (step 4 above) performs the assembly.
+
+Below we provide the usage of the argument list to rdesigneur, which
+does most of the model specification.
+
+turnOffElec
+~~~~~~~~~~~
+.. _`turnOffElec`:
+
+Type: bool
+
+Default: False
+
+Use: Turns off electrical calculations. It is a good idea to set this flag
+**True** if the model doesn't use electrical calculations, it can make the
+calculations many times faster.
+
+useGssa
+~~~~~~~
+Type: bool
+
+Default: True
+
+Use: Turns on the use of the Gillespie Stochastic Simulation Algorithm (GSSA)
+in dendritic spines. Advisable in models where you worry about stochasticity.
+Also it typically makes the simulations run faster.
+
+combineSegments
+~~~~~~~~~~~~~~~
+
+Type: bool
+
+Default: True
+
+Use: Flag to pass on to the NeuroML loader to tell it to combine segments.
+
+stealCellFromLibrary
+~~~~~~~~~~~~~~~~~~~~
+
+Type: bool
+
+Default: False
+
+Use: Use the prototype loaded-in neuron itself for the main simulation run,
+removing it from the available prototypes.
+It is advisable to set this to *True* if the model is large and complicated. It
+saves memory and in some cases runs more reliably.
+
+verbose
+~~~~~~~
+
+Type: bool
+
+Default: True
+
+Use: Tell rdesigneur to be garrulous when loading and reporting status and
+errors.
+
+.. _`addSomaChemCompt`:
+
+addSomaChemCompt
+~~~~~~~~~~~~~~~~
+
+Type: bool
+
+Default: False
+
+Use: Specify that the largest chemical compartment (by volume) should be
+assigned to the cell soma. Most multiscale models don't bother with a soma
+chemical compartment, and are happy with dendrite and possibly spines, so this
+defaults to False.
+
+.. _`addEndoChemCompt`:
+
+addEndoChemCompt
+~~~~~~~~~~~~~~~~
+
+Type: bool
+
+Default: False
+
+Use: Specify that each of the chemical compartments should contain an internal
+*endo*-compartment. This is typically used for the endoplasmic reticulum in
+`models of calcium-induced calcium release`_ (CICR), however, the
+EndoCompartments are quite general and can be used for defining chemistry and
+transport involving any membrane-bound organelle. In MOOSE, when you create
+an EndoCompartment it must be surrounded by a regular compartment, and a
+voxel of the EndoCompartment appears within every voxel of the surrounding
+compartment.
+
+diffusionLength
+~~~~~~~~~~~~~~~
+Type: double
+
+Default: 2e-6 (2 microns)
+
+Use: This sets the spatial discretization length of reaction-diffusion models.
+If the diffusion constant is D (in micron^2/sec), then the *diffusionLength*
+should be less than D microns for signaling events that take 1 second. If the
+signaling is faster, *diffusionLength* should be smaller.
+
+temperature
+~~~~~~~~~~~
+
+Type: double
+
+Default: 32 degrees Celsius
+
+Use: ChannelML definitions of ion channels use this value to modulate
+their kinetics.
+
+chemDt
+~~~~~~
+
+Type: double
+
+Default: 0.1 s
+
+Use: Specify timestep for chemical computations. Note that internally the MOOSE
+solver will probably use finer or adaptive timesteps. The *chemDt* just ensures
+that all the chemical values in different solvers will be synchronized at
+this interval. You will want to make this somewhat smaller (0.01 to 0.001 s)
+in the case of multiscale simulations with tight coupling between electrical
+and signaling events.
+
+diffDt
+~~~~~~
+
+Type: double
+
+Default: 0.01 s
+
+Use: Specify timestep for diffusion computations, as well as cross-compartment
+reactions and molecular transport across membrane pores. This timestep
+does not apply to voltage-gated and synaptic channels handled by the electrical
+solver, for that use *elecDt*.
+You will want to make this somewhat smaller (0.01 to 0.001 s)
+in the case of multiscale simulations with tight coupling between electrical
+and signaling events.
+
+elecDt
+~~~~~~
+
+Type: double
+
+Default: 50e-6 s
+
+Use: Specify timestep for electrical calculations, used by the HSolver in
+MOOSE to carry out calculations using Gaussian Elimination and the Crank-
+Nicolson method for ion channels. This works well for slower
+channels, but if you have particularly fast channel kinetics you may wish to
+use *elecDt* of 10 to 20 us.
+
+chemPlotDt
+~~~~~~~~~~
+
+Type: double
+
+Default: 1 s
+
+Use: Timestep for storing and plotting chemical values.
+
+elecPlotDt
+~~~~~~~~~~
+
+Type: double
+
+Default: 100e-6 s
+
+Use: Timestep for storing and plotting electrical values.
+
+funcDt
+~~~~~~
+
+Type: double
+
+Default: 100e-6 s
+
+Use: Timestep for performing Function calculations for inputs and stimuli,
+for electrical models. Only used for electrical models, i.e.,
+when `turnOffElec`_ is False. Otherwise the system uses a *funcDt* equal to
+the *chemDt*.
+
+cellProto
+~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). This generates the Hodgkin-Huxley configuration where
+length and diameter are 500 microns, RM = 0.333, RA = 3000, and
+CM = 0.01 F/m^2, but no active channels.
+
+Use: This defines which neuronal model specification to use. There are many
+options here:
+
+ 1. zero args: make standard soma corresponding to the Hodgkin-Huxley
+ model. length and diameter are both 500 um.
+ 2. [name, library_proto_name]: uses library prototype object.
+ 3. [fname.suffix, cellname ]: Loads cell from file. The file type
+ is identified by the suffix, and can be :
+
+ - *.nml*: NeuroML
+ - *.xml*: NeuroML
+ - *.swc*: NeuroMorpho.org format for cellular morphology
+ - *.p*: Genesis format
+
+ 4. [moose, cellname]: Makes prototype from MOOSE class.
+ 5. [funcname, cellname]: Calls named function with specified
+ name of cell to be made.
+ 6. [path, cellname]: Copies path to library as proto
+ 7. [libraryName, cellname]: Renames library entry as prototype.
+ 8. [somaProto, name, somaDia=5e-4, somaLen=5e-4]
+ Creates a soma with optional specified diameter and length. Defaults
+ as shown.
+ 9. [ballAndStick,name, somaDia=10e-6, somaLen=10e-6,
+ dendDia=4e-6, dendLen=200e-6, numDendSeg=1]
+ Creates a ball-and-stick with required type and name arguments.
+ The remaining arguments are optional. Defaults as shown.
+
+spineProto
+~~~~~~~~~~
+
+.. _`spine prototype`:
+
+Type: List of lists
+
+Default: [] (empty list). This does not define any spines.
+
+Use: Each list entry should be a list containing two strings: *source* and
+*destination*. The *source* defines how to build the prototype. The
+*destination* specifies its name.
+If the requested *destination* is an object that already exists in the library,
+the system doesn't do anything.
+
+The *source* can be any of:
+
+ - functionName(): Call specified Python function, with the *destination*
+ as the argument. The function is expected to build a prototype of the
+ requested name on '/library'. The following utility functions are
+ built-in:
+
+ - makePassiveSpine(): Makes a 2-compartment spine with the following
+ parameters:
+
+ - shaft name: shaft
+ - shaft length = 1 micron
+ - shaft diameter = 0.2 micron
+ - head name: head
+ - head length = 0.5 micron
+ - head diameter = 0.5 micron
+ - RM = 1.0
+ - RA = 1.0
+ - CM = 0.01
+
+ - makeExcSpine(): Same as above but adds in glutamate and NMDA
+ receptors and a calcium pool. The calcium pool has a pumping tau of
+ 13.333 ms, and is present in the volume of the spine head.
+ Both receptors have conductances in the form of dual-exponential
+ alpha functions, with a separate opening and closing tau.
+ The glutamate receptor has the following parameters:
+
+ - name: glu
+ - opening tau: 2 ms
+ - closing tau: 9 ms
+ - Gbar, ie, conductance per unit area: 200 Siemens/m^2
+
+ The NMDA receptor has the following parameters:
+
+ - name: NMDA
+ - opening tau: 20 ms
+ - closing tau: 20 ms
+ - Gbar, ie, conductance per unit area: 80 Siemens/m^2
+
+ - makeActiveSpine(): Same as above, but also adds in a voltage-gated
+ calcium channel with *Gbar = 10 Siemens/m^2* into the spine head.
+
+ - Path of existing object in memory, such as */library/source*. In this
+ case rdesigneur renames the object to */library/destination*.
+ - A filename, with any of the suffices:
+
+ - *.nml*: NeuroML
+ - *.xml*: NeuroML
+ - *.swc*: NeuroMorpho.org format for cellular morphology
+ - *.p*: Genesis format
+
+ - moose::SymCompartment: Make a SymCompartment for the spine. Deprecated.
+ - moose::Compartment: Make a Compartment for the spine. Deprecated.
+
+
+chanProto
+~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). The empty list does not define any channels.
+
+Use: Each list entry must have a string for the *source*. It can optionally
+have a second string for the *destination*, which is the name to give to the
+*source* channel when it is constructed on */library*.
+
+.. _Open Source Brain: http://www.opensourcebrain.org/
+
+The following options are available for specifying the *source* for
+making channel prototypes:
+
+ - Filepath. This is relative to the working directory. The following
+ file types are known:
+
+ - xml: ChannelML, which is a subset of NeuroML
+ - nml: ChannelML, which is a subset of NeuroML
+
+ Channels in thse formats are available from `Open Source Brain`_,
+
+ - Predefined channel prototypes, available as functions within
+ rdesigneur. This is indicated by the use of braces after the name.
+ The following prototypes are currently available:
+
+ - make_HH_Na(): Make the classical Hodgkin-Huxley Na channel, with
+ kinetics scaled to SI units.
+ - make_HH_K(): Classical HH delayed rectifier K channel.
+ - make_Na(): Hippocampal pyramidal Na channel from Traub 1991.
+ - make_K_DR(): Hippocampal pyramidal K delayed rectifier channel
+ from Traub 1991.
+ - make_K_A(): Hippocampal pyramidal A-type K channel from Traub
+ 1991.
+ - make_Ca_conc(): A calcium pool with tau 13.333 ms. This is
+ required for the calcium dynamics of several channels.
+ - make_Ca(): Voltage-gated Calcium channel, based on Traub 1991. It
+ requires the Ca_conc.
+ - make_K_AHP: Voltage and calcium-gated afterhyperpolarization-
+ activated K channel, from Traub 1991. Note that this channel
+ requires the presence of the Ca_conc.
+ - make_K_C: Voltage and calcium-dependent K channel from Traub 1991.
+ This channel requires the presence of the Ca_conc.
+ - make_glu(): Glutamate receptor in the form of dual-exponential
+ alpha functions, with a separate opening (2ms) and closing (9ms)
+ tau. Reversal potential = 0 mV.
+ - make_GABA(): GABA receptor in the form of dual-exponential
+ alpha functions, with a separate opening (4ms) and closing (9ms)
+ tau. Reversal potential = -65 mV.
+
+ - User-defined channel definition functions.
+ These can be from external Python files, using the
+ full path to the file name minus the suffix. The specific function
+ within it is then specified. For example,
+
+ ::
+
+ chanProto = [
+ ['/home/user/models/channelProtos.make_K_AHP()', 'K_AHP']
+ ]
+
+
+chemProto
+~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). The empty list does not define any chemical systems.
+
+Use: Each list entry must have a string for the *source*. It can optionally
+have a second string for the *destination*, which is the name to give to the
+*source* chemical system when it is constructed on */library*.
+
+.. _DOQCS: https://doqcs.ncbs.res.in/
+.. _BioModels: https://www.ebi.ac.uk/biomodels-main/
+
+The following options are available for specifying the *source* for
+making channel prototypes:
+
+ - Filepath. This is relative to the working directory. The following
+ file types are known:
+
+ - xml: SBML
+ - sbml: SBML
+ - .g: GENESIS Kinetikit (kkit.g) format.
+
+ Channels in thse formats are available from the `DOQCS`_ database,
+ and from the `BioModels`_ database,
+ - Predefined functions. At present only one such function is available,
+ **makeChemOscillator()**
+ - User-defined functions.
+ These can be from external Python files, using the
+ full path to the file name minus the suffix. The specific function
+ within it is then specified. For example,
+ ::
+
+ chemProto = [
+ ['/home/user/models/chemProtos.make_Osc()', 'osc']
+ ]
+
+ - Pool objects. These are created on the fly using the form
+ ::
+
+ chemProto = [['moose:Pool', 'a']]
+
+
+passiveDistrib
+~~~~~~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use; This is for adjusting the passive properties of the neuron. Each list
+entry is a list of strings, of the form:
+
+::
+
+ [path, field, expr, [field, expr]...]
+
+Here the *path* is a MOOSE wildcard path, which defines one or more objects.
+Briefly, the '#' character specifies any string, and the double '##' specifies
+any string at any level in the tree. For example, to specify any compartment
+with the string 'dend' you would use *'#dend#'* and to specify any object
+anywhere in the tree you would use *'##'*.
+
+The *field* can be any one of the following:
+
+ - RM: Membrane resistivity, in ohms.m^2
+ - RA: Axial resistivity, in ohms.m
+ - CM: Membrane specific capacitance, in Farads/m^2
+ - Rm: Absolute membrane resistance of that segment, in ohms.
+ - Ra: Absolute axial resistance of that segment, in ohms.
+ - Cm: Absolute membrane capacitance of that segment, in Farads.
+ - Em: Membrane resting potential, in Volts.
+ - initVm: Initial value to set the membrane potential, in Volts.
+
+The *expr* is an expression string that is evaluated to give the desired value
+for the field. This can be as simple as the value itself, but can be a much
+more interesting function of geometrical properties of the cell. The geometry
+arguments available to the *expr* include:
+
+ - p: Path length in metres from the soma, measured along the dendrite.
+ - g: Geometrical distance from the soma.
+ - L: Number of electronic length constants from the soma
+ - len: length of the segment of dendrite
+ - dia: diameter of the segment of dendrite
+ - maxP: Maximum path length of any dendrite in the cell.
+ - maxG: Maximum geometrical distance of any dendrite from soma
+ - maxL: Maximum electrotonic distance of any dendrite from the soma
+
+Putting these together, here is an example of using the passiveDistrib:
+
+::
+
+ passiveDistrib = [
+ [ 'soma', 'RM', '1.0', 'CM', '0.02' ],
+ [ '#dend#', 'RM', '1.5 + 0.5*(p>200e-6)', 'CM', '0.01' ],
+ ]
+
+This means set the soma *RM* to 1.0, and *CM* to 0.02, leaving the *RA* as the
+default. The scaled value for *Rm*, *Ra*, and *Cm* are computed by scaling
+these terms according to the soma dimensions.
+For all dendrite compartments, set the *RM* to 1.5 provided it is closer than
+200 microns dendritic path length from the soma, and set the *RM* to 2.0 for
+all dendritic compartments further than this.
+Finally, for all dendrite compartments, set *CM* to 0.01. Note that again
+the absolute *Rm* and *Cm* will be scaled according to the local compartment
+dimensions.
+
+spineDistrib
+~~~~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This is for inserting dendritic spines onto the neuron.
+Each entry is a list of strings, of the form:
+
+::
+
+ [proto, path, [spacing, minSpacing, size, sizeDistrib, angle, angleDistrib]]
+
+Of these, the *name* and the *path* are required entries, and the remainder
+can be provided in pairs. The defaults for these entries are:
+
+::
+
+ ['spine', '#dend#,#apical#', '10e-6', '1e-6', '1', '0.5', '0', '6.2832' ]
+
+
+The interpretation of the arguments is as follows:
+
+ - name: This is the name of the `spine prototype`_.
+ - path: The wildcard path of compartments on which to insert the spines.
+ In the example above, *'#dend#,#apical#'* means all compartments with
+ the strings *dend* or *apical* in their names.
+ - spacing: The mean spacing between spines. At present the spines are placed
+ with a Poisson distribution. This is a math expression with the same
+ terms as used for the passive distribution, so that the spine spacing
+ can be a function of spine position along the dendritic tree. The form
+ of this expression is shown again below.
+ - minSpacing: The minimum spacing, and the increment along which the
+ Poisson samples are taken to decide if a spine should be added.
+ In case *minSpacing* is negative, the system places spines with uniform
+ *spacing* along the dendritic segment. If
+ ``segment length < 0.5 * spacing``
+ then the system falls back onto Poisson samples so that finely
+ subdivided dendrites don't miss out on spines altogether.
+ - size: Scale factor for size from the prototype spine. All dimension of
+ the spine are scaled by this number: shaft length, shaft diameter,
+ head length and head diameter. This is a math expression, as shown below.
+ - sizeDistrib: The range of distribution of sizes. This is a linear
+ distribution centered around the defined size.
+ - angle: The initial angle of the first spine on each dendrite compartment,
+ in radians. This is a math expression, as shown below.
+ - angleDistrib: The range of of angles around this initial angle.
+ The angle will be chosen from a linear distribution centered around the
+ centre angle, +/- angleDistrib.
+
+The expression used for spacing, size, and angle is of the form of an
+an expression string that is evaluated to give the desired value
+for the field. This can be as simple as the value itself, but can be a much
+more interesting function of geometrical properties of the cell. The geometry
+arguments available to the *expr* include:
+
+ - p: Path length in metres from the soma, measured along the dendrite.
+ - g: Geometrical distance from the soma.
+ - L: Number of electronic length constants from the soma
+ - len: length of the segment of dendrite
+ - dia: diameter of the segment of dendrite
+ - maxP: Maximum path length of any dendrite in the cell.
+ - maxG: Maximum geometrical distance of any dendrite from soma
+ - maxL: Maximum electrotonic distance of any dendrite from the soma
+
+For example:
+
+::
+
+ ['spine', '#dend#', '1e-6 + (dia<2e-6)*10', '1e-7', '1', '0.5', '6.28*p/maxP', '0']
+
+**proto**: The prototype spine by the name of *spine* is used.
+
+**path**: All compartments with the string *dend* in their name are used.
+
+**Spacing**: The spines are only placed on branches smaller than 2 microns
+(otherwise the spine spacing is 10 metres). On these small branches the
+spacing is, on average, 1 micron.
+
+**Size**: The size is anything from 50% to 150% of the prototype spine size.
+
+**Angle**: The angle is proportional to the distance from the soma, such that
+the spines make a complete spiral (2pi) around the dendrite over its length.
+
+
+chanDistrib
+~~~~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This is for inserting ion channels onto the neuron.
+Each entry is a list of strings, of the form:
+
+::
+
+ [proto, path, field, expr, [field, expr]...]
+
+The entries here are of the form:
+
+ - proto: Specifies the name of the prototype channel to insert
+ - path: Wildcard path of compartments in which to insert the channel
+ - field: Field to assign to channel, almost always **Gbar**, to set its
+ channel density.
+ - expr: Expression evaluated to obtain value to assign to field. This is a
+ mathematical expression of various geometrical properties of the cell,
+ as listed below.
+
+.. _`usual function`:
+
+The *expr* can be as simple as the value itself, but can be a much
+more interesting function of geometrical properties of the cell. The geometry
+arguments available to the *expr* include:
+
+ - p: Path length in metres from the soma, measured along the dendrite.
+ - g: Geometrical distance from the soma.
+ - L: Number of electronic length constants from the soma
+ - len: length of the segment of dendrite
+ - dia: diameter of the segment of dendrite
+ - maxP: Maximum path length of any dendrite in the cell.
+ - maxG: Maximum geometrical distance of any dendrite from soma
+ - maxL: Maximum electrotonic distance of any dendrite from the soma
+
+A typical channel distribution entry is:
+
+::
+
+ ["kdr", "#", "Gbar", "p < 50e-6 ? 500 : 100" ]
+
+Here the *kdr* channel is inserted throughout the cell, and its conductance
+is at 500 Siemens/m^2 for all regions closer than 50 microns, and 100 S/m^2
+for the rest of the cell. Basically there is lots of the channel on and
+near the soma.
+
+chemDistrib
+~~~~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This is for inserting a chemical system into the neuron
+Each entry is a list of strings, of the form:
+
+::
+
+ [proto, path, 'install', expr]
+
+The entries here are of the form:
+
+ - proto: Specifies the name of the prototype chemical system to insert
+ - path: Wildcard path of compartments in which to insert the channel
+ - 'install': Default string.
+ - expr: Expression evaluated to decide whether to install the chemical
+ system. This is the `usual function`_ of geometrical properties of the
+ cell. It is usually '1', to tell the system to install throughout the
+ *path*.
+
+The chemical distribution is handled specially for assignment to the neuronal
+morphology. This is because a given chemical system will have reactions
+between dendrite, ER, spines and PSD, as well as diffusion between these
+zones. Thus, though it would be convenient, we cannot simply define separate
+chemical systems for each cellular compartment. Instead we use one of two
+conventions for doing the assignment.
+
+1. Volume based. If the model format does not permit explicit naming of the
+ chemical compartments in the model, then the assignment is inferred from
+ the volume of each compartment. This limitation applies for the legacy
+ Genesis/kkit **.g** format. It may also apply to SBML models that do not
+ assign suitable names for their chemical compartments. In this case
+ the largest chemical compartment is
+ assigned to the dendrite, the next (if present) to the spine head, and the
+ smallest (if present) to the spine PSD.
+
+ This is modified in one of two ways by the flags `addSomaChemCompt`_ and
+ `addEndoChemCompt`_.
+
+ *addSomaChemCompt* instructs rdesigneur to use the largest compartment for
+ the soma. The remaining compartments follow in the usual order.
+
+ *addEndoChemCompt* instructs rdesigneur to insert an EndoCompartment in
+ each neuronal compartment. The volume order is now dend, dend_endo,
+ spine-head, spine-head-endo and so on.
+
+2. Name based. This works for recent SBML models, which can assign a compartment
+ name to each of the chemical compartments. Here the expectation is that the
+ names are one of *soma*, *soma_endo*, *dend*, *dend_endo*, *spine*,
+ *spine_endo*, *psd*, *psd_endo*.
+ Note that the last one, though permitted, doesn't make much biological
+ sense.
+
+
+adaptorList
+~~~~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This is for implementing an adaptor between chemical and electrical, or
+chemical and structural quantities. Adaptors handle the conversion between
+distinct concepts in chemical and electrical models. For example, Calcium
+concentration as computed electrically in the Ca_conc objects, can map to the
+calcium concentration of the ion as a molecule, where it can react, diffuse,
+and undergo other calcium dynamics. Another common use is to map the
+concentration of the molecular state of an ion channel, to its conductance.
+The adaptor applies the conversion equation **y = mx + c** where **y** is the
+target value, **x** is the source value, **m** is the slope of the conversion,
+and **c** is the offset.
+
+Adaptors automatically average over multiple inputs if the mapping requires.
+Typically electrical segments each contain many chemical voxels, so the
+adaptor averages all the source chemical quantities to apply to the
+corresponding electrical quantity. Similarly, each chemical timestep is
+typically much longer than the electrical timestep, so the adaptor averages
+the electrical quantity over the entire duration of the chemical timestep.
+
+Each entry is a list of strings, of the form:
+
+::
+
+ [source, source_field, dest, dest_field, offset, scaling]
+
+The entries here are:
+
+ - source: Specifies the path of the objects whose quantities need to be
+ converted. In the case of chemical quantities, the path starts with the
+ compartment name, one of *dend*, *spine*, or *psd*. So the molecule
+ Ca in the dendrite would be identified as *dend/Ca*.
+ - source_field: The field on the source object whose value is to be used.
+ - dest: Path of destination object, whose quantities will be assigned.
+ As above, chemical quantities are prefixed by their compartment name.
+ - dest_field: Field to be assigned on the destination object.
+ - offset: Double. In the conversion, what is the value of the dest_field
+ when the source value is zero?. In other words, the quantity **c** in
+ the conversion equation **y = mx + c**
+ - scaling: Double. The slope **m**.
+
+
+stimList
+~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: Each entry is a list of strings, as follows:
+
+::
+
+ [path, geometry_expr, dest, dest_field, time_expr]
+
+The entries here are:
+ - path: The usual MOOSE wildcard path to identify electrical compartments
+ over which the stimulus will extend. Note that the stimulus may be to
+ a chemical entity, but the spatial location is specified in terms of
+ the electrical compartments in which the chemical system is embedded.
+ - geometry_expr. This is the `usual function`_ of geometrical properties
+ of the cell. If it is non-zero, then the stimulus will apply.
+ There is a special case for synaptic inputs in which the *geometry_expr*
+ is repaced with the synaptic weight, recorded as a string.
+ - dest. This is the destination object for the stimulus.
+ - dest_field. This is the field on the destination object to be assigned.
+ There is a special case for synaptic inputs, where the field can be
+ **periodicsyn** or **randsyn**, representing periodic and random
+ synaptic input respectively.
+ - time_expr: This is the time expression of the value of the stimulus.
+ Unlike the *geometry_expr*, the *time_expr* can take the predefined
+ variable **t** which is the current simulation time. The *time_expr* does
+ not have access to the geometry arguments.
+
+Example 1:
+
+::
+
+ ['head#', '0.5','glu', 'periodicsyn', '1 + 40*(t>10 && t<11)']
+
+This acts on all glutamate receptors on the spine *heads*. It delivers
+periodic synaptic input with weight 0.5 at a basal rate of 1 Hz, rising
+by 40Hz in the interval between 10 and 11 seconds.
+
+Example 2:
+
+::
+
+ ['soma', '1', '.', 'inject', '(1+cos(t/10))*(t>31.4 && t<94)* 0.5e-9' ]
+
+This acts to deliver a current injection on the soma. It delivers cosine
+input of angular frequency 1/10 radians/s, between times 31.4 and 94 seconds,
+with a peak amplitude of 0.5 nA.
+
+Rdesigneur also supports keyword-based argument lists for the stimList.
+Here each entry is an rstim function as follows:
+
+::
+
+ rd.rstim( elecpath, geom_expr, relpath, field, expr )
+
+The default values of the arguments are
+
+::
+
+ rd.rstim(elecpath='soma', geom_expr='1', relpath='.', field='inject', expr='0')
+
+
+Example 3: To get the same outcome as example 2, one could use:
+
+::
+
+ rd.rstim( expr=(1+cos(t/10))*(t>31.4 && t<94)* 0.5e-9' )
+
+because most of the arguments are the same as the defaults.
+
+plotList
+~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This displays a line plot of cellular activity.
+Each entry is a list as follows:
+
+::
+
+ [path, geom_expr, relpath, field, title,
+ [mode, ymin, ymax,saveFile, saveResolution, showFlag ]
+ ]
+
+The entries here are:
+ - path: string. The usual MOOSE wildcard path to identify electrical
+ compartments
+ over which the plots will be sampled. Note that the stimulus may be to
+ a chemical entity, but the spatial location is specified in terms of
+ the electrical compartments in which the chemical system is embedded.
+ - geom_expr: string. This is the `usual function`_ of geometrical
+ properties of the cell. If it is non-zero, then the stimulus will apply.
+ There is a special case for synaptic inputs in which the *geometry_expr*
+ is repaced with the synaptic weight, recorded as a string.
+ - replath: string. Relative path to object whose value is being monitored.
+ - field: string. The field to monitor on the source object.
+ - title: Title string for the generated plot.
+ - mode: Optional. String to decide what kind of plot to make. Options are:
+
+ - *'time'*: Default. Plot time-series
+ - *'wave'*: Generate wave-plot with compartment/voxel number as x axis,
+ value as y axis, and run through a series of frames for different
+ time-points durign simulation.
+ - ymin: Double. Optional. Minimum value for y axis. Default = 0.
+ - ymax: Double. Optional. Maximum value for y axis. Default = 0.
+ If ymin==ymax then the plot autoscales.
+ - saveFile: string. Optional. File in which to save plot contents.
+ Default = "", to
+ indicate that the file is not saved. Currently it can save in *csv* and
+ *xml* formats. *nsdf* will be implemented soon.
+ - show: Bool. Optional. Flag to decide if the plot should be displayed.
+ Default=True.
+
+Rdesigneur also supports keyword-based argument lists for the plotList, having
+the same entries as above. Here are two plotList entries with identical
+outcomes.
+
+::
+
+ ['soma', '1', '.', 'Vm', 'Soma membrane potential'],
+ [rd.rplot( field='Vm', title= 'Soma membrane potential')],
+
+moogList
+~~~~~~~~
+
+Type: List of lists
+
+Default: [] (empty list). Does nothing.
+
+Use: This displays a 3-D plot of cellular activity.
+Each entry is a list as follows:
+
+::
+
+ [path, geom_expr, relpath, field, title, [ymin, ymax]]
+
+The entries here are:
+ - path: string. The usual MOOSE wildcard path to identify electrical
+ compartments
+ over which the display will be sampled. Note that the stimulus may be to
+ a chemical entity, but the spatial location is specified in terms of
+ the electrical compartments in which the chemical system is embedded.
+ - geom_expr: string. This is the `usual function`_ of geometrical
+ properties of the cell. If it is non-zero, then the stimulus will apply.
+ There is a special case for synaptic inputs in which the *geometry_expr*
+ is repaced with the synaptic weight, recorded as a string.
+ - replath: string. Relative path to object whose value is being monitored.
+ - field: string. The field to monitor on the source object.
+ - title: Title string for the generated display.
+ - ymin: Double. Minimum value for y axis. Default = 0.
+ - ymax: Double. Maximum value for y axis. Default = 0.
+ If ymin==ymax then the plot autoscales.
+ - show: Bool. Flag to decide if it should be displayed. Default=True.
+
+Rdesigneur also supports keyword-based argument lists for the moogList, having
+the same entries as above. Here are two moogList entries with identical
+outcomes.
+
+::
+
+ ['soma', '1', 'dend/a', 'conc', 'a Conc', 0, 600 ],
+ [rd.rmoog(relpath='dend/a', field='conc', title = 'a Conc', ymax=600)]
+
+
+To run and display moogli, one replaces the *moose.start()* and the
+*rdes.display()* functions with the line:
+
+::
+
+ rdes.displayMoogli(dt, runtime, rotation, fullscreen, block, azim, elev)
+
+in which the first two arguments are required and the rest are optional and
+can be assigned by keywords.
+
+The arguments are as follows:
+
+ - dt: double. Time interval between frames on the moogli display
+ - runtime: double. Simulation runtime.
+ - rotation: double. How much to rotate the display per frame.
+ Defaults to pi/500.
+ - fullscreen: bool. Flag to do display on the full screen.
+ Defaults to False.
+ - azim: double. Azimuth setting. Defaults to 0.0
+ - elev: double. Elevation setting. Defaults to 0.0
+
+The `moogli primer`_ explains how to use the 3-D display.
diff --git a/docs/source/user/py/references/AdExIF.rst b/docs/source/user/py/references/AdExIF.rst
new file mode 100644
index 0000000000..7ced38eba6
--- /dev/null
+++ b/docs/source/user/py/references/AdExIF.rst
@@ -0,0 +1,65 @@
+AdExIF
+------
+
+.. py:class:: AdExIF
+
+ Leaky Integrate-and-Fire neuron with Exponential spike rise and adaptation via an adapting current w.Rm*Cm * dVm/dt = -(Vm-Em) + deltaThresh * exp((Vm-thresh)/deltaThresh) + Rm*I - w tau\_w * d w /dt = a0*(Vm-Em) - w at each spike, w -> w + b0
+
+ .. py:method:: setW
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getW
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTauW
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTauW
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setA0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getA0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setB0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getB0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: w
+
+ double (*value field*) adaptation current with time constant tauW
+
+
+ .. py:attribute:: tauW
+
+ double (*value field*) time constant of adaptation current w
+
+
+ .. py:attribute:: a0
+
+ double (*value field*) factor for voltage-dependent term in evolution of adaptation current: tau\_w dw/dt = a0*(Vm-Em) - w
+
+
+ .. py:attribute:: b0
+
+ double (*value field*) b0 is added to w, the adaptation current on each spike
diff --git a/docs/source/user/py/references/AdThreshIF.rst b/docs/source/user/py/references/AdThreshIF.rst
new file mode 100644
index 0000000000..1fc7c47193
--- /dev/null
+++ b/docs/source/user/py/references/AdThreshIF.rst
@@ -0,0 +1,65 @@
+AdThreshIF
+----------
+
+.. py:class:: AdThreshIF
+
+ Leaky Integrate-and-Fire neuron with adaptive threshold.Based on Rossant, C., Goodman, D.F.M., Platkiewicz, J., and Brette, R. (2010).Rm*Cm * dVm/dt = -(Vm-Em) + Rm*ItauThresh * d threshAdaptive / dt = a0*(Vm-Em) - threshAdaptive at each spike, threshAdaptive is increased by threshJump the spiking threshold adapts as thresh + threshAdaptive
+
+ .. py:method:: setThreshAdaptive
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThreshAdaptive
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTauThresh
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTauThresh
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setA0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getA0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThreshJump
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThreshJump
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: threshAdaptive
+
+ double (*value field*) adaptative part of the threshold that decays with time constant tauThresh
+
+
+ .. py:attribute:: tauThresh
+
+ double (*value field*) time constant of adaptative part of the threshold
+
+
+ .. py:attribute:: a0
+
+ double (*value field*) factor for voltage-dependent term in evolution of adaptative threshold: tauThresh * d threshAdaptive / dt = a0*(Vm-Em) - threshAdaptive
+
+
+ .. py:attribute:: threshJump
+
+ double (*value field*) threshJump is added to threshAdaptive on each spike
diff --git a/docs/source/user/py/references/Adaptor.rst b/docs/source/user/py/references/Adaptor.rst
new file mode 100644
index 0000000000..c021c6f321
--- /dev/null
+++ b/docs/source/user/py/references/Adaptor.rst
@@ -0,0 +1,90 @@
+Adaptor
+-------
+
+.. py:class:: Adaptor
+
+ This is the adaptor class. It is used in interfacing different kinds of solver with each other, especially for electrical to chemical signeur models. The Adaptor class is the core of the API for interfacing between different solution engines. It is currently in use for interfacing between chemical and electrical simulations, but could be used for other cases such as mechanical models. The API for interfacing between solution engines rests on the following capabilities of MOOSE. 1. The object-oriented interface with classes mapped to biological and modeling concepts such as electrical and chemical compartments, ion channels and molecular pools. 2. The invisible mapping of Solvers (Objects implementing numerical engines) to the object-oriented interface. Solvers work behind the scenes to update the objects. 3. The messaging interface which allows any visible field to be accessed and updated from any other object. 4. The clock-based scheduler which drives operations of any subset of objects at any interval. For example, this permits the operations of field access and update to take place at quite different timescales from the numerical engines. 5. The implementation of Adaptor classes. These perform a linear transformation:: (y = scale * (x + inputOffset) + outputOffset ) where y is output and x is the input. The input is the average of any number of sources (through messages) and any number of timesteps. The output goes to any number of targets, again through messages. It is worth adding that messages can transport arbitrary data structures, so it would also be possible to devise a complicated opaque message directly between solvers. The implementation of Adaptors working on visible fields does this much more transparently and gives the user facile control over the scaling transformatoin. These adaptors are used especially in the rdesigneur framework of MOOSE, which enables multiscale reaction-diffusion and electrical signaling models. As an example of this API in operation, I consider two mappings: 1. Calcium mapped from electrical to chemical computations. 2. phosphorylation state of a channel mapped to the channel conductance. 1. Calcium mapping. Problem statement. Calcium is computed in the electrical solver as one or more pools that are fed by calcium currents, and is removed by an exponential decay process. This calcium pool is non-diffusive in the current electrical solver. It has to be mapped to chemical calcium pools at a different spatial discretization, which do diffuse. In terms of the list of capabilities described above, this is how the API works. 1. The electrical model is partitioned into a number of electrical compartments, some of which have the 'electrical' calcium pool as child object in a UNIX filesystem-like tree. Thus the 'electrical' calcium is represented as an object with concentration, location and so on. 2. The Solver computes the time-course of evolution of the calcium concentration. Whenever any function queries the 'concentration' field of the calcium object, the Solver provides this value. 3. Messaging couples the 'electrical' calcium pool concentration to the adaptor (see point 5). This can either be a 'push' operation, where the solver pushes out the calcium value at its internal update rate, or a 'pull' operation where the adaptor requests the calcium concentration. 4. The clock-based scheduler keeps the electrical and chemical solvers ticking away, but it also can drive the operations of the adaptor. Thus the rate of updates to and from the adaptor can be controlled. 5. The adaptor averages its inputs. Say the electrical solver is going at a timestep of 50 usec, and the chemical solver at 5000 usec. The adaptor will take 100 samples of the electrical concentration, and average them to compute the 'input' to the linear scaling. Suppose that the electrical model has calcium units of micromolar, but has a zero baseline. The chemical model has units of millimolar and a baseline of 1e-4 millimolar. This gives: y = 0.001x + 1e-4 At the end of this calculation, the adaptor will typically 'push' its output to the chemical solver. Here we have similar situation to item (1), where the chemical entities are calcium pools in space, each with their own calcium concentration. The messaging (3) determines another aspect of the mapping here: the fan in or fan out. In this case, a single electrical compartment may house 10 chemical compartments. Then the output message from the adaptor goes to update the calcium pool concentration on the appropriate 10 objects representing calcium in each of the compartments. In much the same manner, the phosphorylation state can regulate channel properties. 1. The chemical model contains spatially distributed chemical pools that represent the unphosphorylated state of the channel, which in this example is the conducting form. This concentration of this unphosphorylated state is affected by the various reaction- diffusion events handled by the chemical solver, below. 2. The chemical solver updates the concentrations of the pool objects as per reaction-diffusion calculations. 3. Messaging couples these concentration terms to the adaptor. In this case we have many chemical pool objects for every electrical compartment. There would be a single adaptor for each electrical compartment, and it would average all the input values for calcium concentration, one for each mesh point in the chemical calculation. As before, the access to these fields could be through a 'push' or a 'pull' operation. 4. The clock-based scheduler oeperates as above. 5. The adaptor averages the spatially distributed inputs from calcium, and now does a different linear transform. In this case it converts chemical concentration into the channel conductance. As before, the 'electrical' channel is an object (point 1) with a field for conductance, and this term is mapped into the internal data structures of the solver (point 2) invisibly to the user.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process message from the scheduler.
+
+
+ .. py:method:: setInputOffset
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInputOffset
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setOutputOffset
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getOutputOffset
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setScale
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getScale
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getOutputValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: input
+
+ (*destination message field*) Input message to the adaptor. If multiple inputs are received, the system averages the inputs.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles 'process' call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles 'reinit' call
+
+
+ .. py:attribute:: output
+
+ double (*source message field*) Sends the output value every timestep.
+
+
+ .. py:attribute:: requestOut
+
+ PSt6vectorIdSaIdEE (*source message field*) Sends out a request to a field with a double or array of doubles. Issued from the process call.Works for any number of targets.
+
+
+ .. py:attribute:: inputOffset
+
+ double (*value field*) Offset to apply to input message, before scaling
+
+
+ .. py:attribute:: outputOffset
+
+ double (*value field*) Offset to apply at output, after scaling
+
+
+ .. py:attribute:: scale
+
+ double (*value field*) Scaling factor to apply to input
+
+
+ .. py:attribute:: outputValue
+
+ double (*value field*) This is the linearly transformed output.
diff --git a/docs/source/user/py/references/Annotator.rst b/docs/source/user/py/references/Annotator.rst
new file mode 100644
index 0000000000..68457d1056
--- /dev/null
+++ b/docs/source/user/py/references/Annotator.rst
@@ -0,0 +1,170 @@
+Annotator
+---------
+
+
+.. py:class:: Annotator
+
+
+ .. py:method:: setX
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNotes
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNotes
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setColor
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getColor
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTextColor
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTextColor
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setIcon
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getIcon
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setSolver
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getSolver
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRuntime
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRuntime
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDirpath
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDirpath
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setModeltype
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getModeltype
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: x
+
+ double (*value field*) x field. Typically display coordinate x
+
+
+ .. py:attribute:: y
+
+ double (*value field*) y field. Typically display coordinate y
+
+
+ .. py:attribute:: z
+
+ double (*value field*) z field. Typically display coordinate z
+
+
+ .. py:attribute:: notes
+
+ string (*value field*) A string to hold some text notes about parent object
+
+
+ .. py:attribute:: color
+
+ string (*value field*) A string to hold a text string specifying display color.Can be a regular English color name, or an rgb code rrrgggbbb
+
+
+ .. py:attribute:: textColor
+
+ string (*value field*) A string to hold a text string specifying color for text labelthat might be on the display for this object.Can be a regular English color name, or an rgb code rrrgggbbb
+
+
+ .. py:attribute:: icon
+
+ string (*value field*) A string to specify icon to use for display
+
+
+ .. py:attribute:: solver
+
+ string (*value field*) A string to specify solver to store for Gui
+
+
+ .. py:attribute:: runtime
+
+ double (*value field*) runtime field. Store runtime
+
+
+ .. py:attribute:: dirpath
+
+ string (*value field*) directory path for Gui
+
+
+ .. py:attribute:: modeltype
+
+ string (*value field*) model type
diff --git a/docs/source/user/py/references/Arith.rst b/docs/source/user/py/references/Arith.rst
new file mode 100644
index 0000000000..d4d8eca05c
--- /dev/null
+++ b/docs/source/user/py/references/Arith.rst
@@ -0,0 +1,99 @@
+Arith
+-----
+
+.. py:class:: Arith
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: setFunction
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getFunction
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setOutputValue
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getOutputValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getArg1Value
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAnyValue
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAnyValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: arg1
+
+ (*destination message field*) Handles argument 1. This just assigns it
+
+
+ .. py:method:: arg2
+
+ (*destination message field*) Handles argument 2. This just assigns it
+
+
+ .. py:method:: arg3
+
+ (*destination message field*) Handles argument 3. This sums in each input, and clears each clock tick.
+
+
+ .. py:method:: arg1x2
+
+ (*destination message field*) Store the product of the two arguments in output\_
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:attribute:: output
+
+ double (*source message field*) Sends out the computed value
+
+
+ .. py:attribute:: function
+
+ string (*value field*) Arithmetic function to perform on inputs.
+
+
+ .. py:attribute:: outputValue
+
+ double (*value field*) Value of output as computed last timestep.
+
+
+ .. py:attribute:: arg1Value
+
+ double (*value field*) Value of arg1 as computed last timestep.
+
+
+ .. py:attribute:: anyValue
+
+ unsigned int,double (*lookup field*) Value of any of the internal fields, output, arg1, arg2, arg3,as specified by the index argument from 0 to 3.
diff --git a/docs/source/user/py/references/BinomialRng.rst b/docs/source/user/py/references/BinomialRng.rst
new file mode 100644
index 0000000000..62e4006fcc
--- /dev/null
+++ b/docs/source/user/py/references/BinomialRng.rst
@@ -0,0 +1,35 @@
+BinomialRng
+-----------
+
+.. py:class:: BinomialRng
+
+ Binomially distributed random number generator.
+
+ .. py:method:: setN
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getN
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setP
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getP
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: n
+
+ double (*value field*) Parameter n of the binomial distribution. In a coin toss experiment, this is the number of tosses.
+
+
+ .. py:attribute:: p
+
+ double (*value field*) Parameter p of the binomial distribution. In a coin toss experiment, this is the probability of one of the two sides of the coin being on top.
diff --git a/docs/source/user/py/references/CaConc.rst b/docs/source/user/py/references/CaConc.rst
new file mode 100644
index 0000000000..5199ee7b0e
--- /dev/null
+++ b/docs/source/user/py/references/CaConc.rst
@@ -0,0 +1,6 @@
+CaConc
+------
+
+.. py:class:: CaConc
+
+ CaConc: Calcium concentration pool. Takes current from a channel and keeps track of calcium buildup and depletion by a single exponential process.
diff --git a/docs/source/user/py/references/CaConcBase.rst b/docs/source/user/py/references/CaConcBase.rst
new file mode 100644
index 0000000000..a8e59b4153
--- /dev/null
+++ b/docs/source/user/py/references/CaConcBase.rst
@@ -0,0 +1,202 @@
+CaConcBase
+----------
+
+.. py:class:: CaConcBase
+
+ CaConcBase: Base class for Calcium concentration pool. Takes current from a channel and keeps track of calcium buildup and depletion by a single exponential process.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message to receive Process message from scheduler
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: setCa
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCa
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaBasal
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaBasal
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCa\_base
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCa\_base
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTau
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTau
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThick
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThick
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiameter
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiameter
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLength
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLength
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCeiling
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCeiling
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setFloor
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getFloor
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: current
+
+ (*destination message field*) Calcium Ion current, due to be converted to conc.
+
+
+ .. py:method:: currentFraction
+
+ (*destination message field*) Fraction of total Ion current, that is carried by Ca2+.
+
+
+ .. py:method:: increase
+
+ (*destination message field*) Any input current that increases the concentration.
+
+
+ .. py:method:: decrease
+
+ (*destination message field*) Any input current that decreases the concentration.
+
+
+ .. py:method:: basal
+
+ (*destination message field*) Synonym for assignment of basal conc.
+
+
+ .. py:attribute:: concOut
+
+ double (*source message field*) Concentration of Ca in pool
+
+
+ .. py:attribute:: Ca
+
+ double (*value field*) Calcium concentration.
+
+
+ .. py:attribute:: CaBasal
+
+ double (*value field*) Basal Calcium concentration.
+
+
+ .. py:attribute:: Ca\_base
+
+ double (*value field*) Basal Calcium concentration, synonym for CaBasal
+
+
+ .. py:attribute:: tau
+
+ double (*value field*) Settling time for Ca concentration
+
+
+ .. py:attribute:: B
+
+ double (*value field*) Volume scaling factor. Deprecated. This is a legacy field from GENESIS and exposes internal calculations. Please do not use.
+ B = 1/(vol * F) so that it obeys:
+ dC/dt = B*I\_Ca - C/tau
+
+
+ .. py:attribute:: thick
+
+ double (*value field*) Thickness of Ca shell, assumed cylindrical. Legal range is between zero and the radius. If outside this range it is taken as the radius. Default zero, ie, the shell is the entire thickness of the cylinder
+
+
+ .. py:attribute:: diameter
+
+ double (*value field*) Diameter of Ca shell, assumed cylindrical
+
+
+ .. py:attribute:: length
+
+ double (*value field*) Length of Ca shell, assumed cylindrical
+
+
+ .. py:attribute:: ceiling
+
+ double (*value field*) Ceiling value for Ca concentration. If Ca > ceiling, Ca = ceiling. If ceiling <= 0.0, there is no upper limit on Ca concentration value.
+
+
+ .. py:attribute:: floor
+
+ double (*value field*) Floor value for Ca concentration. If Ca < floor, Ca = floor
diff --git a/docs/source/user/py/references/ChanBase.rst b/docs/source/user/py/references/ChanBase.rst
new file mode 100644
index 0000000000..9236699d1a
--- /dev/null
+++ b/docs/source/user/py/references/ChanBase.rst
@@ -0,0 +1,125 @@
+ChanBase
+--------
+
+.. py:class:: ChanBase
+
+ ChanBase: Base class for assorted ion channels.Presents a common interface for all of them.
+
+ .. py:attribute:: channel
+
+ void (*shared message field*) This is a shared message to couple channel to compartment. The first entry is a MsgSrc to send Gk and Ek to the compartment The second entry is a MsgDest for Vm from the compartment.
+
+
+ .. py:attribute:: ghk
+
+ void (*shared message field*) Message to Goldman-Hodgkin-Katz object
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message to receive Process message from scheduler
+
+
+ .. py:method:: Vm
+
+ (*destination message field*) Handles Vm message coming in from compartment
+
+
+ .. py:method:: Vm
+
+ (*destination message field*) Handles Vm message coming in from compartment
+
+
+ .. py:method:: setGbar
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGbar
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setModulation
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getModulation
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setEk
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getEk
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setGk
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGk
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getIk
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:attribute:: channelOut
+
+ double,double (*source message field*) Sends channel variables Gk and Ek to compartment
+
+
+ .. py:attribute:: permeabilityOut
+
+ double (*source message field*) Conductance term going out to GHK object
+
+
+ .. py:attribute:: IkOut
+
+ double (*source message field*) Channel current. This message typically goes to concenobjects that keep track of ion concentration.
+
+
+ .. py:attribute:: Gbar
+
+ double (*value field*) Maximal channel conductance
+
+
+ .. py:attribute:: modulation
+
+ double (*value field*) Modulation, i.e, scale factor for channel conductance.Note that this is a regular parameter, it is not recomputed each timestep. Thus one can use a slow update, say, from a molecule pool, to send a message to set the modulation, and it will stay at the set value even if the channel runs many timesteps before the next assignment. This differs from the GENESIS semantics of a similar message,which required update each timestep.
+
+
+ .. py:attribute:: Ek
+
+ double (*value field*) Reversal potential of channel
+
+
+ .. py:attribute:: Gk
+
+ double (*value field*) Channel conductance variable
+
+
+ .. py:attribute:: Ik
+
+ double (*value field*) Channel current variable
diff --git a/docs/source/user/py/references/ChemCompt.rst b/docs/source/user/py/references/ChemCompt.rst
new file mode 100644
index 0000000000..318e93a5c4
--- /dev/null
+++ b/docs/source/user/py/references/ChemCompt.rst
@@ -0,0 +1,115 @@
+ChemCompt
+---------
+
+.. py:class:: ChemCompt
+
+ Pure virtual base class for chemical compartments
+
+ .. py:method:: setVolume
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVolume
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getVoxelVolume
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getVoxelMidpoint
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setOneVoxelVolume
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getOneVoxelVolume
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumDimensions
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getStencilRate
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getStencilIndex
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: buildDefaultMesh
+
+ (*destination message field*) Tells ChemCompt derived class to build a default mesh with thespecified volume and number of meshEntries.
+
+
+ .. py:method:: setVolumeNotRates
+
+ (*destination message field*) Changes volume but does not notify any child objects.Only works if the ChemCompt has just one voxel.This function will invalidate any concentration term inthe model. If you don't know why you would want to do this,then you shouldn't use this function.
+
+
+ .. py:method:: resetStencil
+
+ (*destination message field*) Resets the diffusion stencil to the core stencil that only includes the within-mesh diffusion. This is needed prior to building up the cross-mesh diffusion through junctions.
+
+
+ .. py:method:: setNumMesh
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumMesh
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: voxelVolOut
+
+ vector (*source message field*) Sends updated voxel volume out to Ksolve, Gsolve, and Dsolve.Used to request a recalculation of rates and of initial numbers.
+
+
+ .. py:attribute:: volume
+
+ double (*value field*) Volume of entire chemical domain.Assigning this only works if the chemical compartment hasonly a single voxel. Otherwise ignored.This function goes through all objects below this on thetree, and rescales their molecule #s and rates as per thevolume change. This keeps concentration the same, and alsomaintains rates as expressed in volume units.
+
+
+ .. py:attribute:: voxelVolume
+
+ vector (*value field*) Vector of volumes of each of the voxels.
+
+
+ .. py:attribute:: voxelMidpoint
+
+ vector (*value field*) Vector of midpoint coordinates of each of the voxels. The size of this vector is 3N, where N is the number of voxels. The first N entries are for x, next N for y, last N are z.
+
+
+ .. py:attribute:: numDimensions
+
+ unsigned int (*value field*) Number of spatial dimensions of this compartment. Usually 3 or 2
+
+
+ .. py:attribute:: oneVoxelVolume
+
+ unsigned int,double (*lookup field*) Volume of specified voxel.
+
+
+ .. py:attribute:: stencilRate
+
+ unsigned int,vector (*lookup field*) vector of diffusion rates in the stencil for specified voxel.The identity of the coupled voxels is given by the partner field 'stencilIndex'.Returns an empty vector for non-voxelized compartments.
+
+
+ .. py:attribute:: stencilIndex
+
+ unsigned int,vector (*lookup field*) vector of voxels diffusively coupled to the specified voxel.The diffusion rates into the coupled voxels is given by the partner field 'stencilRate'.Returns an empty vector for non-voxelized compartments.
diff --git a/docs/source/user/py/references/Cinfo.rst b/docs/source/user/py/references/Cinfo.rst
new file mode 100644
index 0000000000..4147a8d653
--- /dev/null
+++ b/docs/source/user/py/references/Cinfo.rst
@@ -0,0 +1,27 @@
+Cinfo
+-----
+
+
+
+.. py:class:: Cinfo
+
+ Class information object.
+
+ .. py:method:: getDocs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getBaseClass
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: docs
+
+ string (*value field*) Documentation
+
+
+ .. py:attribute:: baseClass
+
+ string (*value field*) Name of base class
diff --git a/docs/source/user/py/references/Clock.rst b/docs/source/user/py/references/Clock.rst
new file mode 100644
index 0000000000..bb4528d447
--- /dev/null
+++ b/docs/source/user/py/references/Clock.rst
@@ -0,0 +1,742 @@
+Clock
+-----
+
+.. py:class:: Clock
+
+ Every object scheduled for operations in MOOSE is connected to oneof the 'Tick' entries on the Clock.
+ The Clock manages 32 'Ticks', each of which has its own dt,which is an integral multiple of the clock baseDt\_. On every clock step the ticks are examined to see which of themis due for updating. When a tick is updated, the 'process' call of all the objects scheduled on that tick is called. Order of execution: If a subset of ticks are scheduled for execution at a given timestep, then they will be executed in numerical order, lowest tick first and highest last. There is no guarantee of execution order for objects within a clock tick.
+ The clock provides default scheduling for all objects which can be accessed using Clock::lookupDefaultTick( className ). Specific items of note are that the output/file dump objects are second-last, and the postmaster is last on the order of Ticks. The clock also starts up with some default timesteps for each of these ticks, and this can be overridden using the shell command setClock, or by directly assigning tickStep values on the clock object.
+ Which objects use which tick? As a rule of thumb, try this:
+ Electrical/compartmental model calculations: Ticks 0-7
+ Tables and output objects for electrical output: Tick 8
+ Diffusion solver: Tick 10
+ Chemical/compartmental model calculations: Ticks 11-17
+ Tables and output objects for chemical output: Tick 18
+ Unassigned: Ticks 20-29
+ Special: 30-31
+ Data output is a bit special, since you may want to store data at different rates for electrical and chemical processes in the same model. Here you will have to specifically assign distinct clock ticks for the tables/fileIO objects handling output at different time-resolutions. Typically one uses tick 8 and 18.
+ Here are the detailed mappings of class to tick.
+ | Class Tick dt
+ | DiffAmp 0 50e-6
+ | Interpol 0 50e-6
+ | PIDController 0 50e-6
+ | PulseGen 0 50e-6
+ | StimulusTable 0 50e-6
+ | testSched 0 50e-6
+ | VClamp 0 50e-6
+ | SynHandlerBase 1 50e-6
+ | SimpleSynHandler 1 50e-6
+ | STDPSynHandler 1 50e-6
+ GraupnerBrunel2012CaPlasticitySynHandler 1 50e-6
+ SeqSynHandler 1 50e-6
+ CaConc 1 50e-6
+ CaConcBase 1 50e-6
+ DifShell 1 50e-6
+ MgBlock 1 50e-6
+ Nernst 1 50e-6
+ RandSpike 1 50e-6
+ ChanBase 2 50e-6
+ IntFire 2 50e-6
+ IntFireBase 2 50e-6
+ LIF 2 50e-6
+ QIF 2 50e-6
+ ExIF 2 50e-6
+ AdExIF 2 50e-6
+ AdThreshIF 2 50e-6
+ IzhIF 2 50e-6
+ IzhikevichNrn 2 50e-6
+ SynChan 2 50e-6
+ NMDAChan 2 50e-6
+ GapJunction 2 50e-6
+ HHChannel 2 50e-6
+ HHChannel2D 2 50e-6
+ Leakage 2 50e-6
+ MarkovChannel 2 50e-6
+ MarkovGslSolver 2 50e-6
+ MarkovRateTable 2 50e-6
+ MarkovSolver 2 50e-6
+ MarkovSolverBase 2 50e-6
+ RC 2 50e-6
+ Compartment (init) 3 50e-6
+ CompartmentBase (init ) 3 50e-6
+ SymCompartment (init) 3 50e-6
+ Compartment 4 50e-6
+ CompartmentBase 4 50e-6
+ SymCompartment 4 50e-6
+ SpikeGen 5 50e-6
+ HSolve 6 50e-6
+ SpikeStats 7 50e-6
+ Table 8 0.1e-3
+ TimeTable 8 0.1e-3
+ Dsolve 10 0.01
+ Adaptor 11 0.1
+ Func 12 0.1
+ Function 12 0.1
+ Arith 12 0.1
+ BufPool 13 0.1
+ Pool 13 0.1
+ PoolBase 13 0.1
+ CplxEnzBase 14 0.1
+ Enz 14 0.1
+ EnzBase 14 0.1
+ MMenz 14 0.1
+ Reac 14 0.1
+ ReacBase 14 0.1
+ Gsolve (init) 15 0.1
+ Ksolve (init) 15 0.1
+ Gsolve 16 0.1
+ Ksolve 16 0.1
+ Stats 17 0.1
+ Table2 18 1
+ Streamer 19 10
+ HDF5DataWriter 30 1
+ HDF5WriterBase 30 1
+ NSDFWriter 30 1
+ PyRun 30 1
+ PostMaster 31 0.01
+
+ Note that the other classes are not scheduled at all.
+
+ .. py:attribute:: clockControl
+
+ void (*shared message field*) Controls all scheduling aspects of Clock, usually from Shell
+
+
+ .. py:attribute:: proc0
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc1
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc2
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc3
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc4
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc5
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc6
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc7
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc8
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc9
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc10
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc11
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc12
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc13
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc14
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc15
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc16
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc17
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc18
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc19
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc20
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc21
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc22
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc23
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc24
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc25
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc26
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc27
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc28
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc29
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc30
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:attribute:: proc31
+
+ void (*shared message field*) Shared process/reinit message
+
+
+ .. py:method:: setBaseDt
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getBaseDt
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getRunTime
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getCurrentTime
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNsteps
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumTicks
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getStride
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getCurrentStep
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDts
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getIsRunning
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTickStep
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTickStep
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTickDt
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTickDt
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDefaultTick
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: start
+
+ (*destination message field*) Sets off the simulation for the specified duration
+
+
+ .. py:method:: step
+
+ (*destination message field*) Sets off the simulation for the specified # of steps. Here each step advances the simulation by the timestep of the smallest tick that is actually in use.
+
+
+ .. py:method:: stop
+
+ (*destination message field*) Halts the simulation, with option to restart seamlessly
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Zeroes out all ticks, starts at t = 0
+
+
+ .. py:attribute:: finished
+
+ void (*source message field*) Signal for completion of run
+
+
+ .. py:attribute:: process0
+
+ PK8ProcInfo (*source message field*) process for Tick 0
+
+
+ .. py:attribute:: reinit0
+
+ PK8ProcInfo (*source message field*) reinit for Tick 0
+
+
+ .. py:attribute:: process1
+
+ PK8ProcInfo (*source message field*) process for Tick 1
+
+
+ .. py:attribute:: reinit1
+
+ PK8ProcInfo (*source message field*) reinit for Tick 1
+
+
+ .. py:attribute:: process2
+
+ PK8ProcInfo (*source message field*) process for Tick 2
+
+
+ .. py:attribute:: reinit2
+
+ PK8ProcInfo (*source message field*) reinit for Tick 2
+
+
+ .. py:attribute:: process3
+
+ PK8ProcInfo (*source message field*) process for Tick 3
+
+
+ .. py:attribute:: reinit3
+
+ PK8ProcInfo (*source message field*) reinit for Tick 3
+
+
+ .. py:attribute:: process4
+
+ PK8ProcInfo (*source message field*) process for Tick 4
+
+
+ .. py:attribute:: reinit4
+
+ PK8ProcInfo (*source message field*) reinit for Tick 4
+
+
+ .. py:attribute:: process5
+
+ PK8ProcInfo (*source message field*) process for Tick 5
+
+
+ .. py:attribute:: reinit5
+
+ PK8ProcInfo (*source message field*) reinit for Tick 5
+
+
+ .. py:attribute:: process6
+
+ PK8ProcInfo (*source message field*) process for Tick 6
+
+
+ .. py:attribute:: reinit6
+
+ PK8ProcInfo (*source message field*) reinit for Tick 6
+
+
+ .. py:attribute:: process7
+
+ PK8ProcInfo (*source message field*) process for Tick 7
+
+
+ .. py:attribute:: reinit7
+
+ PK8ProcInfo (*source message field*) reinit for Tick 7
+
+
+ .. py:attribute:: process8
+
+ PK8ProcInfo (*source message field*) process for Tick 8
+
+
+ .. py:attribute:: reinit8
+
+ PK8ProcInfo (*source message field*) reinit for Tick 8
+
+
+ .. py:attribute:: process9
+
+ PK8ProcInfo (*source message field*) process for Tick 9
+
+
+ .. py:attribute:: reinit9
+
+ PK8ProcInfo (*source message field*) reinit for Tick 9
+
+
+ .. py:attribute:: process10
+
+ PK8ProcInfo (*source message field*) process for Tick 10
+
+
+ .. py:attribute:: reinit10
+
+ PK8ProcInfo (*source message field*) reinit for Tick 10
+
+
+ .. py:attribute:: process11
+
+ PK8ProcInfo (*source message field*) process for Tick 11
+
+
+ .. py:attribute:: reinit11
+
+ PK8ProcInfo (*source message field*) reinit for Tick 11
+
+
+ .. py:attribute:: process12
+
+ PK8ProcInfo (*source message field*) process for Tick 12
+
+
+ .. py:attribute:: reinit12
+
+ PK8ProcInfo (*source message field*) reinit for Tick 12
+
+
+ .. py:attribute:: process13
+
+ PK8ProcInfo (*source message field*) process for Tick 13
+
+
+ .. py:attribute:: reinit13
+
+ PK8ProcInfo (*source message field*) reinit for Tick 13
+
+
+ .. py:attribute:: process14
+
+ PK8ProcInfo (*source message field*) process for Tick 14
+
+
+ .. py:attribute:: reinit14
+
+ PK8ProcInfo (*source message field*) reinit for Tick 14
+
+
+ .. py:attribute:: process15
+
+ PK8ProcInfo (*source message field*) process for Tick 15
+
+
+ .. py:attribute:: reinit15
+
+ PK8ProcInfo (*source message field*) reinit for Tick 15
+
+
+ .. py:attribute:: process16
+
+ PK8ProcInfo (*source message field*) process for Tick 16
+
+
+ .. py:attribute:: reinit16
+
+ PK8ProcInfo (*source message field*) reinit for Tick 16
+
+
+ .. py:attribute:: process17
+
+ PK8ProcInfo (*source message field*) process for Tick 17
+
+
+ .. py:attribute:: reinit17
+
+ PK8ProcInfo (*source message field*) reinit for Tick 17
+
+
+ .. py:attribute:: process18
+
+ PK8ProcInfo (*source message field*) process for Tick 18
+
+
+ .. py:attribute:: reinit18
+
+ PK8ProcInfo (*source message field*) reinit for Tick 18
+
+
+ .. py:attribute:: process19
+
+ PK8ProcInfo (*source message field*) process for Tick 19
+
+
+ .. py:attribute:: reinit19
+
+ PK8ProcInfo (*source message field*) reinit for Tick 19
+
+
+ .. py:attribute:: process20
+
+ PK8ProcInfo (*source message field*) process for Tick 20
+
+
+ .. py:attribute:: reinit20
+
+ PK8ProcInfo (*source message field*) reinit for Tick 20
+
+
+ .. py:attribute:: process21
+
+ PK8ProcInfo (*source message field*) process for Tick 21
+
+
+ .. py:attribute:: reinit21
+
+ PK8ProcInfo (*source message field*) reinit for Tick 21
+
+
+ .. py:attribute:: process22
+
+ PK8ProcInfo (*source message field*) process for Tick 22
+
+
+ .. py:attribute:: reinit22
+
+ PK8ProcInfo (*source message field*) reinit for Tick 22
+
+
+ .. py:attribute:: process23
+
+ PK8ProcInfo (*source message field*) process for Tick 23
+
+
+ .. py:attribute:: reinit23
+
+ PK8ProcInfo (*source message field*) reinit for Tick 23
+
+
+ .. py:attribute:: process24
+
+ PK8ProcInfo (*source message field*) process for Tick 24
+
+
+ .. py:attribute:: reinit24
+
+ PK8ProcInfo (*source message field*) reinit for Tick 24
+
+
+ .. py:attribute:: process25
+
+ PK8ProcInfo (*source message field*) process for Tick 25
+
+
+ .. py:attribute:: reinit25
+
+ PK8ProcInfo (*source message field*) reinit for Tick 25
+
+
+ .. py:attribute:: process26
+
+ PK8ProcInfo (*source message field*) process for Tick 26
+
+
+ .. py:attribute:: reinit26
+
+ PK8ProcInfo (*source message field*) reinit for Tick 26
+
+
+ .. py:attribute:: process27
+
+ PK8ProcInfo (*source message field*) process for Tick 27
+
+
+ .. py:attribute:: reinit27
+
+ PK8ProcInfo (*source message field*) reinit for Tick 27
+
+
+ .. py:attribute:: process28
+
+ PK8ProcInfo (*source message field*) process for Tick 28
+
+
+ .. py:attribute:: reinit28
+
+ PK8ProcInfo (*source message field*) reinit for Tick 28
+
+
+ .. py:attribute:: process29
+
+ PK8ProcInfo (*source message field*) process for Tick 29
+
+
+ .. py:attribute:: reinit29
+
+ PK8ProcInfo (*source message field*) reinit for Tick 29
+
+
+ .. py:attribute:: process30
+
+ PK8ProcInfo (*source message field*) process for Tick 30
+
+
+ .. py:attribute:: reinit30
+
+ PK8ProcInfo (*source message field*) reinit for Tick 30
+
+
+ .. py:attribute:: process31
+
+ PK8ProcInfo (*source message field*) process for Tick 31
+
+
+ .. py:attribute:: reinit31
+
+ PK8ProcInfo (*source message field*) reinit for Tick 31
+
+
+ .. py:attribute:: baseDt
+
+ double (*value field*) Base timestep for simulation. This is the smallest dt out of all the clock ticks. By definition all other timesteps are integral multiples of this, and are rounded to ensure that this is the case .
+
+
+ .. py:attribute:: runTime
+
+ double (*value field*) Duration to run the simulation
+
+
+ .. py:attribute:: currentTime
+
+ double (*value field*) Current simulation time
+
+
+ .. py:attribute:: nsteps
+
+ unsigned long (*value field*) Number of steps to advance the simulation, in units of the smallest timestep on the clock ticks
+
+
+ .. py:attribute:: numTicks
+
+ unsigned int (*value field*) Number of clock ticks
+
+
+ .. py:attribute:: stride
+
+ unsigned int (*value field*) Number by which the simulation advances the current step on each cycle. stride = smallest active timestep/smallest defined timestep.
+
+
+ .. py:attribute:: currentStep
+
+ unsigned long (*value field*) Current simulation step
+
+
+ .. py:attribute:: dts
+
+ vector (*value field*) Utility function returning the dt (timestep) of all ticks.
+
+
+ .. py:attribute:: isRunning
+
+ bool (*value field*) Utility function to report if simulation is in progress.
+
+
+ .. py:attribute:: tickStep
+
+ unsigned int,unsigned int (*lookup field*) Step size of specified Tick, as integral multiple of dt\_ A zero step size means that the Tick is inactive
+
+
+ .. py:attribute:: tickDt
+
+ unsigned int,double (*lookup field*) Timestep dt of specified Tick. Always integral multiple of dt\_. If you assign a non-integer multiple it will round off. A zero timestep means that the Tick is inactive
+
+
+ .. py:attribute:: defaultTick
+
+ string,unsigned int (*lookup field*) Looks up the default Tick to use for the specified class. If no tick is assigned, as for classes without a process operation or zombie classes, the tick is ~0U. If nothing can be found returns 0 and emits a warning.
diff --git a/docs/source/user/py/references/Compartment.rst b/docs/source/user/py/references/Compartment.rst
new file mode 100644
index 0000000000..6c47c80ceb
--- /dev/null
+++ b/docs/source/user/py/references/Compartment.rst
@@ -0,0 +1,6 @@
+Compartment
+-----------
+
+.. py:class:: Compartment
+
+ Compartment object, for branching neuron models.
diff --git a/docs/source/user/py/references/CompartmentBase.rst b/docs/source/user/py/references/CompartmentBase.rst
new file mode 100644
index 0000000000..2cdc6a3160
--- /dev/null
+++ b/docs/source/user/py/references/CompartmentBase.rst
@@ -0,0 +1,345 @@
+CompartmentBase
+---------------
+
+.. py:class:: CompartmentBase
+
+ CompartmentBase object, for branching neuron models.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process messages from the scheduler objects. The Process should be called \_second\_ in each clock tick, after the Init message.The first entry in the shared msg is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:attribute:: init
+
+ void (*shared message field*) This is a shared message to receive Init messages from the scheduler objects. Its job is to separate the compartmental calculations from the message passing. It doesn't really need to be shared, as it does not use the reinit part, but the scheduler objects expect this form of message for all scheduled output. The first entry is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a dummy MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:attribute:: channel
+
+ void (*shared message field*) This is a shared message from a compartment to channels. The first entry is a MsgDest for the info coming from the channel. It expects Gk and Ek from the channel as args. The second entry is a MsgSrc sending Vm
+
+
+ .. py:attribute:: axial
+
+ void (*shared message field*) This is a shared message between asymmetric compartments. axial messages (this kind) connect up to raxial messages (defined below). The soma should use raxial messages to connect to the axial message of all the immediately adjacent dendritic compartments.This puts the (low) somatic resistance in series with these dendrites. Dendrites should then use raxial messages toconnect on to more distal dendrites. In other words, raxial messages should face outward from the soma. The first entry is a MsgSrc sending Vm to the axialFuncof the target compartment. The second entry is a MsgDest for the info coming from the other compt. It expects Ra and Vm from the other compt as args. Note that the message is named after the source type.
+
+
+ .. py:attribute:: raxial
+
+ void (*shared message field*) This is a raxial shared message between asymmetric compartments. The first entry is a MsgDest for the info coming from the other compt. It expects Vm from the other compt as an arg. The second is a MsgSrc sending Ra and Vm to the raxialFunc of the target compartment.
+
+
+ .. py:method:: setVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setEm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getEm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getIm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInject
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInject
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInitVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInitVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRa
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRa
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiameter
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiameter
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLength
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLength
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: injectMsg
+
+ (*destination message field*) The injectMsg corresponds to the INJECT message in the GENESIS compartment. Unlike the 'inject' field, any value assigned by handleInject applies only for a single timestep.So it needs to be updated every dt for a steady (or varying)injection current
+
+
+ .. py:method:: randInject
+
+ (*destination message field*) Sends a random injection current to the compartment. Must beupdated each timestep.Arguments to randInject are probability and current.
+
+
+ .. py:method:: injectMsg
+
+ (*destination message field*) The injectMsg corresponds to the INJECT message in the GENESIS compartment. Unlike the 'inject' field, any value assigned by handleInject applies only for a single timestep.So it needs to be updated every dt for a steady (or varying)injection current
+
+
+ .. py:method:: cable
+
+ (*destination message field*) Message for organizing compartments into groups, calledcables. Doesn't do anything.
+
+
+ .. py:method:: displace
+
+ (*destination message field*) Displaces compartment by specified vector
+
+
+ .. py:method:: setGeomAndElec
+
+ (*destination message field*) Assigns length and dia and accounts for any electrical scaling needed as a result.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles 'process' call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles 'reinit' call
+
+
+ .. py:method:: initProc
+
+ (*destination message field*) Handles Process call for the 'init' phase of the CompartmentBase calculations. These occur as a separate Tick cycle from the regular proc cycle, and should be called before the proc msg.
+
+
+ .. py:method:: initReinit
+
+ (*destination message field*) Handles Reinit call for the 'init' phase of the CompartmentBase calculations.
+
+
+ .. py:method:: handleChannel
+
+ (*destination message field*) Handles conductance and Reversal potential arguments from Channel
+
+
+ .. py:method:: handleRaxial
+
+ (*destination message field*) Handles Raxial info: arguments are Ra and Vm.
+
+
+ .. py:method:: handleAxial
+
+ (*destination message field*) Handles Axial information. Argument is just Vm.
+
+
+ .. py:attribute:: VmOut
+
+ double (*source message field*) Sends out Vm value of compartment on each timestep
+
+
+ .. py:attribute:: axialOut
+
+ double (*source message field*) Sends out Vm value of compartment to adjacent compartments,on each timestep
+
+
+ .. py:attribute:: raxialOut
+
+ double,double (*source message field*) Sends out Raxial information on each timestep, fields are Ra and Vm
+
+
+ .. py:attribute:: Vm
+
+ double (*value field*) membrane potential
+
+
+ .. py:attribute:: Cm
+
+ double (*value field*) Membrane capacitance
+
+
+ .. py:attribute:: Em
+
+ double (*value field*) Resting membrane potential
+
+
+ .. py:attribute:: Im
+
+ double (*value field*) Current going through membrane
+
+
+ .. py:attribute:: inject
+
+ double (*value field*) Current injection to deliver into compartment
+
+
+ .. py:attribute:: initVm
+
+ double (*value field*) Initial value for membrane potential
+
+
+ .. py:attribute:: Rm
+
+ double (*value field*) Membrane resistance
+
+
+ .. py:attribute:: Ra
+
+ double (*value field*) Axial resistance of compartment
+
+
+ .. py:attribute:: diameter
+
+ double (*value field*) Diameter of compartment
+
+
+ .. py:attribute:: length
+
+ double (*value field*) Length of compartment
+
+
+ .. py:attribute:: x0
+
+ double (*value field*) X coordinate of start of compartment
+
+
+ .. py:attribute:: y0
+
+ double (*value field*) Y coordinate of start of compartment
+
+
+ .. py:attribute:: z0
+
+ double (*value field*) Z coordinate of start of compartment
+
+
+ .. py:attribute:: x
+
+ double (*value field*) x coordinate of end of compartment
+
+
+ .. py:attribute:: y
+
+ double (*value field*) y coordinate of end of compartment
+
+
+ .. py:attribute:: z
+
+ double (*value field*) z coordinate of end of compartment
diff --git a/docs/source/user/py/references/CplxEnzBase.rst b/docs/source/user/py/references/CplxEnzBase.rst
new file mode 100644
index 0000000000..d7b726e73c
--- /dev/null
+++ b/docs/source/user/py/references/CplxEnzBase.rst
@@ -0,0 +1,110 @@
+CplxEnzBase
+-----------
+
+.. py:class:: CplxEnzBase
+
+ : Base class for mass-action enzymes in which there is an explicit pool for the enzyme-substrate complex. It models the reaction: E + S <===> E.S ----> E + P
+
+ .. py:attribute:: enz
+
+ void (*shared message field*) Connects to enzyme pool
+
+
+ .. py:attribute:: cplx
+
+ void (*shared message field*) Connects to enz-sub complex pool
+
+
+ .. py:method:: setK1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getK1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setK2
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getK2
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setK3
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getK3
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRatio
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRatio
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setConcK1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getConcK1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: enzDest
+
+ (*destination message field*) Handles # of molecules of Enzyme
+
+
+ .. py:method:: cplxDest
+
+ (*destination message field*) Handles # of molecules of enz-sub complex
+
+
+ .. py:attribute:: enzOut
+
+ double,double (*source message field*) Sends out increment of molecules on product each timestep
+
+
+ .. py:attribute:: cplxOut
+
+ double,double (*source message field*) Sends out increment of molecules on product each timestep
+
+
+ .. py:attribute:: k1
+
+ double (*value field*) Forward reaction from enz + sub to complex, in # units.This parameter is subordinate to the Km. This means thatwhen Km is changed, this changes. It also means that whenk2 or k3 (aka kcat) are changed, we assume that Km remainsfixed, and as a result k1 must change. It is only whenk1 is assigned directly that we assume that the user knowswhat they are doing, and we adjust Km accordingly.k1 is also subordinate to the 'ratio' field, since setting the ratio reassigns k2.Should you wish to assign the elementary rates k1, k2, k3,of an enzyme directly, always assign k1 last.
+
+
+ .. py:attribute:: k2
+
+ double (*value field*) Reverse reaction from complex to enz + sub
+
+
+ .. py:attribute:: k3
+
+ double (*value field*) Forward rate constant from complex to product + enz
+
+
+ .. py:attribute:: ratio
+
+ double (*value field*) Ratio of k2/k3
+
+
+ .. py:attribute:: concK1
+
+ double (*value field*) K1 expressed in concentration (1/millimolar.sec) unitsThis parameter is subordinate to the Km. This means thatwhen Km is changed, this changes. It also means that whenk2 or k3 (aka kcat) are changed, we assume that Km remainsfixed, and as a result concK1 must change. It is only whenconcK1 is assigned directly that we assume that the user knowswhat they are doing, and we adjust Km accordingly.concK1 is also subordinate to the 'ratio' field, sincesetting the ratio reassigns k2.Should you wish to assign the elementary rates concK1, k2, k3,of an enzyme directly, always assign concK1 last.
diff --git a/docs/source/user/py/references/CubeMesh.rst b/docs/source/user/py/references/CubeMesh.rst
new file mode 100644
index 0000000000..5a69920694
--- /dev/null
+++ b/docs/source/user/py/references/CubeMesh.rst
@@ -0,0 +1,289 @@
+CubeMesh
+--------
+
+.. py:class:: CubeMesh
+
+
+ .. py:method:: setIsToroid
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getIsToroid
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setPreserveNumEntries
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getPreserveNumEntries
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAlwaysDiffuse
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlwaysDiffuse
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDx
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDx
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDz
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDz
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNx
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNx
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNz
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNz
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCoords
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCoords
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMeshToSpace
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMeshToSpace
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setSpaceToMesh
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getSpaceToMesh
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setSurface
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getSurface
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: isToroid
+
+ bool (*value field*) Flag. True when the mesh should be toroidal, that is,when going beyond the right face brings us around to theleft-most mesh entry, and so on. If we have nx, ny, nzentries, this rule means that the coordinate (x, ny, z)will map onto (x, 0, z). Similarly,(-1, y, z) -> (nx-1, y, z)Default is false
+
+
+ .. py:attribute:: preserveNumEntries
+
+ bool (*value field*) Flag. When it is true, the numbers nx, ny, nz remainunchanged when x0, x1, y0, y1, z0, z1 are altered. Thusdx, dy, dz would change instead. When it is false, thendx, dy, dz remain the same and nx, ny, nz are altered.Default is true
+
+
+ .. py:attribute:: alwaysDiffuse
+
+ bool (*value field*) Flag. When it is true, the mesh matches up sequential mesh entries for diffusion and chmestry. This is regardless of spatial location, and is guaranteed to set up at least the home reaction systemDefault is false
+
+
+ .. py:attribute:: x0
+
+ double (*value field*) X coord of one end
+
+
+ .. py:attribute:: y0
+
+ double (*value field*) Y coord of one end
+
+
+ .. py:attribute:: z0
+
+ double (*value field*) Z coord of one end
+
+
+ .. py:attribute:: x1
+
+ double (*value field*) X coord of other end
+
+
+ .. py:attribute:: y1
+
+ double (*value field*) Y coord of other end
+
+
+ .. py:attribute:: z1
+
+ double (*value field*) Z coord of other end
+
+
+ .. py:attribute:: dx
+
+ double (*value field*) X size for mesh
+
+
+ .. py:attribute:: dy
+
+ double (*value field*) Y size for mesh
+
+
+ .. py:attribute:: dz
+
+ double (*value field*) Z size for mesh
+
+
+ .. py:attribute:: nx
+
+ unsigned int (*value field*) Number of subdivisions in mesh in X
+
+
+ .. py:attribute:: ny
+
+ unsigned int (*value field*) Number of subdivisions in mesh in Y
+
+
+ .. py:attribute:: nz
+
+ unsigned int (*value field*) Number of subdivisions in mesh in Z
+
+
+ .. py:attribute:: coords
+
+ vector (*value field*) Set all the coords of the cuboid at once. Order is:x0 y0 z0 x1 y1 z1 dx dy dzWhen this is done, it recalculates the numEntries since dx, dy and dz are given explicitly.As a special hack, you can leave out dx, dy and dz and use a vector of size 6. In this case the operation assumes that nx, ny and nz are to be preserved and dx, dy and dz will be recalculated.
+
+
+ .. py:attribute:: meshToSpace
+
+ vector (*value field*) Array in which each mesh entry stores spatial (cubic) index
+
+
+ .. py:attribute:: spaceToMesh
+
+ vector (*value field*) Array in which each space index (obtained by linearizing the xyz coords) specifies which meshIndex is present.In many cases the index will store the EMPTY flag if there isno mesh entry at that spatial location
+
+
+ .. py:attribute:: surface
+
+ vector (*value field*) Array specifying surface of arbitrary volume within the CubeMesh. All entries must fall within the cuboid. Each entry of the array is a spatial index obtained by linearizing the ix, iy, iz coordinates within the cuboid. So, each entry == ( iz * ny + iy ) * nx + ixNote that the voxels listed on the surface are WITHIN the volume of the CubeMesh object
diff --git a/docs/source/user/py/references/CylMesh.rst b/docs/source/user/py/references/CylMesh.rst
new file mode 100644
index 0000000000..7c36fb4fa6
--- /dev/null
+++ b/docs/source/user/py/references/CylMesh.rst
@@ -0,0 +1,174 @@
+CylMesh
+-------
+
+.. py:class:: CylMesh
+
+
+ .. py:method:: setX0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setR0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getR0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setR1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getR1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiffLength
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiffLength
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCoords
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCoords
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumDiffCompts
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getTotLength
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: x0
+
+ double (*value field*) x coord of one end
+
+
+ .. py:attribute:: y0
+
+ double (*value field*) y coord of one end
+
+
+ .. py:attribute:: z0
+
+ double (*value field*) z coord of one end
+
+
+ .. py:attribute:: r0
+
+ double (*value field*) Radius of one end
+
+
+ .. py:attribute:: x1
+
+ double (*value field*) x coord of other end
+
+
+ .. py:attribute:: y1
+
+ double (*value field*) y coord of other end
+
+
+ .. py:attribute:: z1
+
+ double (*value field*) z coord of other end
+
+
+ .. py:attribute:: r1
+
+ double (*value field*) Radius of other end
+
+
+ .. py:attribute:: diffLength
+
+ double (*value field*) Length constant to use for subdivisionsThe system will attempt to subdivide using compartments oflength diffLength on average. If the cylinder has different enddiameters r0 and r1, it will scale to smaller lengthsfor the smaller diameter end and vice versa.Once the value is set it will recompute diffLength as totLength/numEntries
+
+
+ .. py:attribute:: coords
+
+ vector (*value field*) All the coords as a single vector: x0 y0 z0 x1 y1 z1 r0 r1 diffLength
+
+
+ .. py:attribute:: numDiffCompts
+
+ unsigned int (*value field*) Number of diffusive compartments in model
+
+
+ .. py:attribute:: totLength
+
+ double (*value field*) Total length of cylinder
diff --git a/docs/source/user/py/references/DiagonalMsg.rst b/docs/source/user/py/references/DiagonalMsg.rst
new file mode 100644
index 0000000000..5472801a86
--- /dev/null
+++ b/docs/source/user/py/references/DiagonalMsg.rst
@@ -0,0 +1,19 @@
+DiagonalMsg
+-----------
+
+.. py:class:: DiagonalMsg
+
+
+ .. py:method:: setStride
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getStride
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: stride
+
+ int (*value field*) The stride is the increment to the src DataId that gives thedest DataId. It can be positive or negative, but bounds checkingtakes place and it does not wrap around.
diff --git a/docs/source/user/py/references/DifShell.rst b/docs/source/user/py/references/DifShell.rst
new file mode 100644
index 0000000000..d169a8bf95
--- /dev/null
+++ b/docs/source/user/py/references/DifShell.rst
@@ -0,0 +1,313 @@
+DifShell
+--------
+
+.. py:class:: DifShell
+
+ DifShell object: Models diffusion of an ion (typically calcium) within an electric compartment. A DifShell is an iso-concentration region with respect to the ion. Adjoining DifShells exchange flux of this ion, and also keep track of changes in concentration due to pumping, buffering and channel currents, by talking to the appropriate objects.
+
+ .. py:attribute:: process\_0
+
+ void (*shared message field*) Here we create 2 shared finfos to attach with the Ticks. This is because we want to perform DifShell computations in 2 stages, much as in the Compartment object. In the first stage we send out the concentration value to other DifShells and Buffer elements. We also receive fluxes and currents and sum them up to compute ( dC / dt ). In the second stage we find the new C value using an explicit integration method. This 2-stage procedure eliminates the need to store and send prev\_C values, as was common in GENESIS.
+
+
+ .. py:attribute:: process\_1
+
+ void (*shared message field*) Second process call
+
+
+ .. py:attribute:: buffer
+
+ void (*shared message field*) This is a shared message from a DifShell to a Buffer (FixBuffer or DifBuffer). During stage 0:
+ - DifShell sends ion concentration
+ - Buffer updates buffer concentration and sends it back immediately using a call-back.
+ - DifShell updates the time-derivative ( dC / dt )
+
+ During stage 1:
+ - DifShell advances concentration C
+
+ This scheme means that the Buffer does not need to be scheduled, and it does its computations when it receives a cue from the DifShell. May not be the best idea, but it saves us from doing the above computations in 3 stages instead of 2.
+
+
+ .. py:attribute:: innerDif
+
+ void (*shared message field*) This shared message (and the next) is between DifShells: adjoining shells exchange information to find out the flux between them. Using this message, an inner shell sends to, and receives from its outer shell.
+
+
+ .. py:attribute:: outerDif
+
+ void (*shared message field*) Using this message, an outer shell sends to, and receives from its inner shell.
+
+
+ .. py:method:: getC
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCeq
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCeq
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setValence
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getValence
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLeak
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLeak
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setShapeMode
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getShapeMode
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLength
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLength
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiameter
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiameter
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThickness
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThickness
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVolume
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVolume
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setOuterArea
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getOuterArea
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInnerArea
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInnerArea
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Reinit happens only in stage 0
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handle process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Reinit happens only in stage 0
+
+
+ .. py:method:: reaction
+
+ (*destination message field*) Here the DifShell receives reaction rates (forward and backward), and concentrations for the free-buffer and bound-buffer molecules.
+
+
+ .. py:method:: fluxFromOut
+
+ (*destination message field*) Destination message
+
+
+ .. py:method:: fluxFromIn
+
+ (*destination message field*)
+
+
+ .. py:method:: influx
+
+ (*destination message field*)
+
+
+ .. py:method:: outflux
+
+ (*destination message field*)
+
+
+ .. py:method:: fInflux
+
+ (*destination message field*)
+
+
+ .. py:method:: fOutflux
+
+ (*destination message field*)
+
+
+ .. py:method:: storeInflux
+
+ (*destination message field*)
+
+
+ .. py:method:: storeOutflux
+
+ (*destination message field*)
+
+
+ .. py:method:: tauPump
+
+ (*destination message field*)
+
+
+ .. py:method:: eqTauPump
+
+ (*destination message field*)
+
+
+ .. py:method:: mmPump
+
+ (*destination message field*)
+
+
+ .. py:method:: hillPump
+
+ (*destination message field*)
+
+
+ .. py:attribute:: concentrationOut
+
+ double (*source message field*) Sends out concentration
+
+
+ .. py:attribute:: innerDifSourceOut
+
+ double,double (*source message field*) Sends out source information.
+
+
+ .. py:attribute:: outerDifSourceOut
+
+ double,double (*source message field*) Sends out source information.
+
+
+ .. py:attribute:: C
+
+ double (*value field*) Concentration C is computed by the DifShell and is read-only
+
+
+ .. py:attribute:: Ceq
+
+ double (*value field*)
+
+
+ .. py:attribute:: D
+
+ double (*value field*)
+
+
+ .. py:attribute:: valence
+
+ double (*value field*)
+
+
+ .. py:attribute:: leak
+
+ double (*value field*)
+
+
+ .. py:attribute:: shapeMode
+
+ unsigned int (*value field*)
+
+
+ .. py:attribute:: length
+
+ double (*value field*)
+
+
+ .. py:attribute:: diameter
+
+ double (*value field*)
+
+
+ .. py:attribute:: thickness
+
+ double (*value field*)
+
+
+ .. py:attribute:: volume
+
+ double (*value field*)
+
+
+ .. py:attribute:: outerArea
+
+ double (*value field*)
+
+
+ .. py:attribute:: innerArea
+
+ double (*value field*)
diff --git a/docs/source/user/py/references/DiffAmp.rst b/docs/source/user/py/references/DiffAmp.rst
new file mode 100644
index 0000000000..b8d53ca0ab
--- /dev/null
+++ b/docs/source/user/py/references/DiffAmp.rst
@@ -0,0 +1,80 @@
+DiffAmp
+-------
+
+.. py:class:: DiffAmp
+
+ A difference amplifier. Output is the difference between the total plus inputs and the total minus inputs multiplied by gain. Gain can be set statically as a field or can be a destination message and thus dynamically determined by the output of another object. Same as GENESIS diffamp object.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process messages from the scheduler objects.The first entry in the shared msg is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: setGain
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGain
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setSaturation
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getSaturation
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getOutputValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: gainIn
+
+ (*destination message field*) Destination message to control gain dynamically.
+
+
+ .. py:method:: plusIn
+
+ (*destination message field*) Positive input terminal of the amplifier. All the messages connected here are summed up to get total positive input.
+
+
+ .. py:method:: minusIn
+
+ (*destination message field*) Negative input terminal of the amplifier. All the messages connected here are summed up to get total positive input.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call, updates internal time stamp.
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call.
+
+
+ .. py:attribute:: output
+
+ double (*source message field*) Current output level.
+
+
+ .. py:attribute:: gain
+
+ double (*value field*) Gain of the amplifier. The output of the amplifier is the difference between the totals in plus and minus inputs multiplied by the gain. Defaults to 1
+
+
+ .. py:attribute:: saturation
+
+ double (*value field*) Saturation is the bound on the output. If output goes beyond the +/-saturation range, it is truncated to the closer of +saturation and -saturation. Defaults to the maximum double precision floating point number representable on the system.
+
+
+ .. py:attribute:: outputValue
+
+ double (*value field*) Output of the amplifier, i.e. gain * (plus - minus).
diff --git a/docs/source/user/py/references/Dsolve.rst b/docs/source/user/py/references/Dsolve.rst
new file mode 100644
index 0000000000..ad421e30a7
--- /dev/null
+++ b/docs/source/user/py/references/Dsolve.rst
@@ -0,0 +1,169 @@
+Dsolve
+------
+
+.. py:class:: Dsolve
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: setStoich
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getStoich
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setPath
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getPath
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCompartment
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCompartment
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumAllVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNVec
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNVec
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumPools
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumPools
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiffVol1
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiffVol1
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiffVol2
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiffVol2
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDiffScale
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDiffScale
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: buildMeshJunctions
+
+ (*destination message field*) Builds junctions between mesh on current Dsolve, and another Dsolve. The meshes have to be compatible.
+
+
+ .. py:method:: buildNeuroMeshJunctions
+
+ (*destination message field*) Builds junctions between NeuroMesh, SpineMesh and PsdMesh
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:attribute:: stoich
+
+ Id (*value field*) Stoichiometry object for handling this reaction system.
+
+
+ .. py:attribute:: path
+
+ string (*value field*) Path of reaction system. Must include all the pools that are to be handled by the Dsolve, can also include other random objects, which will be ignored.
+
+
+ .. py:attribute:: compartment
+
+ Id (*value field*) Reac-diff compartment in which this diffusion system is embedded.
+
+
+ .. py:attribute:: numVoxels
+
+ unsigned int (*value field*) Number of voxels in the core reac-diff system, on the current diffusion solver.
+
+
+ .. py:attribute:: numAllVoxels
+
+ unsigned int (*value field*) Number of voxels in the core reac-diff system, on the current diffusion solver.
+
+
+ .. py:attribute:: numPools
+
+ unsigned int (*value field*) Number of molecular pools in the entire reac-diff system, including variable, function and buffered.
+
+
+ .. py:attribute:: nVec
+
+ unsigned int,vector (*lookup field*) vector of # of molecules along diffusion length, looked up by pool index
+
+
+ .. py:attribute:: diffVol1
+
+ unsigned int,double (*lookup field*) Volume used to set diffusion scaling: firstVol[ voxel# ] Particularly relevant for diffusion between PSD and head.
+
+
+ .. py:attribute:: diffVol2
+
+ unsigned int,double (*lookup field*) Volume used to set diffusion scaling: secondVol[ voxel# ] Particularly relevant for diffusion between spine and dend.
+
+
+ .. py:attribute:: diffScale
+
+ unsigned int,double (*lookup field*) Geometry term to set diffusion scaling: diffScale[ voxel# ] Here the scaling term is given by cross-section area/length Relevant for diffusion between spine head and dend, or PSD.
diff --git a/docs/source/user/py/references/Enz.rst b/docs/source/user/py/references/Enz.rst
new file mode 100644
index 0000000000..a1a2a8ec7a
--- /dev/null
+++ b/docs/source/user/py/references/Enz.rst
@@ -0,0 +1,9 @@
+Enz
+---
+
+.. py:class:: Enz
+
+
+ .. py:method:: setKmK1
+
+ (*destination message field*) Low-level function used when you wish to explicitly set Km and k1, without doing any of the volume calculations.Needed by ReadKkit and other situations where the numbers must be set before all the messaging is in place.Not relevant for zombie enzymes.
diff --git a/docs/source/user/py/references/EnzBase.rst b/docs/source/user/py/references/EnzBase.rst
new file mode 100644
index 0000000000..8b87b153f2
--- /dev/null
+++ b/docs/source/user/py/references/EnzBase.rst
@@ -0,0 +1,115 @@
+EnzBase
+-------
+
+.. py:class:: EnzBase
+
+ Abstract base class for enzymes.
+
+ .. py:attribute:: sub
+
+ void (*shared message field*) Connects to substrate molecule
+
+
+ .. py:attribute:: prd
+
+ void (*shared message field*) Connects to product molecule
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: setKm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getKm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumKm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumKm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setKcat
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getKcat
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumSubstrates
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: enzDest
+
+ (*destination message field*) Handles # of molecules of Enzyme
+
+
+ .. py:method:: subDest
+
+ (*destination message field*) Handles # of molecules of substrate
+
+
+ .. py:method:: prdDest
+
+ (*destination message field*) Handles # of molecules of product. Dummy.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: remesh
+
+ (*destination message field*) Tells the MMEnz to recompute its numKm after remeshing
+
+
+ .. py:attribute:: subOut
+
+ double,double (*source message field*) Sends out increment of molecules on product each timestep
+
+
+ .. py:attribute:: prdOut
+
+ double,double (*source message field*) Sends out increment of molecules on product each timestep
+
+
+ .. py:attribute:: Km
+
+ double (*value field*) Michaelis-Menten constant in SI conc units (milliMolar)
+
+
+ .. py:attribute:: numKm
+
+ double (*value field*) Michaelis-Menten constant in number units, volume dependent
+
+
+ .. py:attribute:: kcat
+
+ double (*value field*) Forward rate constant for enzyme, units 1/sec
+
+
+ .. py:attribute:: numSubstrates
+
+ unsigned int (*value field*) Number of substrates in this MM reaction. Usually 1.Does not include the enzyme itself
diff --git a/docs/source/user/py/references/ExIF.rst b/docs/source/user/py/references/ExIF.rst
new file mode 100644
index 0000000000..ce044cb1c5
--- /dev/null
+++ b/docs/source/user/py/references/ExIF.rst
@@ -0,0 +1,35 @@
+ExIF
+----
+
+.. py:class:: ExIF
+
+ Leaky Integrate-and-Fire neuron with Exponential spike rise.Rm*Cm dVm/dt = -(Vm-Em) + deltaThresh * exp((Vm-thresh)/deltaThresh) + Rm*I
+
+ .. py:method:: setDeltaThresh
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDeltaThresh
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVPeak
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVPeak
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: deltaThresh
+
+ double (*value field*) Parameter in Vm evolution equation:Rm*Cm * dVm/dt = -(Vm-Em) + deltaThresh * exp((Vm-thresh)/deltaThresh) + Rm*I
+
+
+ .. py:attribute:: vPeak
+
+ double (*value field*) Vm is reset on reaching vPeak, different from spike thresh below:Rm*Cm dVm/dt = -(Vm-Em) + deltaThresh * exp((Vm-thresh)/deltaThresh) + Rm*I
diff --git a/docs/source/user/py/references/ExponentialRng.rst b/docs/source/user/py/references/ExponentialRng.rst
new file mode 100644
index 0000000000..2a1fb01d17
--- /dev/null
+++ b/docs/source/user/py/references/ExponentialRng.rst
@@ -0,0 +1,36 @@
+ExponentialRng
+--------------
+
+.. py:class:: ExponentialRng
+
+ Exponentially distributed random number generator.
+ Exponential distribution with mean k is defined by the probability density function p(x; k) = k * exp(-k * x) if x >= 0, else 0. By default this class uses the random minimization method described in Knuth's TAOCP Vol II Sec 3.4.1 (Algorithm S).
+
+ .. py:method:: setMean
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMean
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMethod
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMethod
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: mean
+
+ double (*value field*) Mean of the exponential distribution.
+
+
+ .. py:attribute:: method
+
+ int (*value field*) The algorithm to use for computing the sample. Two methods are supported: 0 - logarithmic and 1 - random minimization. The logarithmic method is slower (it computes a logarithm). Default is random minimization. See Knuth, Vol II Sec 3.4.1 : Algorithm S.
diff --git a/docs/source/user/py/references/Finfo.rst b/docs/source/user/py/references/Finfo.rst
new file mode 100644
index 0000000000..7e189a4367
--- /dev/null
+++ b/docs/source/user/py/references/Finfo.rst
@@ -0,0 +1,54 @@
+Finfo
+-----
+
+.. py:class:: Finfo
+
+
+ .. py:method:: getFieldName
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDocs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getType
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getSrc
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDest
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: fieldName
+
+ string (*value field*) Name of field handled by Finfo
+
+
+ .. py:attribute:: docs
+
+ string (*value field*) Documentation for Finfo
+
+
+ .. py:attribute:: type
+
+ string (*value field*) RTTI type info for this Finfo
+
+
+ .. py:attribute:: src
+
+ vector (*value field*) Subsidiary SrcFinfos. Useful for SharedFinfos
+
+
+ .. py:attribute:: dest
+
+ vector (*value field*) Subsidiary DestFinfos. Useful for SharedFinfos
diff --git a/docs/source/user/py/references/Func.rst b/docs/source/user/py/references/Func.rst
new file mode 100644
index 0000000000..bef667af78
--- /dev/null
+++ b/docs/source/user/py/references/Func.rst
@@ -0,0 +1,265 @@
+Func
+----
+
+.. py:class:: Func
+
+ Func: general purpose function calculator using real numbers. It can
+ parse mathematical expression defining a function and evaluate it
+ and/or its derivative for specified variable values.
+ The variables can be input from other moose objects. In case of
+ arbitrary variable names, the source message must have the variable
+ name as the first argument. For most common cases, input messages to
+ set x, y, z and xy, xyz are made available without such
+ requirement. This class handles only real numbers
+ (C-double). Predefined constants are: pi=3.141592...,
+ e=2.718281...
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process messages from the scheduler objects.The first entry in the shared msg is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: getValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDerivative
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMode
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMode
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setExpr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getExpr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVar
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVar
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getVars
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: varIn
+
+ (*destination message field*) Handle value for specified variable coming from other objects
+
+
+ .. py:method:: xIn
+
+ (*destination message field*) Handle value for variable named x. This is a shorthand. If the
+ expression does not have any variable named x, this the first variable
+ in the sequence `vars`.
+
+
+ .. py:method:: yIn
+
+ (*destination message field*) Handle value for variable named y. This is a utility for two/three
+ variable functions where the y value comes from a source separate
+ from that of x. This is a shorthand. If the
+ expression does not have any variable named y, this the second
+ variable in the sequence `vars`.
+
+
+ .. py:method:: zIn
+
+ (*destination message field*) Handle value for variable named z. This is a utility for three
+ variable functions where the z value comes from a source separate
+ from that of x or y. This is a shorthand. If the expression does not
+ have any variable named y, this the second variable in the sequence `vars`.
+
+
+ .. py:method:: xyIn
+
+ (*destination message field*) Handle value for variables x and y for two-variable function
+
+
+ .. py:method:: xyzIn
+
+ (*destination message field*) Handle value for variables x, y and z for three-variable function
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call, updates internal time stamp.
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call.
+
+
+ .. py:attribute:: valueOut
+
+ double (*source message field*) Evaluated value of the function for the current variable values.
+
+
+ .. py:attribute:: derivativeOut
+
+ double (*source message field*) Value of derivative of the function for the current variable values
+
+
+ .. py:attribute:: value
+
+ double (*value field*) Result of the function evaluation with current variable values.
+
+
+ .. py:attribute:: derivative
+
+ double (*value field*) Derivative of the function at given variable values.
+
+
+ .. py:attribute:: mode
+
+ unsigned int (*value field*) Mode of operation:
+ 1: only the function value will be calculated
+ 2: only the derivative will be calculated
+ 3: both function value and derivative at current variable values will be calculated.
+
+
+ .. py:attribute:: expr
+
+ string (*value field*) Mathematical expression defining the function. The underlying parser
+ is muParser. In addition to the available functions and operators from
+ muParser, some more functions are added.
+
+ Functions
+ Name args explanation
+ sin 1 sine function
+ cos 1 cosine function
+ tan 1 tangens function
+ asin 1 arcus sine function
+ acos 1 arcus cosine function
+ atan 1 arcus tangens function
+ sinh 1 hyperbolic sine function
+ cosh 1 hyperbolic cosine
+ tanh 1 hyperbolic tangens function
+ asinh 1 hyperbolic arcus sine function
+ acosh 1 hyperbolic arcus tangens function
+ atanh 1 hyperbolic arcur tangens function
+ log2 1 logarithm to the base 2
+ log10 1 logarithm to the base 10
+ log 1 logarithm to the base 10
+ ln 1 logarithm to base e (2.71828...)
+ exp 1 e raised to the power of x
+ sqrt 1 square root of a value
+ sign 1 sign function -1 if x<0; 1 if x>0
+ rint 1 round to nearest integer
+ abs 1 absolute value
+ min var. min of all arguments
+ max var. max of all arguments
+ sum var. sum of all arguments
+ avg var. mean value of all arguments
+ rand 1 rand(seed), random float between 0 and 1,
+ if seed = -1, then a 'random' seed is created.
+ rand2 3 rand(a, b, seed), random float between a and b,
+ if seed = -1, a 'random' seed is created using either
+ by random\_device or by reading system clock
+
+ Operators
+ Op meaning prioroty
+ = assignement -1
+ && logical and 1
+ || logical or 2
+ <= less or equal 4
+ >= greater or equal 4
+ != not equal 4
+ == equal 4
+ > greater than 4
+ < less than 4
+ + addition 5
+ - subtraction 5
+ * multiplication 6
+ / division 6
+ ^ raise x to the power of y 7
+
+ ?: if then else operator C++ style syntax
+
+
+
+ .. py:attribute:: vars
+
+ vector (*value field*) Variable names in the expression
+
+
+ .. py:attribute:: x
+
+ double (*value field*) Value for variable named x. This is a shorthand. If the
+ expression does not have any variable named x, this the first variable
+ in the sequence `vars`.
+
+
+ .. py:attribute:: y
+
+ double (*value field*) Value for variable named y. This is a utility for two/three
+ variable functions where the y value comes from a source separate
+ from that of x. This is a shorthand. If the
+ expression does not have any variable named y, this the second
+ variable in the sequence `vars`.
+
+
+ .. py:attribute:: z
+
+ double (*value field*) Value for variable named z. This is a utility for three
+ variable functions where the z value comes from a source separate
+ from that of x or z. This is a shorthand. If the expression does not
+ have any variable named z, this the third variable in the sequence `vars`.
+
+
+ .. py:attribute:: var
+
+ string,double (*lookup field*) Lookup table for variable values.
diff --git a/docs/source/user/py/references/Function.rst b/docs/source/user/py/references/Function.rst
new file mode 100644
index 0000000000..46e4728290
--- /dev/null
+++ b/docs/source/user/py/references/Function.rst
@@ -0,0 +1,256 @@
+Function
+--------
+
+.. py:class:: Function
+
+ General purpose function calculator using real numbers.
+ It can parse mathematical expression defining a function and evaluate it and/or its derivative for specified variable values.You can assign expressions of the form::
+ f(c0, c1, ..., cM, x0, x1, ..., xN, y0,..., yP )
+ where `ci`'s are constants and `xi`'s and `yi`'s are variables.The constants must be defined before setting the expression and variables are connected via messages. The constants can have any name, but the variable names must be of the form x{i} or y{i} where i is increasing integer starting from 0.
+ The variables can be input from other moose objects. Such variables must be named `x{i}` in the expression and the source field is connected to Function.x[i]'s `input` destination field.
+ In case the input variable is not available as a source field, but is a value field, then the value can be requested by connecting the `requestOut` message to the `get{Field}` destination on the target object. Such variables must be specified in the expression as y{i} and connecting the messages should happen in the same order as the y indices.
+ This class handles only real numbers (C-double). Predefined constants are: pi=3.141592..., e=2.718281...
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process messages from the scheduler objects.The first entry in the shared msg is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: getValue
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getRate
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getDerivative
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMode
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMode
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setExpr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getExpr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumVars
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumVars
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumX
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumX
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setC
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getC
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setIndependent
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getIndependent
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call, updates internal time stamp.
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call.
+
+
+ .. py:attribute:: requestOut
+
+ PSt6vectorIdSaIdEE (*source message field*) Sends request for input variable from a field on target object
+
+
+ .. py:attribute:: valueOut
+
+ double (*source message field*) Evaluated value of the function for the current variable values.
+
+
+ .. py:attribute:: rateOut
+
+ double (*source message field*) Value of time-derivative of the function for the current variable values
+
+
+ .. py:attribute:: derivativeOut
+
+ double (*source message field*) Value of derivative of the function for the current variable values
+
+
+ .. py:attribute:: value
+
+ double (*value field*) Result of the function evaluation with current variable values.
+
+
+ .. py:attribute:: rate
+
+ double (*value field*) Derivative of the function at given variable values. This is computed as the difference of the current and previous value of the function divided by the time step.
+
+
+ .. py:attribute:: derivative
+
+ double (*value field*) Derivative of the function at given variable values. This is calulated using 5-point stencil at current value of independent variable. Note that unlike hand-calculated derivatives, numerical derivatives are not exact.
+
+
+ .. py:attribute:: mode
+
+ unsigned int (*value field*) Mode of operation:
+ 1: only the function value will be sent out.
+ 2: only the derivative with respect to the independent variable will be sent out.
+ 3: only rate (time derivative) will be sent out.
+ anything else: all three, value, derivative and rate will be sent out.
+
+
+
+ .. py:attribute:: expr
+
+ string (*value field*) Mathematical expression defining the function. The underlying parser
+ is muParser. In addition to the available functions and operators from
+ muParser, some more functions are added.
+
+ Functions
+ Name args explanation
+ sin 1 sine function
+ cos 1 cosine function
+ tan 1 tangens function
+ asin 1 arcus sine function
+ acos 1 arcus cosine function
+ atan 1 arcus tangens function
+ sinh 1 hyperbolic sine function
+ cosh 1 hyperbolic cosine
+ tanh 1 hyperbolic tangens function
+ asinh 1 hyperbolic arcus sine function
+ acosh 1 hyperbolic arcus tangens function
+ atanh 1 hyperbolic arcur tangens function
+ log2 1 logarithm to the base 2
+ log10 1 logarithm to the base 10
+ log 1 logarithm to the base 10
+ ln 1 logarithm to base e (2.71828...)
+ exp 1 e raised to the power of x
+ sqrt 1 square root of a value
+ sign 1 sign function -1 if x<0; 1 if x>0
+ rint 1 round to nearest integer
+ abs 1 absolute value
+ min var. min of all arguments
+ max var. max of all arguments
+ sum var. sum of all arguments
+ avg var. mean value of all arguments
+ rand 1 rand(seed), random float between 0 and 1,
+ if seed = -1, then a 'random' seed is created.
+ rand2 3 rand(a, b, seed), random float between a and b,
+ if seed = -1, a 'random' seed is created using either
+ by random\_device or by reading system clock
+
+ Operators
+ Op meaning priority
+ = assignment -1
+ && logical and 1
+ || logical or 2
+ <= less or equal 4
+ >= greater or equal 4
+ != not equal 4
+ == equal 4
+ > greater than 4
+ < less than 4
+ + addition 5
+ - subtraction 5
+ * multiplication 6
+ / division 6
+ ^ raise x to the power of y 7
+ % floating point modulo 7
+
+ ?: if then else operator C++ style syntax
+
+
+
+ .. py:attribute:: numVars
+
+ unsigned int (*value field*) Number of variables used by Function.
+
+
+ .. py:attribute:: independent
+
+ string (*value field*) Index of independent variable. Differentiation is done based on this. Defaults to the first assigned variable.
+
+
+ .. py:attribute:: c
+
+ string,double (*lookup field*) Constants used in the function. These must be assigned before specifying the function expression.
+
+
+.. py:class:: GammaRng
+
+ Gamma distributed random number generator.
+
+ .. py:method:: setAlpha
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlpha
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTheta
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTheta
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: alpha
+
+ double (*value field*) Parameter alpha of the gamma distribution.
+
+
+ .. py:attribute:: theta
+
+ double (*value field*) Parameter theta of the Gamma distribution.
diff --git a/docs/source/user/py/references/GammaRng.rst b/docs/source/user/py/references/GammaRng.rst
new file mode 100644
index 0000000000..ab9145c9e0
--- /dev/null
+++ b/docs/source/user/py/references/GammaRng.rst
@@ -0,0 +1,35 @@
+GammaRng
+--------
+
+.. py:class:: GammaRng
+
+ Gamma distributed random number generator.
+
+ .. py:method:: setAlpha
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlpha
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTheta
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTheta
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: alpha
+
+ double (*value field*) Parameter alpha of the gamma distribution.
+
+
+ .. py:attribute:: theta
+
+ double (*value field*) Parameter theta of the Gamma distribution.
diff --git a/docs/source/user/py/references/GapJunction.rst b/docs/source/user/py/references/GapJunction.rst
new file mode 100644
index 0000000000..960874d70b
--- /dev/null
+++ b/docs/source/user/py/references/GapJunction.rst
@@ -0,0 +1,74 @@
+GapJunction
+-----------
+
+.. py:class:: GapJunction
+
+ Implementation of gap junction between two compartments. The shared
+ fields, 'channel1' and 'channel2' can be connected to the 'channel'
+ message of the compartments at either end of the gap junction. The
+ compartments will send their Vm to the gap junction and receive the
+ conductance 'Gk' of the gap junction and the Vm of the other
+ compartment.
+
+ .. py:attribute:: channel1
+
+ void (*shared message field*) This is a shared message to couple the conductance and Vm from
+ terminal 2 to the compartment at terminal 1. The first entry is source
+ sending out Gk and Vm2, the second entry is destination for Vm1.
+
+
+ .. py:attribute:: channel2
+
+ void (*shared message field*) This is a shared message to couple the conductance and Vm from
+ terminal 1 to the compartment at terminal 2. The first entry is source
+ sending out Gk and Vm1, the second entry is destination for Vm2.
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process messages from the scheduler objects. The Process should be called \_second\_ in each clock tick, after the Init message.The first entry in the shared msg is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt and so on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: Vm1
+
+ (*destination message field*) Handles Vm message from compartment
+
+
+ .. py:method:: Vm2
+
+ (*destination message field*) Handles Vm message from another compartment
+
+
+ .. py:method:: setGk
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGk
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles 'process' call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles 'reinit' call
+
+
+ .. py:attribute:: channel1Out
+
+ double,double (*source message field*) Sends Gk and Vm from one compartment to the other
+
+
+ .. py:attribute:: channel2Out
+
+ double,double (*source message field*) Sends Gk and Vm from one compartment to the other
+
+
+ .. py:attribute:: Gk
+
+ double (*value field*) Conductance of the gap junction
diff --git a/docs/source/user/py/references/GraupnerBrunel2012CaPlasticitySynHandler.rst b/docs/source/user/py/references/GraupnerBrunel2012CaPlasticitySynHandler.rst
new file mode 100644
index 0000000000..7f9f05233b
--- /dev/null
+++ b/docs/source/user/py/references/GraupnerBrunel2012CaPlasticitySynHandler.rst
@@ -0,0 +1,275 @@
+GraupnerBrunel2012CaPlasticitySynHandler
+----------------------------------------
+
+.. py:class:: GraupnerBrunel2012CaPlasticitySynHandler
+
+ The GraupnerBrunel2012CaPlasticitySynHandler handles synapseswith Ca-based plasticity as per Higgins et al. 2014 and Graupner and Brunel 2012.Note 1: Here, Ca ('chemical Ca') is updated only at each pre-spike, pre-spike+delayD and post-spike! So it is inaccurate to use it for say Ca-dependent K channels in the electrical compartment, for which you use are advised to use the CaPool i.e. 'electrical Ca'.Note 2: Ca here is post-synaptic 'chemical Ca' common for all synapses in this SynHandler, so weights of all pre-synapses connected to this SynHandler get updated at each pre-spike, pre-spike+delayD and post-spike! So if all pre-synaptic weights start out the same, they remain the same!! If you want to consider each pre-synapse independently, have independent SynHandlers for each synapse. If these SynHandlers are in the same electrical compartment, you're essentially assuming these are on different spines, with their own 'chemical Ca' which won't match the 'electrical Ca' of the compartment (=dendrite). If you put each SynHandler with a single synapse in its own electrical compartment (=spine), only then can you have an 'electrical Ca' corresponding to the 'chemical Ca'.Three priority queues are used to manage pre, post, and pre+delayD spikes.
+
+ .. py:method:: setNumSynapse
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumSynapse
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: addPostSpike
+
+ (*destination message field*) Handles arriving spike messages from post-synaptic neuron, inserts into postEvent queue.
+
+
+ .. py:method:: setCa
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCa
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaInit
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaInit
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTauCa
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTauCa
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTauSyn
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTauSyn
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaPre
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaPre
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaPost
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaPost
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDelayD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDelayD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThetaP
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThetaP
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThetaD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThetaD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setGammaP
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGammaP
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setGammaD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGammaD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setWeightMax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getWeightMax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setWeightMin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getWeightMin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setWeightScale
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getWeightScale
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNoisy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNoisy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNoiseSD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNoiseSD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setBistable
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getBistable
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: Ca
+
+ double (*value field*) Ca is a post-synaptic decaying variable as a proxy for Ca concentrationand receives an impulse whenever a pre- or post- spike occurs.Caution: Ca is updated via an event-based rule, so it is only updated and validwhen a pre- or post- spike has occured, or at time delayD after a pre-spike.Do not use it to control a Ca dependent current, etc.See notes in the class Description: all pre-synapses get updated via the same post-synaptic Ca.
+
+
+ .. py:attribute:: CaInit
+
+ double (*value field*) CaInit is the initial value for Ca
+
+
+ .. py:attribute:: tauCa
+
+ double (*value field*) tauCa is the time constant for decay of Ca
+
+
+ .. py:attribute:: tauSyn
+
+ double (*value field*) tauSyn is the time constant for synaptic weight evolution equation
+
+
+ .. py:attribute:: CaPre
+
+ double (*value field*) CaPre is added to Ca on every pre-spike
+
+
+ .. py:attribute:: CaPost
+
+ double (*value field*) CaPost is added to Ca on every post-spike
+
+
+ .. py:attribute:: delayD
+
+ double (*value field*) Time delay D after pre-spike, when Ca is increased by Capre. delayD represents NMDA rise time.
+
+
+ .. py:attribute:: thetaP
+
+ double (*value field*) Potentiation threshold for CaUser must ensure thetaP>thetaD, else simulation results will be wrong.
+
+
+ .. py:attribute:: thetaD
+
+ double (*value field*) Depression threshold for CaUser must ensure thetaP>thetaD, else simulation results will be wrong.
+
+
+ .. py:attribute:: gammaP
+
+ double (*value field*) gammaP is the potentiation factor for synaptic weight increase if Ca>thetaP
+
+
+ .. py:attribute:: gammaD
+
+ double (*value field*) gammaD is the depression factor for synaptic weight decrease if Ca>thetaD
+
+
+ .. py:attribute:: weightMax
+
+ double (*value field*) An upper bound on the weight
+
+
+ .. py:attribute:: weightMin
+
+ double (*value field*) A lower bound on the weight
+
+
+ .. py:attribute:: weightScale
+
+ double (*value field*) Scale all pre-synaptic weights by weightScale before adding to activation (default 1.0)In the terminology of the paper Higgins et al 2012, weight is synaptic efficacy,while weightScale*weight is what finally is added to activation variable.
+
+
+ .. py:attribute:: noisy
+
+ bool (*value field*) If true, turn noise on as per noiseSD
+
+
+ .. py:attribute:: noiseSD
+
+ double (*value field*) Standard deviation of noise added to Ca
+
+
+ .. py:attribute:: bistable
+
+ bool (*value field*) If true, the synapse is bistable as in GraupnerBrunel2012 paper.The effect of potential on the weight update is usually ignorable if Ca is above thetaP and thetaD most of the time.
diff --git a/docs/source/user/py/references/Group.rst b/docs/source/user/py/references/Group.rst
new file mode 100644
index 0000000000..ee0da36eda
--- /dev/null
+++ b/docs/source/user/py/references/Group.rst
@@ -0,0 +1,9 @@
+Group
+-----
+
+.. py:class:: Group
+
+
+ .. py:attribute:: group
+
+ void (*source message field*) Handle for grouping Elements
diff --git a/docs/source/user/py/references/Gsolve.rst b/docs/source/user/py/references/Gsolve.rst
new file mode 100644
index 0000000000..2d5655f013
--- /dev/null
+++ b/docs/source/user/py/references/Gsolve.rst
@@ -0,0 +1,168 @@
+Gsolve
+------
+
+.. py:class:: Gsolve
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:attribute:: init
+
+ void (*shared message field*) Shared message for initProc and initReinit. This is used when the system has cross-compartment reactions.
+
+
+ .. py:attribute:: xCompt
+
+ void (*shared message field*) Shared message for pool exchange for cross-compartment reactions. Exchanges latest values of all pools that participate in such reactions.
+
+
+ .. py:method:: setStoich
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getStoich
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumLocalVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNVec
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNVec
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumAllVoxels
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumAllVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumPools
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumPools
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: voxelVol
+
+ (*destination message field*) Handles updates to all voxels. Comes from parent ChemCompt object.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: initProc
+
+ (*destination message field*) Handles initProc call from Clock
+
+
+ .. py:method:: initReinit
+
+ (*destination message field*) Handles initReinit call from Clock
+
+
+ .. py:method:: xComptIn
+
+ (*destination message field*) Handles arriving pool 'n' values used in cross-compartment reactions.
+
+
+ .. py:method:: setUseRandInit
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getUseRandInit
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setUseClockedUpdate
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getUseClockedUpdate
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumFire
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: xComptOut
+
+ Id,vector (*source message field*) Sends 'n' of all molecules participating in cross-compartment reactions between any juxtaposed voxels between current compt and another compartment. This includes molecules local to this compartment, as well as proxy molecules belonging elsewhere. A(t+1) = (Alocal(t+1) + AremoteProxy(t+1)) - Alocal(t) A(t+1) = (Aremote(t+1) + Aproxy(t+1)) - Aproxy(t) Then we update A on the respective solvers with: Alocal(t+1) = Aproxy(t+1) = A(t+1) This is equivalent to sending dA over on each timestep.
+
+
+ .. py:attribute:: stoich
+
+ Id (*value field*) Stoichiometry object for handling this reaction system.
+
+
+ .. py:attribute:: numLocalVoxels
+
+ unsigned int (*value field*) Number of voxels in the core reac-diff system, on the current solver.
+
+
+ .. py:attribute:: numAllVoxels
+
+ unsigned int (*value field*) Number of voxels in the entire reac-diff system, including proxy voxels to represent abutting compartments.
+
+
+ .. py:attribute:: numPools
+
+ unsigned int (*value field*) Number of molecular pools in the entire reac-diff system, including variable, function and buffered.
+
+
+ .. py:attribute:: useRandInit
+
+ bool (*value field*) Flag: True when using probabilistic (random) rounding.
+ Default: True.
+ When initializing the mol# from floating-point Sinit values, we have two options. One is to look at each Sinit, and round to the nearest integer. The other is to look at each Sinit, and probabilistically round up or down depending on the value. For example, if we had a Sinit value of 1.49, this would always be rounded to 1.0 if the flag is false, and would be rounded to 1.0 and 2.0 in the ratio 51:49 if the flag is true.
+
+
+ .. py:attribute:: useClockedUpdate
+
+ bool (*value field*) Flag: True to cause all reaction propensities to be updated on every clock tick.
+ Default: False.
+ This flag should be set when the reaction system includes a function with a dependency on time or on external events. It has a significant speed penalty so the flag should not be set unless there are such functions.
+
+
+ .. py:attribute:: nVec
+
+ unsigned int,vector (*lookup field*) vector of pool counts
+
+
+ .. py:attribute:: numFire
+
+ unsigned int,vector (*lookup field*) Vector of the number of times each reaction has fired.Indexed by the voxel number.Zeroed out at reinit.
diff --git a/docs/source/user/py/references/HDF5DataWriter.rst b/docs/source/user/py/references/HDF5DataWriter.rst
new file mode 100644
index 0000000000..c5177da92b
--- /dev/null
+++ b/docs/source/user/py/references/HDF5DataWriter.rst
@@ -0,0 +1,43 @@
+HDF5DataWriter
+--------------
+
+.. py:class:: HDF5DataWriter
+
+ HDF5 file writer for saving field values from multiple objects.
+ Connect the `requestOut` field of this object to the `get{Fieldname}` of other objects where `fieldname` is the target value field of type double. The HDF5DataWriter collects the current values of the fields in all the targets at each time step in a local buffer. When the buffer size exceeds `flushLimit` (default 4M), it will write the data into the HDF5 file specified in its `filename` field (default moose\_output.h5). You can explicitly force writing by calling the `flush` function.
+ The dataset location in the output file replicates the MOOSE element tree structure. Thus, if you record the Vm field from `/model[0]/neuron[0]/soma[0], the dataset path will be `/model[0]/neuron[0]/soma[0]/vm`
+ NOTE: The output file remains open until this object is destroyed, or `close()` is called explicitly.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message to receive process and reinit
+
+
+ .. py:method:: setFlushLimit
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getFlushLimit
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handle process calls. Gets data from connected fields into a local buffer and dumps them to `filename` if the buffer length exceeds `flushLimit`
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Reinitialize the object. If the current file handle is valid, it tries to close that and open the file specified in current filename field.
+
+
+ .. py:attribute:: requestOut
+
+ PSt6vectorIdSaIdEE (*source message field*) Sends request for a field to target object
+
+
+ .. py:attribute:: flushLimit
+
+ unsigned int (*value field*) Buffer size limit for flushing the data from memory to file. Default is 4M doubles.
diff --git a/docs/source/user/py/references/HDF5WriterBase.rst b/docs/source/user/py/references/HDF5WriterBase.rst
new file mode 100644
index 0000000000..b678863215
--- /dev/null
+++ b/docs/source/user/py/references/HDF5WriterBase.rst
@@ -0,0 +1,190 @@
+HDF5WriterBase
+--------------
+
+.. py:class:: HDF5WriterBase
+
+ HDF5 file writer base class. This is not to be used directly. Instead, it should be subclassed to provide specific data writing functions. This class provides most basic properties like filename, file opening mode, file open status.
+
+ .. py:method:: setFilename
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getFilename
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getIsOpen
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMode
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMode
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setChunkSize
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getChunkSize
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCompressor
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCompressor
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCompression
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCompression
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setStringAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getStringAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDoubleAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDoubleAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLongAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLongAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setStringVecAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getStringVecAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDoubleVecAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDoubleVecAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLongVecAttr
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLongVecAttr
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: flush
+
+ (*destination message field*) Write all buffer contents to file and clear the buffers.
+
+
+ .. py:method:: close
+
+ (*destination message field*) Close the underlying file. This is a safety measure so that file is not in an invalid state even if a crash happens at exit.
+
+
+ .. py:attribute:: filename
+
+ string (*value field*) Name of the file associated with this HDF5 writer object.
+
+
+ .. py:attribute:: isOpen
+
+ bool (*value field*) True if this object has an open file handle.
+
+
+ .. py:attribute:: mode
+
+ unsigned int (*value field*) Depending on mode, if file already exists, if mode=1, data will be appended to existing file, if mode=2, file will be truncated, if mode=4, no writing will happen.
+
+
+ .. py:attribute:: chunkSize
+
+ unsigned int (*value field*) Chunksize for writing array data. Defaults to 100.
+
+
+ .. py:attribute:: compressor
+
+ string (*value field*) Compression type for array data. zlib and szip are supported. Defaults to zlib.
+
+
+ .. py:attribute:: compression
+
+ unsigned int (*value field*) Compression level for array data. Defaults to 6.
+
+
+ .. py:attribute:: stringAttr
+
+ string,string (*lookup field*) String attributes. The key is attribute name, value is attribute value (string).
+
+
+ .. py:attribute:: doubleAttr
+
+ string,double (*lookup field*) Double precision floating point attributes. The key is attribute name, value is attribute value (double).
+
+
+ .. py:attribute:: longAttr
+
+ string,long (*lookup field*) Long integer attributes. The key is attribute name, value is attribute value (long).
+
+
+ .. py:attribute:: stringVecAttr
+
+ string,vector (*lookup field*) String vector attributes. The key is attribute name, value is attribute value (string).
+
+
+ .. py:attribute:: doubleVecAttr
+
+ string,vector (*lookup field*) Double vector attributes. The key is attribute name, value is attribute value (vector of double).
+
+
+ .. py:attribute:: longVecAttr
+
+ string,vector (*lookup field*) Long integer vector attributes. The key is attribute name, value is attribute value (vector of long).
diff --git a/docs/source/user/py/references/HHChannel.rst b/docs/source/user/py/references/HHChannel.rst
new file mode 100644
index 0000000000..ab3b637934
--- /dev/null
+++ b/docs/source/user/py/references/HHChannel.rst
@@ -0,0 +1,6 @@
+HHChannel
+---------
+
+.. py:class:: HHChannel
+
+ HHChannel: Hodgkin-Huxley type voltage-gated Ion channel. Something like the old tabchannel from GENESIS, but also presents a similar interface as hhchan from GENESIS.
diff --git a/docs/source/user/py/references/HHChannel2D.rst b/docs/source/user/py/references/HHChannel2D.rst
new file mode 100644
index 0000000000..88436ce190
--- /dev/null
+++ b/docs/source/user/py/references/HHChannel2D.rst
@@ -0,0 +1,195 @@
+HHChannel2D
+-----------
+
+.. py:class:: HHChannel2D
+
+ HHChannel2D: Hodgkin-Huxley type voltage-gated Ion channel. Something like the old tabchannel from GENESIS, but also presents a similar interface as hhchan from GENESIS.
+
+ .. py:method:: setXindex
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXindex
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYindex
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYindex
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZindex
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZindex
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInstant
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInstant
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: concen
+
+ (*destination message field*) Incoming message from Concen object to specific conc to useas the first concen variable
+
+
+ .. py:method:: concen2
+
+ (*destination message field*) Incoming message from Concen object to specific conc to useas the second concen variable
+
+
+ .. py:method:: setNumGateX
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateX
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumGateY
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateY
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumGateZ
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateZ
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: Xindex
+
+ string (*value field*) String for setting X index.
+
+
+ .. py:attribute:: Yindex
+
+ string (*value field*) String for setting Y index.
+
+
+ .. py:attribute:: Zindex
+
+ string (*value field*) String for setting Z index.
+
+
+ .. py:attribute:: Xpower
+
+ double (*value field*) Power for X gate
+
+
+ .. py:attribute:: Ypower
+
+ double (*value field*) Power for Y gate
+
+
+ .. py:attribute:: Zpower
+
+ double (*value field*) Power for Z gate
+
+
+ .. py:attribute:: instant
+
+ int (*value field*) Bitmapped flag: bit 0 = Xgate, bit 1 = Ygate, bit 2 = ZgateWhen true, specifies that the lookup table value should beused directly as the state of the channel, rather than usedas a rate term for numerical integration for the state
+
+
+ .. py:attribute:: X
+
+ double (*value field*) State variable for X gate
+
+
+ .. py:attribute:: Y
+
+ double (*value field*) State variable for Y gate
+
+
+ .. py:attribute:: Z
+
+ double (*value field*) State variable for Y gate
diff --git a/docs/source/user/py/references/HHChannelBase.rst b/docs/source/user/py/references/HHChannelBase.rst
new file mode 100644
index 0000000000..883df6b40e
--- /dev/null
+++ b/docs/source/user/py/references/HHChannelBase.rst
@@ -0,0 +1,165 @@
+HHChannelBase
+-------------
+
+.. py:class:: HHChannelBase
+
+ HHChannelBase: Base class for Hodgkin-Huxley type voltage-gated Ion channels. Something like the old tabchannel from GENESIS, but also presents a similar interface as hhchan from GENESIS.
+
+ .. py:method:: setXpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZpower
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZpower
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInstant
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInstant
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setX
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getX
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setY
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setZ
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setUseConcentration
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getUseConcentration
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: concen
+
+ (*destination message field*) Incoming message from Concen object to specific conc to usein the Z gate calculations
+
+
+ .. py:method:: createGate
+
+ (*destination message field*) Function to create specified gate.Argument: Gate type [X Y Z]
+
+
+ .. py:method:: setNumGateX
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateX
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumGateY
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateY
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumGateZ
+
+ (*destination message field*) Assigns number of field entries in field array.
+
+
+ .. py:method:: getNumGateZ
+
+ (*destination message field*) Requests number of field entries in field array.The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: Xpower
+
+ double (*value field*) Power for X gate
+
+
+ .. py:attribute:: Ypower
+
+ double (*value field*) Power for Y gate
+
+
+ .. py:attribute:: Zpower
+
+ double (*value field*) Power for Z gate
+
+
+ .. py:attribute:: instant
+
+ int (*value field*) Bitmapped flag: bit 0 = Xgate, bit 1 = Ygate, bit 2 = ZgateWhen true, specifies that the lookup table value should beused directly as the state of the channel, rather than usedas a rate term for numerical integration for the state
+
+
+ .. py:attribute:: X
+
+ double (*value field*) State variable for X gate
+
+
+ .. py:attribute:: Y
+
+ double (*value field*) State variable for Y gate
+
+
+ .. py:attribute:: Z
+
+ double (*value field*) State variable for Y gate
+
+
+ .. py:attribute:: useConcentration
+
+ int (*value field*) Flag: when true, use concentration message rather than Vm tocontrol Z gate
diff --git a/docs/source/user/py/references/HHGate.rst b/docs/source/user/py/references/HHGate.rst
new file mode 100644
index 0000000000..29f85ade9d
--- /dev/null
+++ b/docs/source/user/py/references/HHGate.rst
@@ -0,0 +1,215 @@
+HHGate
+------
+
+.. py:class:: HHGate
+
+ HHGate: Gate for Hodkgin-Huxley type channels, equivalent to the m and h terms on the Na squid channel and the n term on K. This takes the voltage and state variable from the channel, computes the new value of the state variable and a scaling, depending on gate power, for the conductance.
+
+ .. py:method:: getA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAlpha
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlpha
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setBeta
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getBeta
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTau
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTau
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMInfinity
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMInfinity
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDivs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDivs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTableA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTableA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTableB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTableB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setUseInterpolation
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getUseInterpolation
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAlphaParms
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlphaParms
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setupAlpha
+
+ (*destination message field*) Set up both gates using 13 parameters, as follows:setupAlpha AA AB AC AD AF BA BB BC BD BF xdivs xmin xmaxHere AA-AF are Coefficients A to F of the alpha (forward) termHere BA-BF are Coefficients A to F of the beta (reverse) termHere xdivs is the number of entries in the table,xmin and xmax define the range for lookup.Outside this range the returned value will be the low [high]entry of the table.The equation describing each table is:y(x) = (A + B * x) / (C + exp((x + D) / F))The original HH equations can readily be cast into this form
+
+
+ .. py:method:: setupTau
+
+ (*destination message field*) Identical to setupAlpha, except that the forms specified bythe 13 parameters are for the tau and m-infinity curves ratherthan the alpha and beta terms. So the parameters are:setupTau TA TB TC TD TF MA MB MC MD MF xdivs xmin xmaxAs before, the equation describing each curve is:y(x) = (A + B * x) / (C + exp((x + D) / F))
+
+
+ .. py:method:: tweakAlpha
+
+ (*destination message field*) Dummy function for backward compatibility. It used to convertthe tables from alpha, beta values to alpha, alpha+betabecause the internal calculations used these forms. Notneeded now, deprecated.
+
+
+ .. py:method:: tweakTau
+
+ (*destination message field*) Dummy function for backward compatibility. It used to convertthe tables from tau, minf values to alpha, alpha+betabecause the internal calculations used these forms. Notneeded now, deprecated.
+
+
+ .. py:method:: setupGate
+
+ (*destination message field*) Sets up one gate at a time using the alpha/beta form.Has 9 parameters, as follows:setupGate A B C D F xdivs xmin xmax is\_betaThis sets up the gate using the equation:y(x) = (A + B * x) / (C + exp((x + D) / F))Deprecated.
+
+
+ .. py:attribute:: alpha
+
+ vector (*value field*) Parameters for voltage-dependent rates, alpha:Set up alpha term using 5 parameters, as follows:y(x) = (A + B * x) / (C + exp((x + D) / F))The original HH equations can readily be cast into this form
+
+
+ .. py:attribute:: beta
+
+ vector (*value field*) Parameters for voltage-dependent rates, beta:Set up beta term using 5 parameters, as follows:y(x) = (A + B * x) / (C + exp((x + D) / F))The original HH equations can readily be cast into this form
+
+
+ .. py:attribute:: tau
+
+ vector (*value field*) Parameters for voltage-dependent rates, tau:Set up tau curve using 5 parameters, as follows:y(x) = (A + B * x) / (C + exp((x + D) / F))
+
+
+ .. py:attribute:: mInfinity
+
+ vector (*value field*) Parameters for voltage-dependent rates, mInfinity:Set up mInfinity curve using 5 parameters, as follows:y(x) = (A + B * x) / (C + exp((x + D) / F))The original HH equations can readily be cast into this form
+
+
+ .. py:attribute:: min
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: max
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: divs
+
+ unsigned int (*value field*) Divisions for lookup. Zero means to use linear interpolation
+
+
+ .. py:attribute:: tableA
+
+ vector (*value field*) Table of A entries
+
+
+ .. py:attribute:: tableB
+
+ vector (*value field*) Table of alpha + beta entries
+
+
+ .. py:attribute:: useInterpolation
+
+ bool (*value field*) Flag: use linear interpolation if true, else direct lookup
+
+
+ .. py:attribute:: alphaParms
+
+ vector (*value field*) Set up both gates using 13 parameters, as follows:setupAlpha AA AB AC AD AF BA BB BC BD BF xdivs xmin xmaxHere AA-AF are Coefficients A to F of the alpha (forward) termHere BA-BF are Coefficients A to F of the beta (reverse) termHere xdivs is the number of entries in the table,xmin and xmax define the range for lookup.Outside this range the returned value will be the low [high]entry of the table.The equation describing each table is:y(x) = (A + B * x) / (C + exp((x + D) / F))The original HH equations can readily be cast into this form
+
+
+ .. py:attribute:: A
+
+ double,double (*lookup field*) lookupA: Look up the A gate value from a double. Usually doesso by direct scaling and offset to an integer lookup, usinga fine enough table granularity that there is little error.Alternatively uses linear interpolation.The range of the double is predefined based on knowledge ofvoltage or conc ranges, and the granularity is specified bythe xmin, xmax, and dV fields.
+
+
+ .. py:attribute:: B
+
+ double,double (*lookup field*) lookupB: Look up the B gate value from a double.Note that this looks up the raw tables, which are transformedfrom the reference parameters.
diff --git a/docs/source/user/py/references/HHGate2D.rst b/docs/source/user/py/references/HHGate2D.rst
new file mode 100644
index 0000000000..148b44c08b
--- /dev/null
+++ b/docs/source/user/py/references/HHGate2D.rst
@@ -0,0 +1,235 @@
+HHGate2D
+--------
+
+.. py:class:: HHGate2D
+
+ HHGate2D: Gate for Hodkgin-Huxley type channels, equivalent to the m and h terms on the Na squid channel and the n term on K. This takes the voltage and state variable from the channel, computes the new value of the state variable and a scaling, depending on gate power, for the conductance. These two terms are sent right back in a message to the channel.
+
+ .. py:method:: getA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTableA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTableA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTableB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTableB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXminA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXminA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmaxA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmaxA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXdivsA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXdivsA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYminA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYminA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmaxA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmaxA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYdivsA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYdivsA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXminB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXminB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmaxB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmaxB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXdivsB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXdivsB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYminB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYminB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmaxB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmaxB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYdivsB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYdivsB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: tableA
+
+ vector< vector > (*value field*) Table of A entries
+
+
+ .. py:attribute:: tableB
+
+ vector< vector > (*value field*) Table of B entries
+
+
+ .. py:attribute:: xminA
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: xmaxA
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: xdivsA
+
+ unsigned int (*value field*) Divisions for lookup. Zero means to use linear interpolation
+
+
+ .. py:attribute:: yminA
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: ymaxA
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: ydivsA
+
+ unsigned int (*value field*) Divisions for lookup. Zero means to use linear interpolation
+
+
+ .. py:attribute:: xminB
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: xmaxB
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: xdivsB
+
+ unsigned int (*value field*) Divisions for lookup. Zero means to use linear interpolation
+
+
+ .. py:attribute:: yminB
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: ymaxB
+
+ double (*value field*) Minimum range for lookup
+
+
+ .. py:attribute:: ydivsB
+
+ unsigned int (*value field*) Divisions for lookup. Zero means to use linear interpolation
+
+
+ .. py:attribute:: A
+
+ vector,double (*lookup field*) lookupA: Look up the A gate value from two doubles, passedin as a vector. Uses linear interpolation in the 2D tableThe range of the lookup doubles is predefined based on knowledge of voltage or conc ranges, and the granularity is specified by the xmin, xmax, and dx field, and their y-axis counterparts.
+
+
+ .. py:attribute:: B
+
+ vector,double (*lookup field*) lookupB: Look up B gate value from two doubles in a vector.
diff --git a/docs/source/user/py/references/HSolve.rst b/docs/source/user/py/references/HSolve.rst
new file mode 100644
index 0000000000..d0be86cd15
--- /dev/null
+++ b/docs/source/user/py/references/HSolve.rst
@@ -0,0 +1,170 @@
+HSolve
+------
+
+.. py:class:: HSolve
+
+ HSolve: Hines solver, for solving branching neuron models.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Handles 'reinit' and 'process' calls from a clock.
+
+
+ .. py:method:: setSeed
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getSeed
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTarget
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTarget
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDt
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDt
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaAdvance
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaAdvance
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVDiv
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVDiv
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVMin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVMin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVMax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVMax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaDiv
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaDiv
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaMin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaMin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCaMax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCaMax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles 'process' call: Solver advances by one time-step.
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles 'reinit' call: Solver reads in model.
+
+
+ .. py:attribute:: seed
+
+ Id (*value field*) Use this field to specify path to a 'seed' compartment, that is, any compartment within a neuron. The HSolve object uses this seed as a handle to discover the rest of the neuronal model, which means all the remaining compartments, channels, synapses, etc.
+
+
+ .. py:attribute:: target
+
+ string (*value field*) Specifies the path to a compartmental model to be taken over. This can be the path to any container object that has the model under it (found by performing a deep search). Alternatively, this can also be the path to any compartment within the neuron. This compartment will be used as a handle to discover the rest of the model, which means all the remaining compartments, channels, synapses, etc.
+
+
+ .. py:attribute:: dt
+
+ double (*value field*) The time-step for this solver.
+
+
+ .. py:attribute:: caAdvance
+
+ int (*value field*) This flag determines how current flowing into a calcium pool is computed. A value of 0 means that the membrane potential at the beginning of the time-step is used for the calculation. This is how GENESIS does its computations. A value of 1 means the membrane potential at the middle of the time-step is used. This is the correct way of integration, and is the default way.
+
+
+ .. py:attribute:: vDiv
+
+ int (*value field*) Specifies number of divisions for lookup tables of voltage-sensitive channels.
+
+
+ .. py:attribute:: vMin
+
+ double (*value field*) Specifies the lower bound for lookup tables of voltage-sensitive channels. Default is to automatically decide based on the tables of the channels that the solver reads in.
+
+
+ .. py:attribute:: vMax
+
+ double (*value field*) Specifies the upper bound for lookup tables of voltage-sensitive channels. Default is to automatically decide based on the tables of the channels that the solver reads in.
+
+
+ .. py:attribute:: caDiv
+
+ int (*value field*) Specifies number of divisions for lookup tables of calcium-sensitive channels.
+
+
+ .. py:attribute:: caMin
+
+ double (*value field*) Specifies the lower bound for lookup tables of calcium-sensitive channels. Default is to automatically decide based on the tables of the channels that the solver reads in.
+
+
+ .. py:attribute:: caMax
+
+ double (*value field*) Specifies the upper bound for lookup tables of calcium-sensitive channels. Default is to automatically decide based on the tables of the channels that the solver reads in.
diff --git a/docs/source/user/py/references/InputVariable.rst b/docs/source/user/py/references/InputVariable.rst
new file mode 100644
index 0000000000..6f3c2c5ea1
--- /dev/null
+++ b/docs/source/user/py/references/InputVariable.rst
@@ -0,0 +1,10 @@
+InputVariable
+-------------
+
+.. py:class:: InputVariable
+
+ Variable for capturing incoming values and updating them in owner object.
+
+ .. py:method:: input
+
+ (*destination message field*) Handles input message, inserts into variable queue on owner.
diff --git a/docs/source/user/py/references/IntFire.rst b/docs/source/user/py/references/IntFire.rst
new file mode 100644
index 0000000000..01ac9d8a9a
--- /dev/null
+++ b/docs/source/user/py/references/IntFire.rst
@@ -0,0 +1,89 @@
+IntFire
+-------
+
+.. py:class:: IntFire
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: setVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTau
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTau
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setThresh
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThresh
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRefractoryPeriod
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRefractoryPeriod
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: activation
+
+ (*destination message field*) Handles value of synaptic activation arriving on this IntFire
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:attribute:: spikeOut
+
+ double (*source message field*) Sends out spike events. The argument is the timestamp of the spike.
+
+
+ .. py:attribute:: Vm
+
+ double (*value field*) Membrane potential
+
+
+ .. py:attribute:: tau
+
+ double (*value field*) charging time-course
+
+
+ .. py:attribute:: thresh
+
+ double (*value field*) firing threshold
+
+
+ .. py:attribute:: refractoryPeriod
+
+ double (*value field*) Minimum time between successive spikes
diff --git a/docs/source/user/py/references/IntFireBase.rst b/docs/source/user/py/references/IntFireBase.rst
new file mode 100644
index 0000000000..6db3b0c7d4
--- /dev/null
+++ b/docs/source/user/py/references/IntFireBase.rst
@@ -0,0 +1,80 @@
+IntFireBase
+-----------
+
+.. py:class:: IntFireBase
+
+ Base class for Integrate-and-fire compartment.
+
+ .. py:method:: setThresh
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getThresh
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVReset
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVReset
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRefractoryPeriod
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRefractoryPeriod
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getHasFired
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getLastEventTime
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: activation
+
+ (*destination message field*) Handles value of synaptic activation arriving on this object
+
+
+ .. py:attribute:: spikeOut
+
+ double (*source message field*) Sends out spike events. The argument is the timestamp of the spike.
+
+
+ .. py:attribute:: thresh
+
+ double (*value field*) firing threshold
+
+
+ .. py:attribute:: vReset
+
+ double (*value field*) voltage is set to vReset after firing
+
+
+ .. py:attribute:: refractoryPeriod
+
+ double (*value field*) Minimum time between successive spikes
+
+
+ .. py:attribute:: hasFired
+
+ bool (*value field*) The object has fired within the last timestep
+
+
+ .. py:attribute:: lastEventTime
+
+ double (*value field*) Timestamp of last firing.
diff --git a/docs/source/user/py/references/Interpol.rst b/docs/source/user/py/references/Interpol.rst
new file mode 100644
index 0000000000..9aa26130d6
--- /dev/null
+++ b/docs/source/user/py/references/Interpol.rst
@@ -0,0 +1,70 @@
+Interpol
+--------
+
+.. py:class:: Interpol
+
+ Interpol: Interpolation class. Handles lookup from a 1-dimensional array of real-numbered values.Returns 'y' value based on given 'x' value. Can either use interpolation or roundoff to the nearest index.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: setXmin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getY
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: input
+
+ (*destination message field*) Interpolates using the input as x value.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call, updates internal time stamp.
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call.
+
+
+ .. py:attribute:: lookupOut
+
+ double (*source message field*) respond to a request for a value lookup
+
+
+ .. py:attribute:: xmin
+
+ double (*value field*) Minimum value of x. x below this will result in y[0] being returned.
+
+
+ .. py:attribute:: xmax
+
+ double (*value field*) Maximum value of x. x above this will result in y[last] being returned.
+
+
+ .. py:attribute:: y
+
+ double (*value field*) Looked up value.
diff --git a/docs/source/user/py/references/Interpol2D.rst b/docs/source/user/py/references/Interpol2D.rst
new file mode 100644
index 0000000000..7aadf4099b
--- /dev/null
+++ b/docs/source/user/py/references/Interpol2D.rst
@@ -0,0 +1,180 @@
+Interpol2D
+----------
+
+.. py:class:: Interpol2D
+
+ Interpol2D: Interpolation class. Handles lookup from a 2-dimensional grid of real-numbered values. Returns 'z' value based on given 'x' and 'y' values. Can either use interpolation or roundoff to the nearest index.
+
+ .. py:attribute:: lookupReturn2D
+
+ void (*shared message field*) This is a shared message for doing lookups on the table. Receives 2 doubles: x, y. Sends back a double with the looked-up z value.
+
+
+ .. py:method:: lookup
+
+ (*destination message field*) Looks up table value based on indices v1 and v2, and sendsvalue back using the 'lookupOut' message
+
+
+ .. py:method:: setXmin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXdivs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXdivs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDx
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDx
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYdivs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYdivs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setDy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getDy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTable
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTable
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getZ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setTableVector2D
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getTableVector2D
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: lookupOut
+
+ double (*source message field*) respond to a request for a value lookup
+
+
+ .. py:attribute:: xmin
+
+ double (*value field*) Minimum value for x axis of lookup table
+
+
+ .. py:attribute:: xmax
+
+ double (*value field*) Maximum value for x axis of lookup table
+
+
+ .. py:attribute:: xdivs
+
+ unsigned int (*value field*) # of divisions on x axis of lookup table
+
+
+ .. py:attribute:: dx
+
+ double (*value field*) Increment on x axis of lookup table
+
+
+ .. py:attribute:: ymin
+
+ double (*value field*) Minimum value for y axis of lookup table
+
+
+ .. py:attribute:: ymax
+
+ double (*value field*) Maximum value for y axis of lookup table
+
+
+ .. py:attribute:: ydivs
+
+ unsigned int (*value field*) # of divisions on y axis of lookup table
+
+
+ .. py:attribute:: dy
+
+ double (*value field*) Increment on y axis of lookup table
+
+
+ .. py:attribute:: tableVector2D
+
+ vector< vector > (*value field*) Get the entire table.
+
+
+ .. py:attribute:: table
+
+ vector,double (*lookup field*) Lookup an entry on the table
+
+
+ .. py:attribute:: z
+
+ vector,double (*lookup field*) Interpolated value for specified x and y. This is provided for debugging. Normally other objects will retrieve interpolated values via lookup message.
diff --git a/docs/source/user/py/references/IzhIF.rst b/docs/source/user/py/references/IzhIF.rst
new file mode 100644
index 0000000000..5cd783652b
--- /dev/null
+++ b/docs/source/user/py/references/IzhIF.rst
@@ -0,0 +1,140 @@
+IzhIF
+-----
+
+.. py:class:: IzhIF
+
+ Izhikevich neuron (integrate and fire).d Vm /dt = a0 * Vm^2 + b0 * Vm + c0 - u + I/Cm d u / dt = a * ( b * Vm - u ) at each spike, u -> u + d by default, a0 = 0.04e6/V/s, b0 = 5e3/s, c0 = 140 V/s are set to SI units, so use SI consistently, or change a0, b0, c0 also if you wish to use other units. Rm, Em from Compartment are not used here, vReset is same as c in the usual formalism. At rest, u0 = b V0, and V0 = ( -(-b0-b) +/- sqrt((b0-b)^2 - 4*a0*c0)) / (2*a0) equivalently, to obtain resting Em, set b = (a0*Em^2 + b0*Em + c0)/Em
+
+ .. py:method:: setA0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getA0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setB0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getB0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setC0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getC0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setU
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getU
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setUInit
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getUInit
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVPeak
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVPeak
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: a0
+
+ double (*value field*) factor for Vm^2 term in evolution equation for Vm: d Vm /dt = a0 * Vm^2 + b0 * Vm + c0 - u + I/Cm
+
+
+ .. py:attribute:: b0
+
+ double (*value field*) factor for Vm term in evolution equation for Vm: d Vm /dt = a0 * Vm^2 + b0 * Vm + c0 - u + I/Cm
+
+
+ .. py:attribute:: c0
+
+ double (*value field*) constant term in evolution equation for Vm: d Vm /dt = a0 * Vm^2 + b0 * Vm + c0 - u + I/Cm
+
+
+ .. py:attribute:: a
+
+ double (*value field*) a as in d u / dt = a * ( b * Vm - u )
+
+
+ .. py:attribute:: b
+
+ double (*value field*) b as in d u / dt = a * ( b * Vm - u )
+
+
+ .. py:attribute:: d
+
+ double (*value field*) u jumps by d at every spike
+
+
+ .. py:attribute:: u
+
+ double (*value field*) u is an adaptation variable
+
+
+ .. py:attribute:: uInit
+
+ double (*value field*) Initial value of u. It is reset at reinit()
+
+
+ .. py:attribute:: vPeak
+
+ double (*value field*) Vm is reset when Vm > vPeak
diff --git a/docs/source/user/py/references/IzhikevichNrn.rst b/docs/source/user/py/references/IzhikevichNrn.rst
new file mode 100644
index 0000000000..c2b7d573a0
--- /dev/null
+++ b/docs/source/user/py/references/IzhikevichNrn.rst
@@ -0,0 +1,320 @@
+IzhikevichNrn
+-------------
+
+.. py:class:: IzhikevichNrn
+
+ Izhikevich model of spiking neuron (Izhikevich,EM. 2003. Simple model of spiking neurons. Neural Networks, IEEE Transactions on 14(6). pp 1569-1572).
+ This class obeys the equations (in physiological units):
+ dVm/dt = 0.04 * Vm^2 + 5 * Vm + 140 - u + inject
+ du/dt = a * (b * Vm - u)
+ if Vm >= Vmax then Vm = c and u = u + d
+ Vmax = 30 mV in the paper.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message to receive Process message from scheduler
+
+
+ .. py:attribute:: channel
+
+ void (*shared message field*) This is a shared message from a IzhikevichNrn to channels.The first entry is a MsgDest for the info coming from the channel. It expects Gk and Ek from the channel as args. The second entry is a MsgSrc sending Vm
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: setVmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setC
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getC
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setD
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getD
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setA
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getA
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setB
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getB
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getU
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getIm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInject
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInject
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRmByTau
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRmByTau
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAccommodating
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAccommodating
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setU0
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getU0
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInitVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInitVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInitU
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInitU
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAlpha
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAlpha
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setBeta
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getBeta
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setGamma
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGamma
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: injectMsg
+
+ (*destination message field*) Injection current into the neuron.
+
+
+ .. py:method:: cDest
+
+ (*destination message field*) Destination message to modify parameter c at runtime.
+
+
+ .. py:method:: dDest
+
+ (*destination message field*) Destination message to modify parameter d at runtime.
+
+
+ .. py:method:: bDest
+
+ (*destination message field*) Destination message to modify parameter b at runtime
+
+
+ .. py:method:: aDest
+
+ (*destination message field*) Destination message modify parameter a at runtime.
+
+
+ .. py:method:: handleChannel
+
+ (*destination message field*) Handles conductance and reversal potential arguments from Channel
+
+
+ .. py:attribute:: VmOut
+
+ double (*source message field*) Sends out Vm
+
+
+ .. py:attribute:: spikeOut
+
+ double (*source message field*) Sends out spike events
+
+
+ .. py:attribute:: VmOut
+
+ double (*source message field*) Sends out Vm
+
+
+ .. py:attribute:: Vmax
+
+ double (*value field*) Maximum membrane potential. Membrane potential is reset to c whenever it reaches Vmax. NOTE: Izhikevich model specifies the PEAK voltage, rather than THRSHOLD voltage. The threshold depends on the previous history.
+
+
+ .. py:attribute:: c
+
+ double (*value field*) Reset potential. Membrane potential is reset to c whenever it reaches Vmax.
+
+
+ .. py:attribute:: d
+
+ double (*value field*) Parameter d in Izhikevich model. Unit is V/s.
+
+
+ .. py:attribute:: a
+
+ double (*value field*) Parameter a in Izhikevich model. Unit is s^{-1}
+
+
+ .. py:attribute:: b
+
+ double (*value field*) Parameter b in Izhikevich model. Unit is s^{-1}
+
+
+ .. py:attribute:: u
+
+ double (*value field*) Parameter u in Izhikevich equation. Unit is V/s
+
+
+ .. py:attribute:: Vm
+
+ double (*value field*) Membrane potential, equivalent to v in Izhikevich equation.
+
+
+ .. py:attribute:: Im
+
+ double (*value field*) Total current going through the membrane. Unit is A.
+
+
+ .. py:attribute:: inject
+
+ double (*value field*) External current injection into the neuron
+
+
+ .. py:attribute:: RmByTau
+
+ double (*value field*) Hidden coefficient of input current term (I) in Izhikevich model. Defaults to 1e9 Ohm/s.
+
+
+ .. py:attribute:: accommodating
+
+ bool (*value field*) True if this neuron is an accommodating one. The equation for recovery variable u is special in this case.
+
+
+ .. py:attribute:: u0
+
+ double (*value field*) This is used for accommodating neurons where recovery variables u is computed as: u += tau*a*(b*(Vm-u0))
+
+
+ .. py:attribute:: initVm
+
+ double (*value field*) Initial membrane potential. Unit is V.
+
+
+ .. py:attribute:: initU
+
+ double (*value field*) Initial value of u.
+
+
+ .. py:attribute:: alpha
+
+ double (*value field*) Coefficient of v^2 in Izhikevich equation. Defaults to 0.04 in physiological unit. In SI it should be 40000.0. Unit is V^-1 s^{-1}
+
+
+ .. py:attribute:: beta
+
+ double (*value field*) Coefficient of v in Izhikevich model. Defaults to 5 in physiological unit, 5000.0 for SI units. Unit is s^{-1}
+
+
+ .. py:attribute:: gamma
+
+ double (*value field*) Constant term in Izhikevich model. Defaults to 140 in both physiological and SI units. unit is V/s.
diff --git a/docs/source/user/py/references/Ksolve.rst b/docs/source/user/py/references/Ksolve.rst
new file mode 100644
index 0000000000..1c428b7461
--- /dev/null
+++ b/docs/source/user/py/references/Ksolve.rst
@@ -0,0 +1,189 @@
+Ksolve
+------
+
+.. py:class:: Ksolve
+
+
+ .. py:attribute:: xCompt
+
+ void (*shared message field*) Shared message for pool exchange for cross-compartment reactions. Exchanges latest values of all pools that participate in such reactions.
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit. These are used for all regular Ksolve calculations including interfacing with the diffusion calculations by a Dsolve.
+
+
+ .. py:attribute:: init
+
+ void (*shared message field*) Shared message for initProc and initReinit. This is used when the system has cross-compartment reactions.
+
+
+ .. py:method:: setMethod
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMethod
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setEpsAbs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getEpsAbs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setEpsRel
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getEpsRel
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setCompartment
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getCompartment
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getNumLocalVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNVec
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNVec
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumAllVoxels
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumAllVoxels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumPools
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumPools
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getEstimatedDt
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getStoich
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: voxelVol
+
+ (*destination message field*) Handles updates to all voxels. Comes from parent ChemCompt object.
+
+
+ .. py:method:: xComptIn
+
+ (*destination message field*) Handles arriving pool 'n' values used in cross-compartment reactions.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call from Clock
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call from Clock
+
+
+ .. py:method:: initProc
+
+ (*destination message field*) Handles initProc call from Clock
+
+
+ .. py:method:: initReinit
+
+ (*destination message field*) Handles initReinit call from Clock
+
+
+ .. py:attribute:: xComptOut
+
+ Id,vector (*source message field*) Sends 'n' of all molecules participating in cross-compartment reactions between any juxtaposed voxels between current compt and another compartment. This includes molecules local to this compartment, as well as proxy molecules belonging elsewhere. A(t+1) = (Alocal(t+1) + AremoteProxy(t+1)) - Alocal(t) A(t+1) = (Aremote(t+1) + Aproxy(t+1)) - Aproxy(t) Then we update A on the respective solvers with: Alocal(t+1) = Aproxy(t+1) = A(t+1) This is equivalent to sending dA over on each timestep.
+
+
+ .. py:attribute:: method
+
+ string (*value field*) Integration method, using GSL. So far only explict. Options are:rk5: The default Runge-Kutta-Fehlberg 5th order adaptive dt methodgsl: alias for the aboverk4: The Runge-Kutta 4th order fixed dt methodrk2: The Runge-Kutta 2,3 embedded fixed dt methodrkck: The Runge-Kutta Cash-Karp (4,5) methodrk8: The Runge-Kutta Prince-Dormand (8,9) method
+
+
+ .. py:attribute:: epsAbs
+
+ double (*value field*) Absolute permissible integration error range.
+
+
+ .. py:attribute:: epsRel
+
+ double (*value field*) Relative permissible integration error range.
+
+
+ .. py:attribute:: compartment
+
+ Id (*value field*) Compartment in which the Ksolve reaction system lives.
+
+
+ .. py:attribute:: numLocalVoxels
+
+ unsigned int (*value field*) Number of voxels in the core reac-diff system, on the current solver.
+
+
+ .. py:attribute:: numAllVoxels
+
+ unsigned int (*value field*) Number of voxels in the entire reac-diff system, including proxy voxels to represent abutting compartments.
+
+
+ .. py:attribute:: numPools
+
+ unsigned int (*value field*) Number of molecular pools in the entire reac-diff system, including variable, function and buffered.
+
+
+ .. py:attribute:: estimatedDt
+
+ double (*value field*) Estimated timestep for reac system based on Euler error
+
+
+ .. py:attribute:: stoich
+
+ Id (*value field*) Id for stoichiometry object tied to this Ksolve
+
+
+ .. py:attribute:: nVec
+
+ unsigned int,vector (*lookup field*) vector of pool counts. Index specifies which voxel.
diff --git a/docs/source/user/py/references/LIF.rst b/docs/source/user/py/references/LIF.rst
new file mode 100644
index 0000000000..7735fe1ffa
--- /dev/null
+++ b/docs/source/user/py/references/LIF.rst
@@ -0,0 +1,6 @@
+LIF
+---
+
+.. py:class:: LIF
+
+ Leaky Integrate-and-Fire neuron
diff --git a/docs/source/user/py/references/Leakage.rst b/docs/source/user/py/references/Leakage.rst
new file mode 100644
index 0000000000..eb49fa6a79
--- /dev/null
+++ b/docs/source/user/py/references/Leakage.rst
@@ -0,0 +1,6 @@
+Leakage
+-------
+
+.. py:class:: Leakage
+
+ Leakage: Passive leakage channel.
diff --git a/docs/source/user/py/references/MarkovChannel.rst b/docs/source/user/py/references/MarkovChannel.rst
new file mode 100644
index 0000000000..81e4c31d69
--- /dev/null
+++ b/docs/source/user/py/references/MarkovChannel.rst
@@ -0,0 +1,131 @@
+MarkovChannel
+-------------
+
+.. py:class:: MarkovChannel
+
+ MarkovChannel : Multistate ion channel class.It deals with ion channels which can be found in one of multiple states, some of which are conducting. This implementation assumes the occurence of first order kinetics to calculate the probabilities of the channel being found in all states. Further, the rates of transition between these states can be constant, voltage-dependent or ligand dependent (only one ligand species). The current flow obtained from the channel is calculated in a deterministic method by solving the system of differential equations obtained from the assumptions above.
+
+ .. py:method:: setLigandConc
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLigandConc
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumStates
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumStates
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setNumOpenStates
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getNumOpenStates
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getState
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInitialState
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInitialState
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLabels
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLabels
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setGbar
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getGbar
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: handleLigandConc
+
+ (*destination message field*) Deals with incoming messages containing information of ligand concentration
+
+
+ .. py:method:: handleState
+
+ (*destination message field*) Deals with incoming message from MarkovSolver object containing state information of the channel.
+
+
+
+ .. py:attribute:: ligandConc
+
+ double (*value field*) Ligand concentration.
+
+
+ .. py:attribute:: Vm
+
+ double (*value field*) Membrane voltage.
+
+
+ .. py:attribute:: numStates
+
+ unsigned int (*value field*) The number of states that the channel can occupy.
+
+
+ .. py:attribute:: numOpenStates
+
+ unsigned int (*value field*) The number of states which are open/conducting.
+
+
+ .. py:attribute:: state
+
+ vector (*value field*) This is a row vector that contains the probabilities of finding the channel in each state.
+
+
+ .. py:attribute:: initialState
+
+ vector (*value field*) This is a row vector that contains the probabilities of finding the channel in each state at t = 0. The state of the channel is reset to this value during a call to reinit()
+
+
+ .. py:attribute:: labels
+
+ vector (*value field*) Labels for each state.
+
+
+ .. py:attribute:: gbar
+
+ vector (*value field*) A row vector containing the conductance associated with each of the open/conducting states.
diff --git a/docs/source/user/py/references/MarkovGslSolver.rst b/docs/source/user/py/references/MarkovGslSolver.rst
new file mode 100644
index 0000000000..b4623c77d3
--- /dev/null
+++ b/docs/source/user/py/references/MarkovGslSolver.rst
@@ -0,0 +1,105 @@
+MarkovGslSolver
+---------------
+
+.. py:class:: MarkovGslSolver
+
+ Solver for Markov Channel.
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) Shared message for process and reinit
+
+
+ .. py:method:: getIsInitialized
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setMethod
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getMethod
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setRelativeAccuracy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getRelativeAccuracy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setAbsoluteAccuracy
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getAbsoluteAccuracy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInternalDt
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInternalDt
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: init
+
+ (*destination message field*) Initialize solver parameters.
+
+
+ .. py:method:: handleQ
+
+ (*destination message field*) Handles information regarding the instantaneous rate matrix from the MarkovRateTable class.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:attribute:: stateOut
+
+ vector (*source message field*) Sends updated state to the MarkovChannel class.
+
+
+ .. py:attribute:: isInitialized
+
+ bool (*value field*) True if the message has come in to set solver parameters.
+
+
+ .. py:attribute:: method
+
+ string (*value field*) Numerical method to use.
+
+
+ .. py:attribute:: relativeAccuracy
+
+ double (*value field*) Accuracy criterion
+
+
+ .. py:attribute:: absoluteAccuracy
+
+ double (*value field*) Another accuracy criterion
+
+
+ .. py:attribute:: internalDt
+
+ double (*value field*) internal timestep to use.
diff --git a/docs/source/user/py/references/MarkovRateTable.rst b/docs/source/user/py/references/MarkovRateTable.rst
new file mode 100644
index 0000000000..ec6fd41073
--- /dev/null
+++ b/docs/source/user/py/references/MarkovRateTable.rst
@@ -0,0 +1,110 @@
+MarkovRateTable
+---------------
+
+.. py:class:: MarkovRateTable
+
+ Rate Table for Markov channel calculations.
+
+ .. py:attribute:: channel
+
+ void (*shared message field*) This message couples the rate table to the compartment. The rate table needs updates on voltage in order to compute the rate table.
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process message from thescheduler. The first entry is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt andso on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: handleVm
+
+ (*destination message field*) Handles incoming message containing voltage information.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: init
+
+ (*destination message field*) Initialization of the class. Allocates memory for all the tables.
+
+
+ .. py:method:: handleLigandConc
+
+ (*destination message field*) Handles incoming message containing ligand concentration.
+
+
+ .. py:method:: set1d
+
+ (*destination message field*) Setting up of 1D lookup table for the (i,j)'th rate.
+
+
+ .. py:method:: set2d
+
+ (*destination message field*) Setting up of 2D lookup table for the (i,j)'th rate.
+
+
+ .. py:method:: setconst
+
+ (*destination message field*) Setting a constant value for the (i,j)'th rate. Internally, this is stored as a 1-D rate with a lookup table containing 1 entry.
+
+
+ .. py:method:: setVm
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getVm
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setLigandConc
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getLigandConc
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getQ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getSize
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: instratesOut
+
+ vector< vector > (*source message field*) Sends out instantaneous rate information of varying transition ratesat each time step.
+
+
+ .. py:attribute:: Vm
+
+ double (*value field*) Membrane voltage.
+
+
+ .. py:attribute:: ligandConc
+
+ double (*value field*) Ligand concentration.
+
+
+ .. py:attribute:: Q
+
+ vector< vector > (*value field*) Instantaneous rate matrix.
+
+
+ .. py:attribute:: size
+
+ unsigned int (*value field*) Dimension of the families of lookup tables. Is always equal to the number of states in the model.
diff --git a/docs/source/user/py/references/MarkovSolver.rst b/docs/source/user/py/references/MarkovSolver.rst
new file mode 100644
index 0000000000..68e8c97d81
--- /dev/null
+++ b/docs/source/user/py/references/MarkovSolver.rst
@@ -0,0 +1,19 @@
+MarkovSolver
+------------
+
+.. py:class:: MarkovSolver
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process message from thescheduler. The first entry is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt andso on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
diff --git a/docs/source/user/py/references/MarkovSolverBase.rst b/docs/source/user/py/references/MarkovSolverBase.rst
new file mode 100644
index 0000000000..e6cc366750
--- /dev/null
+++ b/docs/source/user/py/references/MarkovSolverBase.rst
@@ -0,0 +1,190 @@
+MarkovSolverBase
+----------------
+
+.. py:class:: MarkovSolverBase
+
+ Solver for Markov Channel.
+
+ .. py:attribute:: channel
+
+ void (*shared message field*) This message couples the MarkovSolverBase to the Compartment. The compartment needs Vm in order to look up the correct matrix exponential for computing the state.
+
+
+ .. py:attribute:: proc
+
+ void (*shared message field*) This is a shared message to receive Process message from thescheduler. The first entry is a MsgDest for the Process operation. It has a single argument, ProcInfo, which holds lots of information about current time, thread, dt andso on. The second entry is a MsgDest for the Reinit operation. It also uses ProcInfo.
+
+
+ .. py:method:: handleVm
+
+ (*destination message field*) Handles incoming message containing voltage information.
+
+
+ .. py:method:: process
+
+ (*destination message field*) Handles process call
+
+
+ .. py:method:: reinit
+
+ (*destination message field*) Handles reinit call
+
+
+ .. py:method:: ligandConc
+
+ (*destination message field*) Handles incoming message containing ligand concentration.
+
+
+ .. py:method:: init
+
+ (*destination message field*) Setups the table of matrix exponentials associated with the solver object.
+
+
+ .. py:method:: getQ
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getState
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setInitialState
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getInitialState
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setXdivs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getXdivs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getInvdx
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmin
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmin
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYmax
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYmax
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: setYdivs
+
+ (*destination message field*) Assigns field value.
+
+
+ .. py:method:: getYdivs
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:method:: getInvdy
+
+ (*destination message field*) Requests field value. The requesting Element must provide a handler for the returned value.
+
+
+ .. py:attribute:: stateOut
+
+ vector