Skip to content
Snippets Groups Projects
Commit 21f5e65e authored by Harsha Rani's avatar Harsha Rani
Browse files

Clean up in README file and deleted unwanted files and folders

parent ff37cca1
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 14 additions and 10658 deletions
docs/user/README.txt
+ 14
− 20
View file @ 21f5e65e
This directory contains MOOSE user documentation. This directory contains MOOSE user documentation.
The documentation is encoded in the Markdown format. Each of the Markdown The documentation is encoded in the Markdown format. Each of the Markdown
files is converted here to a corresponding HTML file for viewing in a browser, files is converted to corresponding reStructuredText (rst) file by running "python markdown2rst.py" which creates rst file into corresponding directory.
and can be converted to many other formats. To learn more about the Markdown To convert rst files, one needs to go to respective directory e.g Rdesigneur run "make html" in terminal, which
creates corresponding HTML file for viewing in a browser in "_build/html" directory.
To learn more about the Markdown
format itself, go to the other 'markdown' directory one level up, in the format itself, go to the other 'markdown' directory one level up, in the
main 'Docs' directory. main 'docs' directory.
Here are some of the important files: Here are some of the important files:
- index.html:
If you just want to read the documentation, open this file in
your browser, and start exploring! This file links to all the
other user documents. All the user documents are listed below as
well, as *.markdown files.
- markdown/pymoose2walkthrough.markdown:
"Getting started with python scripting for MOOSE"
- markdown/MooseGuiDocs.markdown: - markdown/MooseGuiDocs.markdown:
"MOOSEGUI: Graphical interface for MOOSE" "MOOSEGUI: Graphical interface for MOOSE"
- markdown/Nkit2Documentation.markdown:
"Neuronal simulations in MOOSEGUI". THIS IS CURRENTLY NOT INCLUDED
- markdown/Kkit12Documentation.markdown: - markdown/Kkit12Documentation.markdown:
"Kinetikit 12: Interface for chemical kinetic models in MOOSEGUI" "Kinetikit 12: Interface for chemical kinetic models in MOOSEGUI"
- markdown/RdesigneurDocumentation:markdown: - markdown/RdesigneurDocumentation:markdown:
"Reaction Diffusion and Electrical SIGnaling in NEURons):Interface "Reaction Diffusion and Electrical SIGnaling in NEURons):Interface
to the multiscale modeling capabilities in MOOSE" to the multiscale modeling capabilities in MOOSE"
- markdown/moosebuiltindocs.markdown: - markdown/Nkit2Documentation.markdown:
"MOOSE class and function documentation" "Neuronal simulations in MOOSEGUI". THIS IS CURRENTLY NOT INCLUDED
This file is auto-generated by the 'py/digestbuiltindocs.py'
Python script (see below). - snippets/snippets.rst:
- py/digestbuiltindocs.py: This Python script compiles all the inline A diverse collection of snippets: (mostly) short code examples illustrating different features of MOOSE
documentation for MOOSE classes and functions, as visible in the - tutorials/tutorials.rst:
MOOSE Python module, into a Markdown text file. THIS IS CURRENTLY A set of tutorials for teaching a range of topics, including integrate-and-fire networks, chemical bistables, and oscillators.
BROKEN. Has stand-alone graphics and the Python scripts are meant to tinker with.
- py/create_rest_doc.py: This Python script compiles all the inline - py/create_rest_doc.py: This Python script compiles all the inline
documentation for MOOSE classes and functions, as visible in the documentation for MOOSE classes and functions, as visible in the
MOOSE Python module, into a reST text file. MOOSE Python module, into a reST text file.
......
docs/user/markdown/moosebuiltindocs.markdown deleted 100644 → 0
+ 0
− 7862
View file @ ff37cca1
source diff could not be displayed: it is too large. Options to address this: view the blob.
docs/user/markdown/pymoose2walkthrough.markdown deleted 100644 → 0
+ 0
− 714
View file @ ff37cca1
% Getting started with python scripting for MOOSE
% Subhasis Ray
% December 12, 2012
# Introduction
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
[here](./MooseGuiDocs.html). The example code in the boxes can be
entered in a Python shell.
# Importing MOOSE and accessing built-in documentation
In a python script you import modules to access the functionalities
they provide.
~~~~{.python}
import moose
~~~~
This makes 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:
~~~~{.python}
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.
~~~~{.python}
help(moose.connect)
~~~~
To list the available functions and classes you can use `dir`
function[^1].
~~~~{.python}
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.
~~~~{.python}
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.
~~~~{.python}
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.
# 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.
~~~~{.python}
moose.le()
~~~~
This shows something like:
~~~~{.python}
Elements under /
/Msgs
/clock
/classes
~~~~
`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`.
Entering:
~~~~{.python}
moose.le('/clock')
~~~~
prints:
~~~~{.python}
Elements under /clock
/clock/tick[0]
~~~~
Now let us create some objects of our own. This can be done by
invoking MOOSE class constructors (just like regular Python
classes).
~~~~{.python}
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`:
~~~~{.python}
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.
~~~~{.python}
print soma.path
~~~~
shows you its path:
~~~~{.python}
/model/soma
~~~~
The name of the element can be printed, too.
~~~~{.python}
print soma.name
~~~~
shows:
~~~~{.python}
soma
~~~~
The `Compartment` elements model small portions 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.
~~~~{.python}
pulse = moose.PulseGen('/model/pulse')
~~~~
You can use `le` at any point to see what is there:
~~~~{.python}
moose.le('/model')
~~~~
will show you:
~~~~{.python}
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:
~~~~{.python}
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.
# 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:
~~~~{.python}
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:
~~~~{.python}
('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:
----
![**Passive neuronal compartment**](../../images/neuronalcompartment.jpg)
----
The fields are populated with some defaults.
~~~~{.python}
print soma.Cm, soma.Rm, soma.Vm, soma.Em, soma.initVm
~~~~
will give you:
~~~~{.python}
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].
~~~~{.python}
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:
~~~~{.python}
moose.showfield(soma)
~~~~
will list most of the fields with their values:
~~~~{.c}
[ /model/soma ]
diameter = 0.0
linearSize = 1
localNumField = 0
Ra = 1.0
y0 = 0.0
Rm = 10000000.0
inject = 0.0
Em = -0.06
initVm = -0.07
x = 0.0
path = /model/soma
x0 = 0.0
z0 = 0.0
class = Compartment
name = soma
Cm = 1e-09
Vm = -0.06
length = 0.0
Im = 0.0
y = 0.0
lastDimension = 0
z = 0.0
~~~~{.python}
Now we can setup the current pulse to be delivered to the soma:
~~~~{.python}
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.
# 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:
~~~~{.python}
moose.getFieldNames('PulseGen', 'srcFinfo')
~~~~
This form has the advantage that you can get information about a
class without creating elements of that class. The above code
shows:
~~~~{.python}
('childMsg', 'outputOut')
~~~~
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:
~~~~{.python}
moose.doc('PulseGen.outputOut')
~~~~
shows:
~~~~{.python}
PulseGen.outputOut: 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.
~~~~{.python}
soma.getFieldNames('destFinfo')
~~~~
shows:
~~~~{.python}
('parentMsg',
'set_this',
'get_this',
...
'set_z',
'get_z',
'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:
~~~~{.python}
m = moose.connect(pulse, 'outputOut', soma, 'injectMsg')
~~~~
`connect(source, source_field, dest, dest_field)` creates a
`message` from `source` element's `source_field` field to `dest`
elements `dest_field` field and returns that message. Messages are
also elements. You can print them to see their identity:
~~~~{.python}
print m
~~~~
on my system gives:
~~~~{.python}
<moose.SingleMsg: id=5, dataId=733, path=/Msgs/singleMsg[733]>
~~~~
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:
~~~~{.python}
print m.e1.path, m.e2.path, m.srcFieldsOnE1, m.destFieldsOnE2
~~~~
will confirm what you already know:
~~~~{.python}
/model/pulse /model/soma ('outputOut',) ('injectMsg',)
~~~~
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:
~~~~{.python}
print soma.neighbours['injectMsg']
~~~~
shows:
~~~~{.python}
[<moose.ematrix: class=PulseGen, id=729,path=/model/pulse>]
~~~~
Notice that the list contains something called ematrix. We discuss
this [later](#some-more-details). Also `neighbours` 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.
~~~~{.python}
moose.connect(vmtab, 'requestData', soma, 'get_Vm')
~~~~
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 `requestData` is a `srcFinfo` acting like a
reply card. This mode of obtaining data is called *pull*
mode.[^3]
# Scheduling and running the simulation
With the model all set up, we have to schedule the simulation.
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. We
initialize the ticks and set their `dt` values using the `setClock`
function.
~~~~{.python}
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`.
So to assign tick #2 to the table for recording `Vm`, we pass its
whole path to the `useClock` function.
~~~~{.python}
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:
~~~~{.python}
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`.
~~~~{.python}
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.
Once the elements are assigned ticks, we can put the model to its
initial state using:
~~~~{.python}
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:
~~~~{.python}
print soma.Vm
~~~~
gives:
~~~~{.python}
-0.07
~~~~
Finally, we run the simulation for 300 ms:
~~~~{.python}
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 `vec`. So you
can easily plot the membrane potential using the
[matplotlib](http://matplotlib.org/) library.
~~~~{.python}
import pylab
t = pylab.linspace(0, 300e-3, len(vmtab.vec))
pylab.plot(t, vmtab.vec)
pylab.show()
~~~~
The first line imports the pylab submodule from matplotlib. This
useful for interactive plotting. The second line creates the time
points to match our simulation time and length of the recorded
data. The third line plots the `Vm` and the fourth line makes it
visible. Does the plot match your expectation?
# Some more details
## `ematrix`, `melement` and `element`
MOOSE elements are instances of the class `melement`.
`Compartment`, `PulseGen` and other MOOSE classes are derived
classes of `melement`. All `melement` instances are contained in
array-like structures called `ematrix`. Each `ematrix` object has a
numerical `id_` field uniquely identifying it. An `ematrix` can
have one or more elements. You can create an array of elements:
~~~~{.python}
comp_array = moose.ematrix('/model/comp', (3,), 'Compartment')
~~~~
This tells MOOSE to create an `ematrix` of 3 `Compartment` elements
with path `/model/comp`. For `ematrix` objects with multiple
elements, the index in the `ematrix` is part of the element path.
~~~~{.python}
print comp_array.path, type(comp_array)
~~~~
shows that `comp_array` is an instance of `ematrix` class. You can
loop through the elements in an `ematrix` like a Python list:
~~~~{.python}
for comp in comp_array:
print comp.path, type(comp)
~~~~
shows:
~~~~{.python}
/model/comp[0] <type 'moose.melement'>
/model/comp[1] <type 'moose.melement'>
/model/comp[2] <type 'moose.melement'>
~~~~
Thus elements are instances of class `melement`. All elements in an
`ematrix` share the `id_` of the `ematrix` 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:
~~~~{.python}
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
`Demos/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` `get_XYZ` that can be used for reading the value at run
time. If `XYZ` is writable then there will also be `destFinfo` to
set it: `set_XYZ`. Example: `Compartment.Rm`
- **`lookupFinfo`** :
lookup tables. These fields act like Python dictionaries but
iteration is not supported. Example: `Neutral.neighbours`.
- **`srcFinfo`** :
source of a message. Example: `PulseGen.outputOut`.
- **`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`.
# Moving on
Now you know the basics of pymoose and how to access the help
system. 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](http://www.genesis-sim.org/GENESIS/Hyperdoc/Manual.html)
is still a good source for documentation on classes that have been
ported from GENESIS.
In addition, the `Demos/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 `Demos` directory to see some more complex models.
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. Finally
you can join the
[moose mailing list](https://lists.sourceforge.net/lists/listinfo/moose-generic)
and request for help.
[^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.
docs/user/snippets_tutorial/Building_Simple_Reaction_Model.html deleted 100644 → 0
+ 0
− 588
View file @ ff37cca1
source diff could not be displayed: it is too large. Options to address this: view the blob.
docs/user/snippets_tutorial/Makefile deleted 100644 → 0
+ 0
− 153
View file @ ff37cca1
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = _build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
clean:
-rm -rf $(BUILDDIR)/*
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/MOOSE.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/MOOSE.qhc"
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/MOOSE"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/MOOSE"
@echo "# devhelp"
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
man:
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
texinfo:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
info:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
gettext:
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."
docs/user/snippets_tutorial/SteadyState.html deleted 100644 → 0
+ 0
− 919
View file @ ff37cca1
source diff could not be displayed: it is too large. Options to address this: view the blob.
docs/user/snippets_tutorial/_templates/layout.html deleted 100644 → 0
+ 0
− 33
View file @ ff37cca1
{% extends "!layout.html" %}
{% block rootrellink %}
<li><a href="http://moose.ncbs.res.in/">MOOSE Homepage</a> &raquo;</li>
{{ super() }}
{% endblock %}
{% block sidebartitle %}
{% if logo and theme_logo_only %}
<a href="http://moose.ncbs.res.in">
{% else %}
<a href="http://moose.ncbs.res.in/" class="icon icon-home"> {{ project }}
{% endif %}
{% if logo %}
{# Not strictly valid HTML, but it's the only way to display/scale it properly, without weird scripting or heaps of work #}
<img src="{{ pathto('_static/' + logo, 1) }}" class="logo" />
{% endif %}
</a>
{% if theme_display_version %}
{%- set nav_version = version %}
{% if READTHEDOCS and current_version %}
{%- set nav_version = current_version %}
{% endif %}
{% if nav_version %}
<div class="version">
{{ nav_version }}
</div>
{% endif %}
{% endif %}
{% include "searchbox.html" %}
{% endblock %}
docs/user/snippets_tutorial/conf.py deleted 100644 → 0
+ 0
− 250
View file @ ff37cca1
# -*- coding: utf-8 -*-
#
# MOOSE documentation build configuration file, created by
# sphinx-quickstart on Tue Jul 1 19:05:47 2014.
#
# 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.
import sys, os
# 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('../../moose/moose-core/python'))
sys.path.append(os.path.abspath('../../../../moose-examples/snippets'))
# -- 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.viewcode',
'numpydoc']
# 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'2016'
# 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 = '3.2'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# 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 = True
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# 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 = 'better'
# 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 = [better_theme_path]
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> 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'
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# 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 <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'MOOSEdoc'
# -- Options for LaTeX output --------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'MOOSE.tex', u'MOOSE Documentation',
u'Upinder Bhalla, Aviral Goel and Harsha Rani', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
latex_logo = '../images/moose_logo.png'
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
latex_show_pagerefs = True
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
latex_domain_indices = True
# -- Options for manual page output --------------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'moose', u'MOOSE Documentation',
[u'Upinder Bhalla, Aviral Goel and Harsha Rani'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output ------------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'MOOSE', u'MOOSE Documentation',
u'Upinder Bhalla, Aviral Goel and Harsha Rani', 'MOOSE', 'MOOSE is the Multiscale Object-Oriented Simulation Environment.',
'Science'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
#numpydoc option
numpydoc_show_class_members = True
docs/user/snippets_tutorial/index.rst deleted 100644 → 0
+ 0
− 16
View file @ ff37cca1
.. MOOSE documentation master file, created by
sphinx-quickstart on Tue Feb 2 14:05:47 2016.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Snippets and Tutorials for MOOSE
==================================
Snippets and Tutorials for MOOSE
.. toctree::
:maxdepth: 2
:numbered:
snippet
tutorial
docs/user/snippets_tutorial/snippet.rst deleted 100644 → 0
+ 0
− 66
View file @ ff37cca1
.. A snippets for MOOSE
.. Lists all the snippets in moose-examples/snippets directory
MOOSE Snippet
==============
The MOOSE Snippet contains examples showing you how to do specific
tasks in MOOSE.
Scripting Parser
----------------
Class features
--------------
Network Models
--------------
Single Neuron Models
---------------------
Some salient properties of neuronal building blocks in MOOSE are described below.
Signaling Pathways
------------------
This section show some of the chemical signaling pathways related settings
Define a kinetic model using the scripting in moose
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. automodule:: scriptKineticModel
:members:
Set up of kinetic solver
^^^^^^^^^^^^^^^^^^^^^^^^
.. automodule:: scriptKineticSolver
:members:
Multi scale models
-------------------
3-D graphics
-------------
Load-Run-Saving pre-existing model files
----------------------------------------
This section of the documentation explains how to load-run-save predefined models in MOOSE.
Load Kinetics Models
^^^^^^^^^^^^^^^^^^^^^
.. automodule:: loadKineticModel
:members:
Load SBML Models
^^^^^^^^^^^^^^^^^
.. automodule:: loadSbmlmodel
:members:
Load Cspace Models
^^^^^^^^^^^^^^^^^^^
.. automodule:: loadCspaceModel
:members:
Save Models to Sbml format
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. automodule:: convert_Genesis2Sbml
:members:
docs/user/snippets_tutorial/tutorial.rst deleted 100644 → 0
+ 0
− 37
View file @ ff37cca1
.. A tutorials for MOOSE
.. This tutorials walks through some of the simple and practical approch related to MOOSE
Audience
This reference has been prepared for the beginners to help them understand the basic to advanced concepts related to MOOSE.
This tutorial walks through a range of topics, including integrate-and-fire networks, chemical bistables, and oscillators.
Has stand-alone graphics and the Python scripts are meant to tinker with.
MOOSE Tutorial
==============
This reference has prepared for the users to help them understand from the basic to complex modeling building in MOOSE
Chemical Signalling Models
^^^^^^^^^^^^^^^^^^^^^^^^^^
`Load Kinetic Model <loadKineticModel.html>`_
----------------------------------------------
`Deterministic Simulation <DeterministicSolver.html>`_
----------------------------------------------------------------
`Stochastic Simulation <StochasticSolver.html>`_
-----------------------------------------------------------
`Finding Steady State <SteadyState.html>`_
-------------------------------------------------
`Building Simple Reaction Model <Building_Simple_Reaction_Model.html>`_
------------------------------------------------------------------------------
Building of Electical Signalling Models
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Building Chemical-Electrical Signalling Models using Rdesigneur
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment