From 2af833a02ab1ad4d1e9caf12efe7705e73fb2c32 Mon Sep 17 00:00:00 2001 From: Dilawar Singh Date: Sun, 26 Jun 2016 09:51:41 +0530 Subject: [PATCH] Squashed 'moose-core/' changes from 1318029..a15a538 a15a538 Merge pull request #131 from dilawar/master 1800283 Merge branch 'master' of github.com:dilawar/moose-core 2ad812f Rdesigeur by sarthak, 8e87707 Fixed the streamer test. e62ec09 Merge remote-tracking branch 'bhallalab/master' 002edb6 Fix to BhallaLab/moose-core#130. d7ebbe7 No need to have header name in inverted commas. 414a8d9 stimulustable is check and some more correction 343a08a First version of model merging pools and reaction are done 943f96f clean up in notes field f2b71f5 Merge branch 'master' of http://github.com/BhallaLab/moose-core c742934 kkitUtil: check to see if the color goes beyond genesis color Sequence, _main.py: eliminated enzyme cplx pool to genesis under compartment 9aca1c1 Merge pull request #128 from dilawar/master 322093e Streamer uses name of the table whenever possible. 5be9eb4 Added getName, setName to table. If these are set, use them in Streamer class to write the header of csv file. f9178d2 Merge branch 'master' of github.com:BhallaLab/moose-core 3d420b0 species concentration/amount is calculated depending on the hasOnlySubstanceUnit flag 9188681 Merge branch 'master' of github.com:BhallaLab/moose-core cf3d4f8 Merge branch 'master' of github.com:dilawar/moose-core 4d98756 Write path without [0] in streamer numpy table instead of table name. 9b143e4 reaction and enzyme are added with the ratelaw b2fbc15 Merge branch 'master' of http://github.com/BhallaLab/moose-core 0a765fb Rules are added 07a68b9 If -Wno-unused-but-set-variable is supported by compiler, enable it. d98241c Merge branch 'master' of github.com:BhallaLab/moose-core d22bfea Moved Doc from here to BhallaLab/moose . In docs folder. 9f18f0a Merge pull request #125 from dilawar/master a942a4c Fixed the failed build on travis https://travis-ci.org/BhallaLab/moose-core/jobs/134133078 3d6a8cc Added support to float and double to numpy format. Fixed some documentation about Streamer, correct dt is docstring. More assert statements in streamer test script. aada8c4 Merge branch 'master' of github.com:BhallaLab/moose-core 303ad71 Changes for gcc4.4. on nargis. 1af4a69 Temporary change before switching to another branch. 0018c55 notes are written for species 895766a species added a7e9509 paremeter and compartment info is read back to moose 2b9076e update with more details 170739f Put some more utility inside namespace moose. When writing numpy format, do not write whole path in header. Just name would do. f01727c Merge remote-tracking branch 'bhallalab/master' 7e95a6d A fix to failing unit-tests. When user writes /compt/a/b, inside MOOSE it is represented as /compt[0]/a[0]/b[0] which could be annoying for Streamer user. Just remove [0]. For other [n], don't do anything. 21fe695 Bringing back some changed undone by bad merge strategy. This should now pass on travis. ca8d55b Merge branch 'master' of https://github.com/BhallaLab/moose-core c165976 Fixes issue dilawar/moose-core#3 (#123) c17df70 clean up in filename while writing into SBML db701fc Enzyme's are written 320b0c3 Function and reaction are written a8bfc7c compartment and species are written 008e25e moose Annotation like runtime,dts and plots are written 3ba5e33 units are written bcfa3c7 Merge branch 'master' of http://github.com/BhallaLab/moose-core d3b3789 firstphase of write file 4418691 For cmake, enable the c++11 support on compiler which supports it. This should fix ">>" to "> >" error in template parameters in boost code which is only supported in cmake build system. dc9d0c3 Merge branch 'master' of http://github.com/BhallaLab/moose-core 156e762 python readSBML file 2786757 Fixed #124. Not using gsl_rng in global rng. It is not working as expected in class RNG. Using Subha's mtrand() when boost or c++11 is not available. eecc171 Adding a small print statement about why assert failed in rdesigneur. 6454673 Merge branch 'master' of github.com:BhallaLab/moose-core 270f1d6 Fixed #112. Not using gsl_rng in global rng. It is not working as expected in class RNG. Using Subha's mtrand() when boost or c++11 is not available. 738d9dc Fixed issue #124. Adding the issue #124 file to repo for reference. Can't reproduce the error with latest commit (this and previous one). cc85cfb Update README.md af178bf This fixes the missing time column in streamer. dilawar/moose-core#3. 9faf02e Don't rewrite the table path before writing them to csv in header. dilawar/moose-core#3. 806f6a1 Checks if not of tables added are more than 0 or not. If zero, then disable the streamer. Notify the user. Issue dilawar/moose-core#3 0a93eaa Importing so that it passes with legacy makefiles as well. 4dc2a6c Merge branch 'master' of https://github.com/BhallaLab/moose-core 56fdc36 Fixes to issue #116 (#120) 357b1b5 Fixed the test script. Method rk4 is not good enough when using boost. Use rk5a. 8057a8f Generate h5 name using tmpnam. If tests are run by two different users on the same system, there won't be any issue with permissions. However this makes testing bit harder during development. b01caf4 Fixes to gcc-5.x on Ubuntu-16.04. fc98bfc Adding random library to link flags. ceea4f0 Use RNG object rather than pointer. Can't figure out why pointer did not work well. ea5529d FIxed -std=c++11 error. 014175d Fixed issue #116. Using real_distribution instead of int_distribution. Let the library take care of scaling to between 0 and 1. ab91625 Merge branch 'master' of github.com:BhallaLab/moose-core e23c827 Some temporary changes before merging. I forgot what there are. Probably RNG initialization is changed. cf73c1f Update of python setup file. (#118) 51bcf63 Disabled part of code which checks for extension . On some platform it reutrns x86_64.so etc, which probably we don't want. In any case, if build fails on open build service, we can bring it back #78. fb558d8 Modifying SBML_LIBRARY related macros. Since libsbml is now distributed from mosoe repo as well. 487587b test scripts points to directory commited by @subha #issue #94. e47a492 Update INSTALL.md 13afeaf Update README.md 8b33ae5 Merge branch 'master' of github.com:BhallaLab/moose-core 1268296 Merge branch 'master' of github.com:BhallaLab/moose-core 808ae94 Update INSTALL.md 6316820 Update INSTALL.md 2522f47 Merge branch 'master' of github.com:dilawar/moose-core 3f13efd Temp commit. 347e5b0 Update INSTALL.md d14e4e8 moved to appropriate doc folder. 5a48285 CheckMOOSECompiler -> CheckCXXCompiler. 5ecd06e Updated INSTALL.md file. 0c42d28 Merge remote-tracking branch 'bhallalab/master' 87c193d Deleted cymoose from master branch. e77361c Fixed moose building after moving _moose target to subdirectory. af97ec3 Cymoose remains only in my personal clone branch cymoose. Removing it from master branch. b3542f6 Cleaned up Cmakefile. 7fec36b Moved pymoose target to its own directory. 7575c55 Update test_ksolve.py 904e32a Added missing cmake file. 1998e27 Using ptr instead of object of RNG. 1ee1427 Added ksolve test. fbf9d90 Test script for ksolve is modified. Total 40 pools. 2ea5ed1 Separate file to check compiler macro. c7d3e15 Removed the copy constrcutor from RNG class. 1acec97 GssaVoxelPools gets its won random number generator. Had to remove constantness of a function to be able to use uniform( ) or rng call. 08fa1ed test display is changed a bit. Removed some hanging c++11 auto . c6bc8c3 Printing tests name during tests. 4116cc5 More verbose output when tests are runnug. Added a macro which runs test. d1c77ce Replaced simple assert( doubleEq(a, b) ) with ASSERT_DOUBLE_EQ( "", a, b ); git-subtree-dir: moose-core git-subtree-split: a15a538e22f0cd62de95532c2932156055d58673 --- CMakeLists.txt | 66 +- CheckCXXCompiler.cmake | 9 + CheckMooseCompiler.cmake | 36 - Docs/README.txt | 18 - Docs/config/epydoc.cfg | 152 - Docs/developer/API.txt | 215 - Docs/developer/BuildingNewMOOSEClasses.txt | 32 - Docs/developer/CodingConventions.txt | 32 - Docs/developer/DesignDocument | 778 - Docs/developer/Ksolve.txt | 101 - Docs/developer/MessageObjectLookup.txt | 23 - Docs/developer/PortingOldMooseObjects.txt | 36 - Docs/developer/PythonRecommendations.org | 135 - Docs/developer/ReduceOperations | 154 - Docs/developer/Scheduling.txt | 145 - Docs/developer/doxygen-API.cpp | 408 - Docs/developer/doxygen-design-document.cpp | 50 - Docs/developer/doxygen-main.cpp | 48 - Docs/developer/doxygen-programmers-guide.cpp | 277 - Docs/developer/hsolve-developer-overview.cpp | 208 - Docs/developer/hsolve-implementation.cpp | 156 - Docs/developer/parameter_fitting.cpp | 120 - Docs/developer/profiling.cpp | 135 - Docs/developer/setget.txt | 112 - Docs/developer/the-messaging-system.cpp | 171 - Docs/doxygen/Doxyfile | 2411 -- Docs/doxygen/doxy_1.4.6/Doxyfile | 1237 - Docs/doxygen/doxy_1.4.6/Doxyfile.full | 1237 - Docs/doxygen/doxy_1.4.6/Doxyfile.intermediate | 1237 - Docs/doxygen/doxy_1.4.6/Doxyfile.minimal | 1237 - Docs/doxygen/doxy_1.4.6/docgen | 13 - Docs/generate-documentation | 14 - Docs/images/Addgraph.png | Bin 1614 -> 0 bytes Docs/images/BufPool.png | Bin 1600 -> 0 bytes Docs/images/Chemical.png | Bin 31833 -> 0 bytes Docs/images/ChemicalSignallingEditor.png | Bin 56788 -> 0 bytes Docs/images/Chemical_run.png | Bin 52680 -> 0 bytes Docs/images/CompartmentalEditor.png | Bin 290239 -> 0 bytes Docs/images/Electrical_sim.png | Bin 32881 -> 0 bytes Docs/images/Electrical_vis.png | Bin 35686 -> 0 bytes Docs/images/Gallery_Moose_Multiscale.png | Bin 46966 -> 0 bytes Docs/images/KkitModelWindow.png | Bin 56788 -> 0 bytes Docs/images/KkitPlotWindow.png | Bin 106613 -> 0 bytes Docs/images/KkitPoolIcon.png | Bin 2262 -> 0 bytes Docs/images/KkitReacIcon.png | Bin 544 -> 0 bytes Docs/images/KkitReaction.png | Bin 9280 -> 0 bytes Docs/images/KkitSumTotal.png | Bin 8330 -> 0 bytes Docs/images/MM_EnzIcon.png | Bin 1195 -> 0 bytes Docs/images/MM_EnzReac.png | Bin 8975 -> 0 bytes Docs/images/MOOSE_MPI_threading.gif | Bin 19368 -> 0 bytes Docs/images/MOOSE_threading.gif | Bin 12217 -> 0 bytes Docs/images/MassActionEnzIcon.png | Bin 1353 -> 0 bytes Docs/images/MassActionEnzReac.png | Bin 11279 -> 0 bytes Docs/images/MatPlotLibConfigureSubplots.png | Bin 1818 -> 0 bytes Docs/images/MatPlotLibDoUndo.png | Bin 1586 -> 0 bytes Docs/images/MatPlotLibHomeIcon.png | Bin 1132 -> 0 bytes Docs/images/MatPlotLibPan.png | Bin 719 -> 0 bytes Docs/images/MatPlotLibSave.png | Bin 1066 -> 0 bytes Docs/images/MatPlotLibZoom.png | Bin 987 -> 0 bytes Docs/images/Moose1.png | Bin 98137 -> 0 bytes Docs/images/MooseGuiImage.png | Bin 226406 -> 0 bytes Docs/images/MooseGuiMenuImage.png | Bin 4844 -> 0 bytes Docs/images/Moose_Run.png | Bin 104520 -> 0 bytes Docs/images/Moose_edit.png | Bin 117902 -> 0 bytes Docs/images/NeurokitEditor.png | Bin 470612 -> 0 bytes Docs/images/NeurokitRunner.png | Bin 333780 -> 0 bytes Docs/images/NkitModelWindow.png | Bin 104335 -> 0 bytes Docs/images/PlotConfig.png | Bin 19347 -> 0 bytes Docs/images/PlotWindowIcons.png | Bin 9833 -> 0 bytes Docs/images/Pool.png | Bin 1604 -> 0 bytes Docs/images/PropertyEditor.png | Bin 22716 -> 0 bytes Docs/images/RunView.png | Bin 153721 -> 0 bytes Docs/images/SimulationControl.png | Bin 9336 -> 0 bytes Docs/images/chemDoseResponse.png | Bin 21011 -> 0 bytes Docs/images/chemical_CS.png | Bin 51343 -> 0 bytes Docs/images/classIcon/BufPool.png | Bin 1600 -> 0 bytes Docs/images/classIcon/CubeMesh.png | Bin 590 -> 0 bytes Docs/images/classIcon/CylMesh.png | Bin 740 -> 0 bytes Docs/images/classIcon/Enz.png | Bin 891 -> 0 bytes Docs/images/classIcon/FuncPool.png | Bin 597 -> 0 bytes Docs/images/classIcon/Function.png | Bin 597 -> 0 bytes Docs/images/classIcon/MMenz.png | Bin 937 -> 0 bytes Docs/images/classIcon/Pool.png | Bin 1604 -> 0 bytes Docs/images/classIcon/Reac.png | Bin 544 -> 0 bytes Docs/images/classIcon/StimulusTable.png | Bin 2194 -> 0 bytes Docs/images/classIcon/SumFunc.png | Bin 986 -> 0 bytes Docs/images/clone.png | Bin 370 -> 0 bytes Docs/images/delete.png | Bin 290 -> 0 bytes Docs/images/delgraph.png | Bin 1556 -> 0 bytes Docs/images/func.png | Bin 6195 -> 0 bytes Docs/images/function.png | Bin 61469 -> 0 bytes Docs/images/grid.png | Bin 1008 -> 0 bytes Docs/images/moose_logo.png | Bin 9133 -> 0 bytes Docs/images/move.png | Bin 316 -> 0 bytes Docs/images/neuronalcompartment.jpg | Bin 13583 -> 0 bytes Docs/images/neuroncompartment.fig | 369 - Docs/images/neuroncompartment.png | Bin 8912 -> 0 bytes Docs/images/plot.png | Bin 363 -> 0 bytes Docs/images/pythonshell.png | Bin 48129 -> 0 bytes Docs/images/randomSpike.png | Bin 37086 -> 0 bytes Docs/images/rdes2_passive_squid.png | Bin 24466 -> 0 bytes Docs/images/rdes3_squid.png | Bin 32746 -> 0 bytes Docs/images/rdes4_osc.png | Bin 45131 -> 0 bytes Docs/images/rdes5_reacdiff.png | Bin 128778 -> 0 bytes Docs/images/rdes6_multiscale.png | Bin 38438 -> 0 bytes Docs/images/rdes7_passive.png | Bin 34227 -> 0 bytes Docs/images/rdes8_active.png | Bin 66315 -> 0 bytes Docs/images/rdes9_spiny_active.png | Bin 185033 -> 0 bytes Docs/images/reacDiffBranchingNeuron.png | Bin 19551 -> 0 bytes Docs/images/squid_demo.png | Bin 54290 -> 0 bytes Docs/images/testWigglySpines3.png | Bin 209769 -> 0 bytes Docs/images/tweakingParameters.png | Bin 48501 -> 0 bytes Docs/images/twoCells.png | Bin 26365 -> 0 bytes Docs/markdown/README.html | 613 - Docs/markdown/README.markdown | 152 - Docs/markdown/build | 9 - Docs/markdown/css/stylesheet.css | 121 - Docs/markdown/images/purkinje.png | Bin 142428 -> 0 bytes Docs/user/GUI/Kkit12Documentation.rst | 491 - Docs/user/GUI/Makefile | 153 - Docs/user/GUI/MooseGuiDocs.rst | 256 - Docs/user/GUI/RdesigneurDocumentation.rst | 801 - Docs/user/GUI/_templates/layout.html | 27 - Docs/user/GUI/conf.py | 249 - Docs/user/GUI/index.rst | 21 - Docs/user/README.txt | 52 - Docs/user/build | 49 - Docs/user/html/Kkit12Documentation.html | 311 - Docs/user/html/MooseGuiDocs.html | 167 - Docs/user/html/Nkit2Documentation.html | 119 - Docs/user/html/css/moosebuiltindocs.css | 16 - Docs/user/html/css/moosedocs.css | 163 - Docs/user/html/moosebuiltindocs.html | 24939 ---------------- .../html/moosebuiltindocs.html.REMOVED.git-id | 1 - .../user/html/pymoose/_static/ajax-loader.gif | Bin 673 -> 0 bytes Docs/user/html/pymoose/_static/basic.css | 540 - .../html/pymoose/_static/comment-bright.png | Bin 3500 -> 0 bytes .../html/pymoose/_static/comment-close.png | Bin 3578 -> 0 bytes Docs/user/html/pymoose/_static/comment.png | Bin 3445 -> 0 bytes Docs/user/html/pymoose/_static/default.css | 256 - Docs/user/html/pymoose/_static/doctools.js | 247 - .../html/pymoose/_static/down-pressed.png | Bin 368 -> 0 bytes Docs/user/html/pymoose/_static/down.png | Bin 363 -> 0 bytes Docs/user/html/pymoose/_static/file.png | Bin 392 -> 0 bytes Docs/user/html/pymoose/_static/jquery.js | 9404 ------ Docs/user/html/pymoose/_static/minus.png | Bin 199 -> 0 bytes Docs/user/html/pymoose/_static/plus.png | Bin 199 -> 0 bytes Docs/user/html/pymoose/_static/pygments.css | 62 - Docs/user/html/pymoose/_static/searchtools.js | 567 - Docs/user/html/pymoose/_static/sidebar.js | 151 - Docs/user/html/pymoose/_static/underscore.js | 1226 - Docs/user/html/pymoose/_static/up-pressed.png | Bin 372 -> 0 bytes Docs/user/html/pymoose/_static/up.png | Bin 363 -> 0 bytes Docs/user/html/pymoose/_static/websupport.js | 808 - Docs/user/html/pymoose/genindex.html | 8413 ------ Docs/user/html/pymoose/index.html | 145 - Docs/user/html/pymoose/moose_builtins.html | 889 - Docs/user/html/pymoose/moose_classes.html | 11794 -------- .../pymoose/moose_classes.html.REMOVED.git-id | 1 - Docs/user/html/pymoose/objects.inv | Bin 21527 -> 0 bytes Docs/user/html/pymoose/py-modindex.html | 116 - Docs/user/html/pymoose/search.html | 110 - Docs/user/html/pymoose/searchindex.js | 1 - Docs/user/html/pymoose2walkthrough.html | 282 - Docs/user/index.html | 27 - .../markdown/Kkit12Documentation.markdown | 283 - Docs/user/markdown/MooseGuiDocs.markdown | 150 - .../user/markdown/Nkit2Documentation.markdown | 215 - .../markdown/RdesigneurDocumentation.markdown | 702 - Docs/user/markdown/index.markdown | 12 - Docs/user/markdown/markdown2rst.py | 14 - Docs/user/markdown/moosebuiltindocs.markdown | 7862 ----- .../moosebuiltindocs.markdown.REMOVED.git-id | 1 - .../markdown/pymoose2walkthrough.markdown | 714 - Docs/user/py/Makefile | 153 - Docs/user/py/README.txt | 29 - Docs/user/py/_templates/layout.html | 33 - Docs/user/py/conf.py | 257 - Docs/user/py/create_all_rstdoc.py | 277 - Docs/user/py/index.rst | 41 - Docs/user/py/make.bat | 190 - Docs/user/py/moose_builtins.rst | 24 - Docs/user/py/moose_classes.rst | 10149 ------- Docs/user/py/moose_cookbook.rst | 688 - Docs/user/py/moose_quickstart.rst | 684 - .../Building_Simple_Reaction_Model.html | 588 - Docs/user/snippets_tutorial/Makefile | 153 - Docs/user/snippets_tutorial/SteadyState.html | 919 - .../snippets_tutorial/_templates/layout.html | 33 - Docs/user/snippets_tutorial/conf.py | 250 - Docs/user/snippets_tutorial/index.rst | 16 - Docs/user/snippets_tutorial/snippet.rst | 66 - Docs/user/snippets_tutorial/tutorial.rst | 37 - INSTALL.md | 4 - Makefile | 4 +- README.md | 146 +- basecode/Makefile | 4 +- basecode/global.cpp | 29 +- basecode/global.h | 3 +- biophysics/MarkovChannel.cpp | 3 + builtins/Streamer.cpp | 86 +- builtins/Streamer.h | 3 +- builtins/StreamerBase.cpp | 5 +- builtins/Table.cpp | 23 +- builtins/Table.h | 5 +- builtins/testNSDF.cpp | 5 +- ksolve/GssaVoxelPools.cpp | 30 +- ksolve/GssaVoxelPools.h | 2 +- ksolve/Makefile | 5 +- ksolve/NonLinearSystem.h | 332 - ksolve/VoxelPools.cpp | 10 +- ksolve/VoxelPoolsBase.cpp | 8 +- pymoose/CMakeLists.txt | 15 +- pymoose/moosemodule.cpp | 2 +- python/moose/SBML/__init__.py | 4 + python/moose/SBML/readSBML.py | 643 + python/moose/SBML/writeSBML.py | 734 + python/moose/genesis/_main.py | 100 +- python/moose/merge.py | 247 + python/rdesigneur/rdesigneur.py | 227 +- python/rdesigneur/rdesigneurProtos.py | 2 +- randnum/RNG.h | 77 +- scheduling/Clock.cpp | 22 +- scripts/{setup_subha.py => setup.cygwin.py} | 0 shell/Shell.cpp | 18 +- tests/issues/issue_124.py | 32 + tests/issues/issue_93.py | 5 + tests/python/test_ksolve.py | 4 - tests/python/test_streamer.py | 16 +- utility/cnpy.cpp | 25 +- utility/cnpy.hpp | 26 +- utility/print_function.hpp | 26 +- utility/setupenv.cpp | 130 +- utility/testing_macros.hpp | 14 +- utility/utility.h | 24 +- 235 files changed, 2350 insertions(+), 100411 deletions(-) delete mode 100644 CheckMooseCompiler.cmake delete mode 100644 Docs/README.txt delete mode 100644 Docs/config/epydoc.cfg delete mode 100644 Docs/developer/API.txt delete mode 100644 Docs/developer/BuildingNewMOOSEClasses.txt delete mode 100644 Docs/developer/CodingConventions.txt delete mode 100644 Docs/developer/DesignDocument delete mode 100644 Docs/developer/Ksolve.txt delete mode 100644 Docs/developer/MessageObjectLookup.txt delete mode 100644 Docs/developer/PortingOldMooseObjects.txt delete mode 100644 Docs/developer/PythonRecommendations.org delete mode 100644 Docs/developer/ReduceOperations delete mode 100644 Docs/developer/Scheduling.txt delete mode 100644 Docs/developer/doxygen-API.cpp delete mode 100644 Docs/developer/doxygen-design-document.cpp delete mode 100644 Docs/developer/doxygen-main.cpp delete mode 100644 Docs/developer/doxygen-programmers-guide.cpp delete mode 100644 Docs/developer/hsolve-developer-overview.cpp delete mode 100644 Docs/developer/hsolve-implementation.cpp delete mode 100644 Docs/developer/parameter_fitting.cpp delete mode 100644 Docs/developer/profiling.cpp delete mode 100644 Docs/developer/setget.txt delete mode 100644 Docs/developer/the-messaging-system.cpp delete mode 100644 Docs/doxygen/Doxyfile delete mode 100644 Docs/doxygen/doxy_1.4.6/Doxyfile delete mode 100644 Docs/doxygen/doxy_1.4.6/Doxyfile.full delete mode 100644 Docs/doxygen/doxy_1.4.6/Doxyfile.intermediate delete mode 100644 Docs/doxygen/doxy_1.4.6/Doxyfile.minimal delete mode 100755 Docs/doxygen/doxy_1.4.6/docgen delete mode 100755 Docs/generate-documentation delete mode 100644 Docs/images/Addgraph.png delete mode 100644 Docs/images/BufPool.png delete mode 100644 Docs/images/Chemical.png delete mode 100644 Docs/images/ChemicalSignallingEditor.png delete mode 100644 Docs/images/Chemical_run.png delete mode 100644 Docs/images/CompartmentalEditor.png delete mode 100644 Docs/images/Electrical_sim.png delete mode 100644 Docs/images/Electrical_vis.png delete mode 100644 Docs/images/Gallery_Moose_Multiscale.png delete mode 100644 Docs/images/KkitModelWindow.png delete mode 100644 Docs/images/KkitPlotWindow.png delete mode 100644 Docs/images/KkitPoolIcon.png delete mode 100644 Docs/images/KkitReacIcon.png delete mode 100644 Docs/images/KkitReaction.png delete mode 100644 Docs/images/KkitSumTotal.png delete mode 100644 Docs/images/MM_EnzIcon.png delete mode 100644 Docs/images/MM_EnzReac.png delete mode 100644 Docs/images/MOOSE_MPI_threading.gif delete mode 100644 Docs/images/MOOSE_threading.gif delete mode 100644 Docs/images/MassActionEnzIcon.png delete mode 100644 Docs/images/MassActionEnzReac.png delete mode 100644 Docs/images/MatPlotLibConfigureSubplots.png delete mode 100644 Docs/images/MatPlotLibDoUndo.png delete mode 100644 Docs/images/MatPlotLibHomeIcon.png delete mode 100644 Docs/images/MatPlotLibPan.png delete mode 100644 Docs/images/MatPlotLibSave.png delete mode 100644 Docs/images/MatPlotLibZoom.png delete mode 100644 Docs/images/Moose1.png delete mode 100644 Docs/images/MooseGuiImage.png delete mode 100644 Docs/images/MooseGuiMenuImage.png delete mode 100644 Docs/images/Moose_Run.png delete mode 100644 Docs/images/Moose_edit.png delete mode 100644 Docs/images/NeurokitEditor.png delete mode 100644 Docs/images/NeurokitRunner.png delete mode 100644 Docs/images/NkitModelWindow.png delete mode 100644 Docs/images/PlotConfig.png delete mode 100644 Docs/images/PlotWindowIcons.png delete mode 100644 Docs/images/Pool.png delete mode 100644 Docs/images/PropertyEditor.png delete mode 100644 Docs/images/RunView.png delete mode 100644 Docs/images/SimulationControl.png delete mode 100644 Docs/images/chemDoseResponse.png delete mode 100644 Docs/images/chemical_CS.png delete mode 100644 Docs/images/classIcon/BufPool.png delete mode 100644 Docs/images/classIcon/CubeMesh.png delete mode 100644 Docs/images/classIcon/CylMesh.png delete mode 100644 Docs/images/classIcon/Enz.png delete mode 100644 Docs/images/classIcon/FuncPool.png delete mode 100644 Docs/images/classIcon/Function.png delete mode 100644 Docs/images/classIcon/MMenz.png delete mode 100644 Docs/images/classIcon/Pool.png delete mode 100644 Docs/images/classIcon/Reac.png delete mode 100644 Docs/images/classIcon/StimulusTable.png delete mode 100644 Docs/images/classIcon/SumFunc.png delete mode 100644 Docs/images/clone.png delete mode 100644 Docs/images/delete.png delete mode 100644 Docs/images/delgraph.png delete mode 100644 Docs/images/func.png delete mode 100644 Docs/images/function.png delete mode 100644 Docs/images/grid.png delete mode 100644 Docs/images/moose_logo.png delete mode 100644 Docs/images/move.png delete mode 100644 Docs/images/neuronalcompartment.jpg delete mode 100644 Docs/images/neuroncompartment.fig delete mode 100644 Docs/images/neuroncompartment.png delete mode 100644 Docs/images/plot.png delete mode 100644 Docs/images/pythonshell.png delete mode 100644 Docs/images/randomSpike.png delete mode 100644 Docs/images/rdes2_passive_squid.png delete mode 100644 Docs/images/rdes3_squid.png delete mode 100644 Docs/images/rdes4_osc.png delete mode 100644 Docs/images/rdes5_reacdiff.png delete mode 100644 Docs/images/rdes6_multiscale.png delete mode 100644 Docs/images/rdes7_passive.png delete mode 100644 Docs/images/rdes8_active.png delete mode 100644 Docs/images/rdes9_spiny_active.png delete mode 100644 Docs/images/reacDiffBranchingNeuron.png delete mode 100644 Docs/images/squid_demo.png delete mode 100644 Docs/images/testWigglySpines3.png delete mode 100644 Docs/images/tweakingParameters.png delete mode 100644 Docs/images/twoCells.png delete mode 100644 Docs/markdown/README.html delete mode 100644 Docs/markdown/README.markdown delete mode 100755 Docs/markdown/build delete mode 100644 Docs/markdown/css/stylesheet.css delete mode 100644 Docs/markdown/images/purkinje.png delete mode 100644 Docs/user/GUI/Kkit12Documentation.rst delete mode 100644 Docs/user/GUI/Makefile delete mode 100644 Docs/user/GUI/MooseGuiDocs.rst delete mode 100644 Docs/user/GUI/RdesigneurDocumentation.rst delete mode 100644 Docs/user/GUI/_templates/layout.html delete mode 100644 Docs/user/GUI/conf.py delete mode 100644 Docs/user/GUI/index.rst delete mode 100644 Docs/user/README.txt delete mode 100755 Docs/user/build delete mode 100644 Docs/user/html/Kkit12Documentation.html delete mode 100644 Docs/user/html/MooseGuiDocs.html delete mode 100644 Docs/user/html/Nkit2Documentation.html delete mode 100644 Docs/user/html/css/moosebuiltindocs.css delete mode 100644 Docs/user/html/css/moosedocs.css delete mode 100644 Docs/user/html/moosebuiltindocs.html delete mode 100644 Docs/user/html/moosebuiltindocs.html.REMOVED.git-id delete mode 100644 Docs/user/html/pymoose/_static/ajax-loader.gif delete mode 100644 Docs/user/html/pymoose/_static/basic.css delete mode 100644 Docs/user/html/pymoose/_static/comment-bright.png delete mode 100644 Docs/user/html/pymoose/_static/comment-close.png delete mode 100644 Docs/user/html/pymoose/_static/comment.png delete mode 100644 Docs/user/html/pymoose/_static/default.css delete mode 100644 Docs/user/html/pymoose/_static/doctools.js delete mode 100644 Docs/user/html/pymoose/_static/down-pressed.png delete mode 100644 Docs/user/html/pymoose/_static/down.png delete mode 100644 Docs/user/html/pymoose/_static/file.png delete mode 100644 Docs/user/html/pymoose/_static/jquery.js delete mode 100644 Docs/user/html/pymoose/_static/minus.png delete mode 100644 Docs/user/html/pymoose/_static/plus.png delete mode 100644 Docs/user/html/pymoose/_static/pygments.css delete mode 100644 Docs/user/html/pymoose/_static/searchtools.js delete mode 100644 Docs/user/html/pymoose/_static/sidebar.js delete mode 100644 Docs/user/html/pymoose/_static/underscore.js delete mode 100644 Docs/user/html/pymoose/_static/up-pressed.png delete mode 100644 Docs/user/html/pymoose/_static/up.png delete mode 100644 Docs/user/html/pymoose/_static/websupport.js delete mode 100644 Docs/user/html/pymoose/genindex.html delete mode 100644 Docs/user/html/pymoose/index.html delete mode 100644 Docs/user/html/pymoose/moose_builtins.html delete mode 100644 Docs/user/html/pymoose/moose_classes.html delete mode 100644 Docs/user/html/pymoose/moose_classes.html.REMOVED.git-id delete mode 100644 Docs/user/html/pymoose/objects.inv delete mode 100644 Docs/user/html/pymoose/py-modindex.html delete mode 100644 Docs/user/html/pymoose/search.html delete mode 100644 Docs/user/html/pymoose/searchindex.js delete mode 100644 Docs/user/html/pymoose2walkthrough.html delete mode 100644 Docs/user/index.html delete mode 100644 Docs/user/markdown/Kkit12Documentation.markdown delete mode 100644 Docs/user/markdown/MooseGuiDocs.markdown delete mode 100644 Docs/user/markdown/Nkit2Documentation.markdown delete mode 100644 Docs/user/markdown/RdesigneurDocumentation.markdown delete mode 100644 Docs/user/markdown/index.markdown delete mode 100644 Docs/user/markdown/markdown2rst.py delete mode 100644 Docs/user/markdown/moosebuiltindocs.markdown delete mode 100644 Docs/user/markdown/moosebuiltindocs.markdown.REMOVED.git-id delete mode 100644 Docs/user/markdown/pymoose2walkthrough.markdown delete mode 100644 Docs/user/py/Makefile delete mode 100644 Docs/user/py/README.txt delete mode 100644 Docs/user/py/_templates/layout.html delete mode 100644 Docs/user/py/conf.py delete mode 100644 Docs/user/py/create_all_rstdoc.py delete mode 100644 Docs/user/py/index.rst delete mode 100644 Docs/user/py/make.bat delete mode 100644 Docs/user/py/moose_builtins.rst delete mode 100644 Docs/user/py/moose_classes.rst delete mode 100644 Docs/user/py/moose_cookbook.rst delete mode 100644 Docs/user/py/moose_quickstart.rst delete mode 100644 Docs/user/snippets_tutorial/Building_Simple_Reaction_Model.html delete mode 100644 Docs/user/snippets_tutorial/Makefile delete mode 100644 Docs/user/snippets_tutorial/SteadyState.html delete mode 100644 Docs/user/snippets_tutorial/_templates/layout.html delete mode 100644 Docs/user/snippets_tutorial/conf.py delete mode 100644 Docs/user/snippets_tutorial/index.rst delete mode 100644 Docs/user/snippets_tutorial/snippet.rst delete mode 100644 Docs/user/snippets_tutorial/tutorial.rst delete mode 100644 ksolve/NonLinearSystem.h create mode 100755 python/moose/SBML/__init__.py create mode 100644 python/moose/SBML/readSBML.py create mode 100644 python/moose/SBML/writeSBML.py create mode 100644 python/moose/merge.py rename scripts/{setup_subha.py => setup.cygwin.py} (100%) create mode 100644 tests/issues/issue_124.py diff --git a/CMakeLists.txt b/CMakeLists.txt index 755309c6..ae7a4e03 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -72,7 +72,6 @@ endif() ################################ CMAKE OPTIONS ################################## -option(WITH_DOC "Build documentation using python-sphinx and doxygen" OFF) option(VERBOSITY "Set MOOSE verbosity level (deprecated)" 0) ## Unit testing and debug mode. option(DEBUG "Build with debug support" OFF) @@ -201,10 +200,6 @@ if(LIBSBML_FOUND) find_package(LibXML2 REQUIRED) endif() include_directories(${LibXML2_INCLUDE_DIRS}) - if(${LIBSBML_LIBRARY_DIRS}) - target_link_libraries(libmoose PROPERTIES LINK_FLAGS "-L${LIBSBML_LIBRARY_DIRS}") - endif() - else() message( "======================================================================\n" @@ -267,23 +262,17 @@ if(WITH_GSL) # top level. include_directories( ${GSL_INCLUDE_DIRS} ) elseif(WITH_BOOST) - find_package(Boost 1.44 COMPONENTS filesystem REQUIRED) + find_package(Boost 1.44 COMPONENTS filesystem random REQUIRED) find_package( LAPACK REQUIRED ) add_definitions( -DUSE_BOOST -UUSE_GSL ) include_directories( ${Boost_INCLUDE_DIRS} ) - # check_include_file_cxx( - # ${Boost_INCLUDE_DIRS}/boost/random/random_device.hpp - # BOOST_RANDOM_DEVICE_EXISTS - # ) - # if(BOOST_RANDOM_DEVICE_EXISTS) - # add_definitions(-DBOOST_RANDOM_DEVICE_EXISTS) - # endif(BOOST_RANDOM_DEVICE_EXISTS) - # check_include_file_cxx( - # ${Boost_INCLUDE_DIRS}/boost/filesystem.hpp BOOST_FILESYSTEM_EXISTS - # ) - # if(BOOST_FILESYSTEM_EXISTS) - # add_definitions( -DBOOST_FILESYSTEM_EXISTS ) - # endif(BOOST_FILESYSTEM_EXISTS) + check_include_file_cxx( + ${Boost_INCLUDE_DIRS}/boost/random/random_device.hpp + BOOST_RANDOM_DEVICE_EXISTS + ) + if(BOOST_RANDOM_DEVICE_EXISTS) + add_definitions(-DBOOST_RANDOM_DEVICE_EXISTS) + endif(BOOST_RANDOM_DEVICE_EXISTS) endif() ## Setup hdf5 @@ -513,42 +502,14 @@ if(CMAKE_VERSION VERSION_LESS "2.8.0") target_link_libraries(moose.bin PUBLIC moose) ELSE() target_link_libraries(moose.bin LINK_PUBLIC moose) - if(LIBSBML_FOUND) - target_link_libraries(moose.bin LINK_PUBLIC ${LIBSBML_LIBRARIES}) - endif(LIBSBML_FOUND) ENDIF() -if(WITH_DOC) - FIND_PACKAGE(Doxygen REQUIRED) - add_custom_command(TARGET libmoose POST_BUILD - COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.full - WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} - COMMENT "Building developer documentation" - VERBATIM - ) -endif(WITH_DOC) - ######################### BUILD PYMOOSE ######################################## # Root of all python module. if(WITH_PYTHON) add_subdirectory( pymoose ) endif(WITH_PYTHON) -## Moose documentation -option(WITH_DOC "Build documentation using python-sphinx and doxygen" OFF) -if(WITH_DOC) - FIND_PACKAGE(Sphinx REQUIRED) - message(STATUS "Build documentation.") - set(USER_DOC_OUTPUT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Docs/user/py/_build/html) - set(DEVELOPER_DOC_OUTPUT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Docs/developer/html) - ADD_CUSTOM_TARGET(docs ALL - COMMAND ./docgen - WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} - COMMENT "Generating html doc using sphinx and doxygen" - ) - -endif(WITH_DOC) - ######################### INSTALL ############################################## install(TARGETS moose.bin @@ -575,17 +536,6 @@ if(WITH_PYTHON) endif(WITH_PYTHON) -if(WITH_DOC) - message(STATUS "Installing moose doc") - install(DIRECTORY ${USER_DOC_OUTPUT_DIR} - DESTINATION share/doc/moose - ) - - install(DIRECTORY ${DEVELOPER_DOC_OUTPUT_DIR} - DESTINATION share/doc/moose/developer - ) -endif() - # Print message to start build process if(${CMAKE_BUILD_TOOL} MATCHES "make") message( diff --git a/CheckCXXCompiler.cmake b/CheckCXXCompiler.cmake index dcab851b..7fddd1d2 100644 --- a/CheckCXXCompiler.cmake +++ b/CheckCXXCompiler.cmake @@ -5,6 +5,8 @@ CHECK_CXX_COMPILER_FLAG( "-std=c++11" COMPILER_SUPPORTS_CXX11 ) CHECK_CXX_COMPILER_FLAG( "-std=c++0x" COMPILER_SUPPORTS_CXX0X ) CHECK_CXX_COMPILER_FLAG( "-Wno-strict-aliasing" COMPILER_WARNS_STRICT_ALIASING ) + + # Turn warning to error: Not all of the options may be supported on all # versions of compilers. be careful here. add_definitions(-Wall @@ -18,6 +20,13 @@ if(COMPILER_WARNS_STRICT_ALIASING) add_definitions( -Wno-strict-aliasing ) endif(COMPILER_WARNS_STRICT_ALIASING) +# Disable some harmless warnings. +CHECK_CXX_COMPILER_FLAG( "-Wno-unused-but-set-variable" + COMPILER_SUPPORT_UNUSED_BUT_SET_VARIABLE_NO_WARN + ) +if(COMPILER_SUPPORT_UNUSED_BUT_SET_VARIABLE_NO_WARN) + add_definitions( "-Wno-unused-but-set-variable" ) +endif(COMPILER_SUPPORT_UNUSED_BUT_SET_VARIABLE_NO_WARN) if(COMPILER_SUPPORTS_CXX11) message(STATUS "Your compiler supports c++11 features. Enabling it") diff --git a/CheckMooseCompiler.cmake b/CheckMooseCompiler.cmake deleted file mode 100644 index dcab851b..00000000 --- a/CheckMooseCompiler.cmake +++ /dev/null @@ -1,36 +0,0 @@ -########################### COMPILER MACROS ##################################### - -include(CheckCXXCompilerFlag) -CHECK_CXX_COMPILER_FLAG( "-std=c++11" COMPILER_SUPPORTS_CXX11 ) -CHECK_CXX_COMPILER_FLAG( "-std=c++0x" COMPILER_SUPPORTS_CXX0X ) -CHECK_CXX_COMPILER_FLAG( "-Wno-strict-aliasing" COMPILER_WARNS_STRICT_ALIASING ) - -# Turn warning to error: Not all of the options may be supported on all -# versions of compilers. be careful here. -add_definitions(-Wall - #-Wno-return-type-c-linkage - -Wno-unused-variable - -Wno-unused-function - #-Wno-unused-private-field - ) -add_definitions(-fPIC) -if(COMPILER_WARNS_STRICT_ALIASING) - add_definitions( -Wno-strict-aliasing ) -endif(COMPILER_WARNS_STRICT_ALIASING) - - -if(COMPILER_SUPPORTS_CXX11) - message(STATUS "Your compiler supports c++11 features. Enabling it") - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") - add_definitions( -DENABLE_CPP11 ) -elseif(COMPILER_SUPPORTS_CXX0X) - message(STATUS "Your compiler supports c++0x features. Enabling it") - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x") - add_definitions( -DENABLE_CXX11 ) - add_definitions( -DBOOST_NO_CXX11_SCOPED_ENUMS -DBOOST_NO_SCOPED_ENUMS ) -else() - add_definitions( -DBOOST_NO_CXX11_SCOPED_ENUMS -DBOOST_NO_SCOPED_ENUMS ) - message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support.") -endif() - - diff --git a/Docs/README.txt b/Docs/README.txt deleted file mode 100644 index fe534860..00000000 --- a/Docs/README.txt +++ /dev/null @@ -1,18 +0,0 @@ -This is the MOOSE documentation directory. The documentation is grouped into -the following directories: - - - user: This is for anyone wishing to learn/use MOOSE. - This part of the documentation is encoded in Markdown format. - - developer: If you wish to learn about MOOSE code, go here. - - doxygen: Source code documentation generation. - - markdown: This contains a quick introduction to Markdown itself. - - images: These are images that are included in the user and developer - documentation. - --------------------------------------------------------------------------------- -N.B.: This text file has Windows-style line endings (CR/LF) for easy -viewing in Windows. We will try to keep the other text files here -Windows-compatible (e.g.: *.markdown files), but we may slip. -If you have difficulty viewing them in Notepad, try the inbuilt Wordpad -editor, or better still, download a good text editor like Notepad++ or Geany. --------------------------------------------------------------------------------- diff --git a/Docs/config/epydoc.cfg b/Docs/config/epydoc.cfg deleted file mode 100644 index 4bd20f4b..00000000 --- a/Docs/config/epydoc.cfg +++ /dev/null @@ -1,152 +0,0 @@ -[epydoc] # Epydoc section marker (required by ConfigParser) - -# The list of objects to document. Objects can be named using -# dotted names, module filenames, or package directory names. -# Alases for this option include "objects" and "values". -modules: python/libmumbl - , python/moose - , python/rdesigneur - , gui - -# The type of output that should be generated. Should be one -# of: html, text, latex, dvi, ps, pdf. -output: html - -# The path to the output directory. May be relative or absolute. -#target: Docs/developer/epydoc -target: docs - -# An integer indicating how verbose epydoc should be. The default -# value is 0; negative values will supress warnings and errors; -# positive values will give more verbose output. -verbosity: 10 - -# A boolean value indicating that Epydoc should show a traceback -# in case of unexpected error. By default don't show tracebacks -debug: 1 - -# If True, don't try to use colors or cursor control when doing -# textual output. The default False assumes a rich text prompt -simple-term: 0 - - -### Generation options - -# The default markup language for docstrings, for modules that do -# not define __docformat__. Defaults to epytext. -docformat: epytext - -# Whether or not parsing should be used to examine objects. -parse: yes - -# Whether or not introspection should be used to examine objects. -introspect: yes - -# Don't examine in any way the modules whose dotted name match this -# regular expression pattern. -#exclude - -# Don't perform introspection on the modules whose dotted name match this -# regular expression pattern. -#exclude-introspect - -# Don't perform parsing on the modules whose dotted name match this -# regular expression pattern. -#exclude-parse - -# The format for showing inheritance objects. -# It should be one of: 'grouped', 'listed', 'included'. -inheritance: listed - -# Whether or not to include private variables. (Even if included, -# private variables will be hidden by default.) -private: yes - -# Whether or not to list each module's imports. -imports: yes - -# Whether or not to include syntax highlighted source code in -# the output (HTML only). -sourcecode: yes - -# Whether or not to include a page with Epydoc log, containing -# effective option at the time of generation and the reported logs. -include-log: no - - -### Output options - -# The documented project's name. -name: PyMOOSE - -# The CSS stylesheet for HTML output. Can be the name of a builtin -# stylesheet, or the name of a file. -css: white - -# The documented project's URL. -#url: http://some.project/ - -# HTML code for the project link in the navigation bar. If left -# unspecified, the project link will be generated based on the -# project's name and URL. -link: PyMOOSE Documentation - -# The "top" page for the documentation. Can be a URL, the name -# of a module or class, or one of the special names "trees.html", -# "indices.html", or "help.html" -#top: os.path - -# An alternative help file. The named file should contain the -# body of an HTML file; navigation bars will be added to it. -#help: my_helpfile.html - -# Whether or not to include a frames-based table of contents. -frames: yes - -# Whether each class should be listed in its own section when -# generating LaTeX or PDF output. -separate-classes: no - - -### API linking options - -# Define a new API document. A new interpreted text role -# will be created -#external-api: epydoc - -# Use the records in this file to resolve objects in the API named NAME. -#external-api-file: epydoc:api-objects.txt - -# Use this URL prefix to configure the string returned for external API. -#external-api-root: epydoc:http://epydoc.sourceforge.net/api - - -### Graph options - -# The list of graph types that should be automatically included -# in the output. Graphs are generated using the Graphviz "dot" -# executable. Graph types include: "classtree", "callgraph", -# "umlclasstree". Use "all" to include all graph types -graph: all - -# The path to the Graphviz "dot" executable, used to generate -# graphs. -# dotpath: /usr/local/bin/dot - -# The name of one or more pstat files (generated by the profile -# or hotshot module). These are used to generate call graphs. -pstat: profile.out - -# Specify the font used to generate Graphviz graphs. -# (e.g., helvetica or times). -graph-font: Helvetica - -# Specify the font size used to generate Graphviz graphs. -graph-font-size: 10 - - -### Return value options - -# The condition upon which Epydoc should exit with a non-zero -# exit status. Possible values are error, warning, docstring_warning -#fail-on: error diff --git a/Docs/developer/API.txt b/Docs/developer/API.txt deleted file mode 100644 index 5dddd83a..00000000 --- a/Docs/developer/API.txt +++ /dev/null @@ -1,215 +0,0 @@ -API for Python interface. - -1. Key data structures, not accessed directly, but important for concepts: - - Element: Managers for objects. This includes data, messaging, - field info and class info. All Elements can be arrays. - - Finfo: Field information specifiers, used to build up the MOOSE - interface to the underlying C++ class. Similar to the old MOOSE. - Major Subclasses: - - DestFinfo: used for functions of the Object. Can be called - either using SetGet::set or by messages. - - SrcFinfo: Used to call messages. - - ValueFinfo: Used to define fields. The ReadOnly kind has - just the 'get' function, whereas the normal kind - also has a 'set' function. Both 'get' and 'set' are - implemented as DestFinfos. - - Cinfo: Class information specifier, used to specify class name, - inheritance, and manage the array of Finfos. - - Msg: Messages. Many subclasses. Handle communication between Elements. - All Msgs are between precisely two Elements. So the Elements are nodes - and the Msgs are edges. Msg have a lot of variety in how they control - data transfer between individual array entries within the source and - destination Element. Data transfer can be bidirectional. - All Msgs provide a handle to an Element called a MsgManager, which - allows you to inspect the Msg fields and in some cases modify them. - But you cannot modify the source and destination Elements. - -2. Key data structures that you will access. - -Id: Handle to Elements. -DataId: Handle to objects on Elements. Has a data part and a field part. - The data part is the parent object, and is used for any array Element. - The field part is for array fields within individual data entries, - in cases where the array fields themselves are accessed like Elements. - For example, in an IntFire neuron, you could have an - array of a million IntFire neurons on Element A, and each IntFire - neuron might have a random individual number, say, 10000, 15000, 8000, - etc Synapses. To index Synapse 234 on IntFire 999999 you would use a - DataId( 999999, 234). - -ObjId: Composite of Id and DataId. Allows you to uniquely identify any entity - in the simulation. - - -3. Field assignments and function calls: - File: SetGet.h - This has a series of templates for different argument cases. - 1. If you want to call a function foo( int A, double B ) on - ObjId oid, you would do: - - SetGet2< int, double >::set( oid, "foo", A, B ); - - 2. To call a function bar( int A, double B, string C ) on oid: - SetGet3< int, double, string >::set( oid, "bar", A, B, C ); - - 3. To assign a field value "short abc" on object oid: - Field< short >::set( oid, "abc", 123 ); - - 4. To get a field value "double pqr" on object obj: - double x = Field< short >::get( oid, "pqr" ); - - 5. To assign the double 'xcoord' field on all the objects on - element Id id, which has an array of the objects: - vector< double > newXcoord; - // Fill up the vector here. - Field< double >::setVec( id, "xcoord", newXcoord ); - 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: - SetGet1< double >::setVec( id, "xcoord_func", newXcoord ); - - 6. To extract the double vector 'ycoord' field from all the - objects on id: - vector< double > oldYcoord; // Do not need to allocate. - Field< double >::getVec( id, "ycoord", oldYcoord ); - - 7. To set/get LookupFields, that is fields which have an index - to lookup: - double x = LookupField< unsigned int, double >::get( objId, field, index ); - LookupField< unsigned int, double >::set( objId, field, index, value ); - - There are lots of other variants here. - -4. Shell commands to use: the ones that start with 'do'. - -Id doCreate( string type, Id parent, string name, - vector< unsigned int > dimensions ); - -bool doDelete( Id id ) - -MsgId doAddMsg( const string& msgType, - ObjId src, const string& srcField, - ObjId dest, const string& destField); - -void doQuit(); - -void doStart( double runtime ); - -void doNonBlockingStart( double runtime ); - -void doReinit(); - -void doStop(); - -void doTerminate(); - -void doMove( Id orig, Id newParent ); - -Id doCopyId orig, Id newParent, string newName, - unsigned int n, bool copyExtMsgs); - -Id doFind( const string& path ) const - -void doSetClock( unsigned int tickNum, double dt ) - -void doUseClock( string path, string field, unsigned int tick ); - -Id doLoadModel( const string& fname, const string& modelpath ); - -void doSyncDataHandler( Id elm, const string& sizeField, Id tgt ); - - -5. Important fields of important objects. - -5.1. Shell object. This is the root object, '/' or '/root'. -This has the following fields of note: - - bool isRunning: ReadOnlyValue - - Id cwe: Regular value. - -5.2 Neutral. These fields are shared by all objects. - string name - ObjId parent // Parent ObjId. Note this is fully - // specified, including index. - vector< Id > children // All child elements. - string path // Full path - string className - unsigned int linearSize // Product of all dimensions - // Currently not working. - vector< unsigned int> Dimensions - unsigned int fieldDimension // Size of field dimension. - vector< ObjId > msgOut // MsgManagers of all outgoing msgs - vector< ObjId > msgIn // MsgManagers of all incoming msgs - vector< Id > msgSrc( string field ) // Ids of source msgs into field - vector< Id > msgDest( string field ) // Ids of dest msgs into field - -5.3 Class Info objects. These are located in /classes/ - string docs // currently not implemented - string baseClass // Name of base class - -5.4 Field Info objects. These are children of the respective ClassInfo and - are located in /classes// - There are 5 field categories: - srcFinfo - destFinfo - valueFinfo - lookupFinfo - sharedFinfo - Each of these is an array, indexed as DataId( 0, ) - since they are FieldElements. - You can query the # of entries in each category using - Id classId( "/classes/" ); - numValueFinfos = - Field< unsigned int >::get( classId, "num_valueFinfo" ); - - Finally each of the field categories has the following fields: - string name - string docs // This is implemented - string type // String with argument types separated by - // commas. Can handle basic types, Ids, - // ObjIds, DataIds, strings, and vectors of - // any of the above. - vector< string > src // vector of subsidiary srcFinfos, which - // happens in SharedFinfos. - vector< string > dest // vector of subsidiary destFinfos, which - // happens in SharedFinfos and ValueFinfos. - - - -6. Message traversal, C++ level: -General approach: - - If you just want src/dest Id, use the Neutral or Element functions - to find list of source or target Ids as per spec. - - Netural::msgSrc( string field ); - - Netural::msgDest( string field ); - - Element::getOutputs( vector< Id >& ret, const SrcFinfo* finfo) - - Element::getInputs( vector< Id >& ret, const DestFinfo* finfo) - - - If you want to iterate through specific array and/or field - entries in src/dest Id, then you will have to look up the - MsgIds themselves. - - vector< ObjId > Neutral::msgOut(): - Not very specific, just the ObjIds of the MsgManagers - of all outgoing Msgs. - - vector< ObjId > Neutral::msgIn(): - All ObjIds of MsgManagers of incoming Msgs. - - MsgId Element::findCaller( FuncId fid ) const: - Looks up the first Msg that calls the specified Fid - - Element::getInputMsgs( vector< MsgId >& caller, FuncId fid) - Fills up vector of MsgIds that call the specified fid - - - To convert between MsgIds, Msgs, and the manager ObjId: - - MsgId Msg::mid(): returns the MsgId of the Msg. - - Msg::manager(): returns the manager Eref of a Msg. - - Msg::manager().objId(): returns the manager ObjId of a Msg. - - static const Msg* Msg::getMsg( MsgId mid ) - Returns the Msg ptr given a MsgId. - - - To iterate through Msg targets: - unsigned int Msg::srcToDestPairs( - vector< DataId >& src, vector< DataId >& dest) const - This function gives matching vectors of src and dest - pairs for the Msg. This should be node-independent, - but the SparseMsg currently doesn't handle it right, - and works only on 1 node. - diff --git a/Docs/developer/BuildingNewMOOSEClasses.txt b/Docs/developer/BuildingNewMOOSEClasses.txt deleted file mode 100644 index a1883146..00000000 --- a/Docs/developer/BuildingNewMOOSEClasses.txt +++ /dev/null @@ -1,32 +0,0 @@ -Building new MOOSE classes. - -- Take your existing class. -- Set it up to use access functions of this form: - - For things that should look like Read/Write variables to the user: - void setField( FieldType value ); - FieldType getField() const; - - For things that should look like ReadOnly variables to the user: - FieldType getField() const; - - For things that should look like functions to the user: - ( MOOSE can handle up to 6 arguments ) - void func( Type1 arg1, Type2 arg2 ); - -- Put in the following function in the header: - static const Cinfo* initCinfo(); - - -- Figure out your MOOSE interface. There are three main kinds of fields, - which are going to be set up using Finfo objects (short for Field - Information). - The three are: - - DestFinfos: These handle function requests. - - SrcFinfos: These call functions on other objects. In other - words, they send messages. - - ValueFinfos: These support field assignment and readout. - - -- Define initCinfo() in your .cpp, as follows: - diff --git a/Docs/developer/CodingConventions.txt b/Docs/developer/CodingConventions.txt deleted file mode 100644 index 7e901760..00000000 --- a/Docs/developer/CodingConventions.txt +++ /dev/null @@ -1,32 +0,0 @@ -Naming conventions: -General: Use CamelCase -Don't use underscores as word separators. -Classes start with caps -Fields and functions start with lower case, except for scientific - conventions (e.g., Vm_) in which case the scientific convention is used. -Private fields end with an underscore (e.g., Vm_ ); -Use spaces liberally, and always after a comma. -Field assignment functions (set/get) start with set/get - -Naming of MOOSE fields and functions: -Fields (ValueFinfos): Just use the name of the field, e.g., Vm, x, y, z. -Message sources (SrcFinfos): Use the name of the field, e.g., output, - unless there is a name-clash with a Fields. Then use name - e.g., nOut, xOut, VmOut. - If the message source is to request a return value, generally use the - form request -Message destination (DestFinfos): Use the name of the function, typically a - verb. e.g., increment, process. - Special case comes up with the internal set/get functions of fields, - which are implemented as DestFinfos. Here the DestFinfos are - automatically named set_ and get_ - If the message dest handles a request or other operation as part of - a shared message, generally use the form - handle - If there is an overlap with a SharedMessage or field after applying - all these rules, then use the form handle. -Shared messages (SharedFinfos): Use the name of the message. - If there is an overlap with any other message, the SharedMessage takes - precedence. This is because Shared Messages are the interface users - will normally use. Try to avoid overlaps with field names. - diff --git a/Docs/developer/DesignDocument b/Docs/developer/DesignDocument deleted file mode 100644 index e652b413..00000000 --- a/Docs/developer/DesignDocument +++ /dev/null @@ -1,778 +0,0 @@ -MOOSE redesign for messaging. -Goals: -1. Cleanup. -2. Handle multithreading and MPI from the ground up. - -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. -- There is a split between synchronous messaging (exact amount of data - transferred on every timestep) and asynchronous messaging (variable - amounts of data transferred). This split is at the data transfer - level but the message specification should be nearly the same. -- 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. - - ------------------------------------------------------------------------------- -Control flow. - -Developer design: -Every object being scheduled has to provide a 'process' and a 'reinit' function, -which are set up as a shared message, as per the following interface: - -static DestFinfo process( - "process", "description", new ProcOpFunc< Class>( &Class::process ) ); -static DestFinfo reinit( - "reinit", "description", new ProcOpFunc< Class>( &Class::reinit ) ); -static Finfo* procShared[] = { &process, &reinit }; -static SharedFinfo( "proc", "description", procShared, - sizeof( procShared ) / sizeof( const Finfo* ) ); - -These functions are called specially by the scheduler, and bypass the regular -message queuing system. - -During Reinit, the initial conditions are set and state variables are sent out -(see below). Reinit happens just at the start of the calculation. -During Process, first all pending messages are cleared, then internal updates -happen and data is sent out. Process is repeated once each timestep for each -Element. -Process even within the same timestep, can be strictly ordered by clock tick. -In other words, the messages are handled and the internal updates are done -within one clock tick, before the next is begun. - -Supposing you have two classes A and B. Class A has the state variables of -the calculation, and class B computes rates of change and sends these back. -We need to put these on separate clock ticks. When running, this -is the sequence your classes should follow: - -REINIT: -A reinits and sends out data, typically the state variables. - -PROCESS: -Stage 0: - B handle msgs - B send update -Stage 1: - A handle msgs - A send update. - - - -1. Scheduling. -Shell::start( double runtime ) - Sets up thread stuff - Configures clocks for barriers, threads, etc. - Inits threads with Clock::threadStartFunc - Clock::threadStartFunc - Clock::tStart - Sets up grouping for current thread - TickPtr::advance - Tick::advance on all ticks. - pthread_barrier_wait - On first thread only: Qinfo::mergeQ - Puts local data into InQ - pthread_barrier_wait - Qinfo::readQ: handle msgs in InQ - Call process on all scheduled Elements. - pthread_barrier_wait - sorts TickPtrs. - pthread_exit -join threads -clean up - - -As before, we have a hierarchy of Shell, Clock, and Tick. -The Tick now becomes an ArrayField of the Clock. This means that the clock -can manipulate Ticks directly, which is much easier to understand. However, -Ticks still look like Elements to the rest of the system and have their -own messages to all scheduled objects. -The TickPtr is an intermediate wrapper for Ticks that helps to sort them -efficiently. -The Tick object is the one that connects to and calls operations on target -Elements. -Ticks call the 'process' function on Elements. This bypasses the queueing -system, but uses the regular field definition system. There is a somewhat -specialised OpFunc: ProcOpFunc, which handes type conversions for calls -emerging from Ticks. This is the sequence: -Tick::advance -Iterate over all outgoing Process messages. - call Msg::process( procinfo, fid ) - call e2->process( procinfo, fid ); - call dataHandler->process( p, elm, fid ) - Get the OpFunc corresponding to fid. - cast to ProcOpFuncBase, check. - Scan over the elm array indices - suitable for current thread. - call opFunc->proc( obj, eref, p) - Typecasts obj - calls obj->process( eref, p ) - - -Ticks also call the global Qinfo::readQ() function. This handles all -asynchronous message passing including spike events and setup calls. -The old reinit/reset/resched is gone, it will be a function call triggered -through clearQ. - -2. ASYNCHRONOUS MESSAGING -Async messages work at two levels. First, the developer sees the creation and -calls to messages within MOOSE objects. Second, the data transfer happens -under the surface through queues that span threads and nodes. - -2.1 Data structures used for messages within MOOSE objects. -Messages are called through the static const instances of SrcFinfos. -As described elsewhere, SrcFinfos are initialized along with other Element -fields at static initialization time. -SrcFinfo< T1, T2...>( name, description, slot ); - The slot here is a BindIndex, which looks up which Message and Function - will be called by SrcFinfo::send. - Slot 0 is reserved for parent->child messages - Slot 1 is reserved for element->msgSpec messages - Slots 2 onward are used for data-transfer messages. - For now each data-transfer slot is predefined. - Later, if there is a proliferation of costly slot definitions, it - should be possible to predefine slots only for those SrcFinfos which - need to be executed efficiently. Other slots will have to generate an - entry on the fly. - -2.1.1 Element-level messaging data structures. -The Element carries two messaging data structures: - vector< MsgId > m_; // Handles incoming messages - vector< vector< MsgFuncBinding > > msgBinding_; // Handles outgoing msgs - -The first of these is just to keep track of what comes in to the Element. -The msgBinding_ is indexed by the slot described above, which is of type -BindIndex. Each slot refers to a vector of MsgFuncBinding objects, which are -basically pairs of MsgIds and FuncIds. -When send executes, the code iterates through this vector of MsgFuncBinding -objects, adding each MsgId/FuncId pair into the outgoing queue. - -2.1.2 Shared messages and messages with many distinct target classes/functions -There are often cases where a pair of objects must exchange multiple kinds -of information. When this happens, we want to use a single Msg between the -two, to keep track of the trajectory of the data, but we want to send -many kinds of data along this Msg. - Example 1: when getting a field, the querying object needs to tell - the responder what information to send, and the responder must send - back the field value. This is a single Msg, but different kinds of - data travel in different directions along it in this case. - To accomplish this, the querying object sets up an entry in its - msgBinding_ vector. The responding object in this special case - just puts the other end of the Msg in its m_ vector. - - Execution works as follows: Querying object calls send< FuncId > - where the FuncId identifies the 'get_field' function on the responder. - The get_field function is registered automagically by the Field< T > - field definition as a GetOpFunc. The operation done by this function - is to get the field value, and send it right back along the querying - Msg using somewhat low-level call to Qinfo::addSpecificTargetToQ. - Example 2. A molecule might send a display object both its xyz - coordinates, and also its state. It might do so at different times, - called by different SrcFinfo::send functions. - Here we have more than one kind of data go from the source - to the target object. - - To accomplish this, the two SrcFinfos have distinct slot values, - pointing to distinct msgBinding_ entries. The MsgFuncBindings point - to the same MsgId but distinct FuncIds for the respective SrcFinfos. - Example 3. A molecule sends its conc to a reaction, and the reaction - sends back the change in conc on each timestep. - - This is really a sync message problem. If done using async calls, - the SrcFinfos on either side of the Msg would point to their own - msg slots, each referring to a BindIndex entry. We don't really worry - about what the m_ vector does, it isn't too costly for this to - maintain the Msg at one or both sides of the msg, but it isn't - necessary either. Since the Shared Msg setup will use a single call, - it is not hard to do it efficiently. Since the high-level details of - the Msg are stored in the MsgSpec, we don't worry too much about - traversal either. - -2.2 Calls to messages within MOOSE objects. -To send a message, one just calls - srcFinfoInstance->send( Eref current, ProcInfo p, arg1, arg2 ... ) - - -Scheduling: -clearQ: Manages the event queue for the async messaging. Here are the calls: - -Tick::advance(): // Calls Qinfo::clearQ on the global event queues. -Qinfo::clearQ: marches through the queue, each entry of which identifies the - operative message and hence target Element. Also identifies function - to call, and the arguments. -Msg::exec: specialized for each Msg subclass. Calls func on all target entries. - -Still to do: Sort out flow control to interface threads such as graphics -and console. Presumably these would go through other Jobs. There is some -trickiness in how they fill in queues for the regular objects to clear. - -Functioning: -This is how asynchronous messaging works. -slot s = Slot1< double >(Conn#, InitCinfo()->funcInfo("funcName")); - This slot constructor does an RTTI check on the func type, and if OK, - loads in the funcIndex. If bad, emits warning and stores a safety - function. - Limitation: handling multiple types of targets, whose Functions are - not just inherited variations. e.g., conc -> plot and xview. - To get round it: these are simply distinct Connections. -s->send( Eref e, double arg ); // Uses s to send the data in a typesafe way. - Converts the funcId and argument into a char buffer. -void Eref::asend( Slot s, char* arg, unsigned int size); - //Looks up Conn from Slot, passes it the buffer with funcId and args. -void Conn::asend( funcIndex, char* arg, unsigned int size); - // Goes through all Msgs with buffer. -void Element::addToQ( FuncId funcId, MsgId msgId, const char* arg, unsigned int size ); - Puts MsgId, funcId and data on queue. May select Q based on thread. - Multi-node Element needs a table to look up for MsgId, pointing to - off-node targets for that specific MsgId. At this time it also inserts - data transfer requests to those targets into the postmaster buffers. - Looks up opFunc, which is also an opportunity to do type checking in - case lookup shows a problem. -OpFunc Element::getOpFunc( funcId ); // asks Cinfo for opFunc. -OpFunc cinfo::getOpFunc( funcId ); - -At this point all the info is sitting in the asyncQueue of the target Element. -Eventually the scheduling gets round to calling clearQ as discussed above. - - - -SYNCHRONOUS MESSAGING -Scheduling: -process: Manages synchronous messaging, which is similar to the traditional - GENESIS messaging in that objects transfer fixed amounts of data every - timestep. Here are the calls: -Tick::process(); // Calls Process on targets specified by Conn. -Conn::process( const ProcInfo* p ); // Calls Process on all Msgs. -Msg::process( const ProcInfo* p ); // Calls Process on e1. -Element::process( const ProcInfo* p );// Calls Process on all Data objects. - Partitions among threads. -virtual void Data::process( const ProcInfo* p, Eref e ); - Asks e to look up or sum the incoming data buffers, does computation, - sends out other messages. This involves dumping data directly into - the target sync buffers. Note that the memory locations are fixed - ahead of time and are distinct, so this can be done simultaneously - from multiple threads. - -Functioning: - -Here are the calls that the Elements/Data use to send out data: - - -void ssend1< double >( Eref e, Slot s, double arg ); // Calls Eref::send. -Eref::send1( Slot slot, double arg); // Calls Element::send -Element::send1( Slot slot, unsigned int eIndex, double arg ); - Puts data into buffer: sendBuf_[ slot + i * numSendSlots_ ] = arg; -Note that we assume all sync data transfer is doubles. Probably a good -assumption, may help with data alignment. - -Here are some of the calls that Elements use to examine the dumped data: -double Eref::oneBuf( Slot slot ); - Looks up value in sync buffer at slot: - return *procBuf_[ procBufRange_[ slot + eIndex * numRecvSlots_ ] ]; -double Eref::sumBuf( Slot slot ); - Sums up series of values in sync buffer at slot. Uses similar operation - except that it iterates through the offset variable: - offset = procBufRange_.begin() + slot + i * numRecvSlots_; -double Eref::prdBuf( Slot slot, double v ); - multiples v into series of values in sync buffer at slot, similar - fast iteration through buffer using offset. - -< To clarify: How to set up these buffers when defining messages > - - -SPORADIC FUNCTION CALLS -Case 1: Existing message between Elements, using all targets: -Slot* s = Slot1< double >(...) -s->send( Eref e, [args] ) -Case 2: Message does not exist -bool set< double >( Id tgt, FieldId f, double val ); -bool set< double >( Id tgt, const string& fieldname, double val ); -Both of these functions create a temporary object and add a temporary message. - -Case 3: Message exists, but want to send to a single target: -s->sendTo( Eref me, Id tgt, [args] ); - -============================================================================= -FIELD ACCESS. Updated 18 Apr 2010. -Field and function access is routed through the Shell object, /root. -The Shell is present on all nodes. -For the coder, the field access functions have a templated front-end described - below. This is more efficient than the string interface functions. -For the parser talking to the Shell, the field/func access functions go through - string-ified arguments void doSet( Id, DataId, field, args) and - string doGet( Id, DataId, field ) - -These functions are mediated by the SetGet< Type > class templates. -N can be any number of arguments, from 0 to 5. -Each provides one consistent function: -SetGet1< double >::set( const Eref& dest, const string& field, A arg ) - -For N = 1 we also have the following functions. -SetGet1< double >::strSet( const Eref& dest, const string& field, - const string& val ) -string SetGet1< double >::strGet( const Eref& dest, const string& field ) -SetGet1< double >::setVec( const Eref& dest, const string& field, - const vector< A >& arg ) -We would like to also make a function: -SetGet1< double >::getVec( const Eref& dest, const string& field, - vector< A >& arg ) - -In addition, the Field< Type > template is derived from SetGet1< A > and -is designed to interface with the automatically generated functions for -field access from ValueFinfo: set_ and get_ -It provides type-specific functions: -bool Field< double >::set( const Eref& dest, const string& field, double arg ) -double Field< double >::get( const Eref& dest, const string& field ) - - -Inner functioning. -Set works as follows: - -Func Src Dest Args -Master::innerDispatchSet - requestSet Worker: handleSet Id, DataId, FuncId, - Prepacked Buffer -Worker::handleSet - lowLevelSet Target::set_field None: hacks in the data. - ack Master::handleAck - - ------------- -Get works as follows. - -Func Src Dest Args -Master::innerDispatchGet - requestGet Worker::handleGet Id, DataId, FuncId - -Worker::handleGet on non_tgt node - ack Master::handleAck -Worker::handleGet on tgt node - lowLevelGet Target::get_field:: Eref, buf - GetOpFunc - -Target::get_field::GetOpFunc::fieldOp - Hacked func Worker::recvGet node, status, - to add directly from RetFunc PrepackedBuffer - into Q - -Worker::recvGet - Puts the data into the buffer - calls handleAck to complete the operation. - -Field access is set up using ValueFinfo and its variants. -ValueFinfo: uses - setFunc of form void ( T::*setFunc )( F ) - getFunc of form F ( T::*getFunc )() const -to access fields. Wraps these functions into OpFunc1 and GetOpFunc. Generates -functions named "set_" + fieldname and "get_" + fieldname for the Finfo array. - -ReadOnlyValueFinfo: Similar, only doesn't use the setFunc. - - -Internals for SetGet access to fields. -Sets: -1. DestFinfos provide templated functions with different types and # of args. - SetGet< ArgTypes >::set( const Eref& dest, const string& field, Args) - This munges the arguments into a char* array. -2. Shell::innerSet( Eref, funcId, val, size ) (taking over SetGet::iSetInner) - This creates a message to the target Eref:Finfo, and passes the data. - This message is predefined - - Not deleted/recreated for different targets, just changes - the target - - Avoid running up the MsgIds for this Msg. It is always the - same on all nodes. - - Avoid having different nodes end up with different MsgIds - due to creation on local node. - 2.1 When running on multiple nodes, this first sends out the data - to all workers and the owner of the target object has to deal with it. - 2.2 The owner shell then passes back an ack to the master node. -3. The target function sends back an ack to the calling Shell? Need this to - ensure serial operation. But it will mess up Destfinfos. - -Gets: -1. ValueFinfos provide the proper combination of a handler and a return - function that sends the return value back. - Field< Type > currently handles the return op, not sure why. - Type Field< Type >::get just passes data on to the Shell::innerGet -2. Shell::innerGet( Eref, DataId, requestFid, handleFid, field ) - replaces SetGet::iGet in doing field validation, setting up msgs, - and sending request. Now it polls till the return comes in. -3. Shell::handleGet deals with the return value, just bunging it into a buffer - on the Shell object. We don't know yet what the type is. -4. Shell::innerGet again, having waited till the data came home. Passes - data back to the Field< Type >::get. -5. Field< Type >::get now has a buffer and knows how to deal with it, converts - back to the desired type and returns. -Note that we can probably replace all of the Field stuff with SetGet1< Type >. - -We have a small problem here when handling array fields that also need to -refer to the parent object. For example, when dt values on clock ticks are -modified the parent clock needs to do some re-sorting. - -A related problems is to set up zombies. In all these cases, things would be -easier if we always had access to the full DataId as one of the function -arguments, as in UpFunc. This is untidy for regular function calls. -For that matter we might want to use yet more information arguments, such -as the target Element and the Qinfo, as in Epfuncs. - ------------------------------------------------------------------------------- -Setup -FIELD DEFINITION -Similar to earlier MOOSE, have an initClassInfo function for each class, -that is meant to be called in order at static initialization. The ordering -is ensured by having the static initializers call the static initializers -of their own base classes. - -With initClassInfo, set up a static array of finfos. Entries like: -new Finfo( async1< Reac, double, &Reac::setKf >, "Kf" ) -Function handling is cleaner in at least three ways: -- It does not require static typecasting of functions, -- It does static typecasting of the char buffer within a templated function -- It uses member functions of the Data class directly, rather than static - functions. - -Note that a single Finfo might refer to more than one OpFunc. For example, -a ValueFinfo will typically define a set func and a get func. -A LookupFinfo will define a set func with index, a get func with index, a - get func to return size of table, and a get func to return the whole - table. - - - -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 deleted file mode 100644 index 609752a0..00000000 --- a/Docs/developer/Ksolve.txt +++ /dev/null @@ -1,101 +0,0 @@ -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/MessageObjectLookup.txt b/Docs/developer/MessageObjectLookup.txt deleted file mode 100644 index 8cdde37a..00000000 --- a/Docs/developer/MessageObjectLookup.txt +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index abbc552d..00000000 --- a/Docs/developer/PortingOldMooseObjects.txt +++ /dev/null @@ -1,36 +0,0 @@ -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 deleted file mode 100644 index 370451e7..00000000 --- a/Docs/developer/PythonRecommendations.org +++ /dev/null @@ -1,135 +0,0 @@ -#+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 deleted file mode 100644 index d1206523..00000000 --- a/Docs/developer/ReduceOperations +++ /dev/null @@ -1,154 +0,0 @@ -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 deleted file mode 100644 index 9c8b02a2..00000000 --- a/Docs/developer/Scheduling.txt +++ /dev/null @@ -1,145 +0,0 @@ -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 deleted file mode 100644 index 6511ba07..00000000 --- a/Docs/developer/doxygen-API.cpp +++ /dev/null @@ -1,408 +0,0 @@ -/** -\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 deleted file mode 100644 index 31957ab9..00000000 --- a/Docs/developer/doxygen-design-document.cpp +++ /dev/null @@ -1,50 +0,0 @@ -/** -\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 deleted file mode 100644 index 7c1d36aa..00000000 --- a/Docs/developer/doxygen-main.cpp +++ /dev/null @@ -1,48 +0,0 @@ -/** -\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 deleted file mode 100644 index ba756f82..00000000 --- a/Docs/developer/doxygen-programmers-guide.cpp +++ /dev/null @@ -1,277 +0,0 @@ -/** -\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: -
      -
    1. Clock0: MeshEntry::process. -
    2. 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: -
      -
    1. ChemMesh::updateDiffusion( meshIndex ) -
    2. Stoich::updateDiffusion( meshIndex, stencil ) -
    3. Iterate through stencils, calling Stencil::addFlux for meshIndex -
    4. In Stencil::addFlux: Add flux values to the Stoich::flux vector. -
    - -
  • During Process on the GslIntegrator: -
      -
    1. the GslIntegrators on all threads call their inner loop - for advancing to the next timestep through gsl_odeiv_evolve_apply. -
    2. The GslIntegrators on all threads call Stoich::clearFlux. -
    -
  • During Process on the Stoich, which is called through the GslIntegrator - functions, not directly from Process: -
      -
    1. 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 -
    2. 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 deleted file mode 100644 index 898b663e..00000000 --- a/Docs/developer/hsolve-developer-overview.cpp +++ /dev/null @@ -1,208 +0,0 @@ -/** - -\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 deleted file mode 100644 index a6cbce1e..00000000 --- a/Docs/developer/hsolve-implementation.cpp +++ /dev/null @@ -1,156 +0,0 @@ -/** - -\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) - -
    - -
  1. -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. -
    2. -

    -
  2. -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. -
    3. -

    -
  3. -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. -
    4. -

    -
  4. -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. -
    5. -

    - -
- -\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 deleted file mode 100644 index 9c59d499..00000000 --- a/Docs/developer/parameter_fitting.cpp +++ /dev/null @@ -1,120 +0,0 @@ -/** - -\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: - -
    -
  1. Provide experimental data, simulation script, fitting settings to Optimizer,
    2. -
  2. Run parameter fitting,
    3. -
      -
    1. Optimizer provides parameters to the simulation through params.param file located next to the simulation script,
      2. -
    2. Optimizer runs the simulation,
      3. -
        -
      1. Simulation retrieves the parameters from params.param using OptimizerInterface,
        2. -
      2. Simulation runs with the given parameters,
        3. -
      3. Simulation saves the results to trace.dat, located next to the simulation script, using OptimizerInterface,
        4. -
      -
    3. 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.
      4. -
    -
  3. Optimizer shows parameter fitting results.
    4. -
- -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 deleted file mode 100644 index 4a7c9ed0..00000000 --- a/Docs/developer/profiling.cpp +++ /dev/null @@ -1,135 +0,0 @@ -/** - -\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 deleted file mode 100644 index c4afddab..00000000 --- a/Docs/developer/setget.txt +++ /dev/null @@ -1,112 +0,0 @@ -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 deleted file mode 100644 index bef52d56..00000000 --- a/Docs/developer/the-messaging-system.cpp +++ /dev/null @@ -1,171 +0,0 @@ -/** - * \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 deleted file mode 100644 index 887f3677..00000000 --- a/Docs/doxygen/Doxyfile +++ /dev/null @@ -1,2411 +0,0 @@ -# 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 = ../../basecode \ - ../../biophysics \ - ../../builtins \ - ../../device \ - ../../diffusion \ - ../../hsolve \ - ../../intfire \ - ../../kinetics \ - ../../ksolve \ - ../../mesh \ - ../../mpi \ - ../../msg \ - ../../randnum \ - ../../pymoose \ - ../../sbml \ - ../../scheduling \ - ../../shell \ - ../../signeur \ - ../../synapse \ - ../../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 -# , /