GENESIS: Documentation

Related Documentation:

Frequently Asked Questions

This page provides answers to frequently asked questions (FAQ). The answers to particular questions contain links to more detailed documentation. Questions and their answers are added to the lists as they are received by either the genesis-sim-users mailing list or the GENESIS Development Team.

The categories of FAQ are as listed below. They can be extended as needed or requested.

USER FAQ

1. Why should I subscribe to the GENESIS mailing list?
   Although anyone can email a question or reply to the GENESIS mailing list, if you are not registered, you will only receive a reply if the person answering your question remembers to “reply to all”, something that cannot be guaranteed.
2. How do I join the genesis-sim-users mailing list?
   Instructions can be found at:

   https://lists.sourceforge.net/lists/listinfo/genesis-sim-users.

3. How do I email the genesis-sim-users mailing list?
   Send an email to:

   genesis-sim-users@lists.sourceforge.net.

4. How do I contact the GENESIS Developers Team?
   You can contact us directly at:

   http://genesis-sim.org/contact.

5. How do I generate a FAQ?
   The preferred method of generating a FAQ is to email the genesis-sim-users mailing list. As replies are received a FAQ response will be generated.

   For further information see Workflow User Question.

6. Who should I be when installing GENESIS on my computer?
   GENESIS should not be installed as superuser/root/administrator or by using the sudo command. However, installation as a regular user will result in a prompt requesting the root password to be entered for each component installed.

   Testing an installation (recommended) as superuser (not recommended) via the command:

   neurospaces_check >/tmp/check.out 2>&1

   generates files that are owned by root. Subsequent use of GENESIS will fail as many files will not be owned by the user. For example, when running Example Script 1 in Tutorial 1, an error message similar to the following will be generated:

   genesis > create cell /n      . . .      genesis > check /n      Can’t locate object method "new" via package "SSP" at /usr/local/glue/swig/perl/GENESIS3.pm line 1314.      at /usr/local/bin/genesis-g3 line 40              main::__ANON__(’Can\’t locate object method "new" via package "SSP" at /usr/l...’) called at /usr/local/glue/swig/perl/GENESIS3.pm line 1314              GENESIS3::Commands::run(’/n’, 0) called at /usr/local/glue/swig/perl/GENESIS3.pm line 224              GENESIS3::Commands::check(’/n’) called at (eval 89) line 1              eval ’GENESIS3::Commands::check( \’/n\’, )      ;’ called at /usr/local/bin/genesis-g3 line 146              main::interprete(’check /n’) called at /usr/local/bin/genesis-g3 line 217              main::loop() called at /usr/local/bin/genesis-g3 line 279              main::main() called at /usr/local/bin/genesis-g3 line 339      $Result = undef;

   If you have this problem a quick fix is to:

   1. Delete all files in /tmp owned by root (find owner with “ls -l”) that were produced by neurospaces_check with a command such as the following:

      root /tmp #  rm -Rf neurospaces/ morphology* file* text_* report_* heccer output* purk_test_soma* readcell_reset.txt  traub91_* text_gshell_1.* singlep.ssp 1.* current_schedule a1 a2

   2. If the previous step doesn’t fix the problem, remove all _Inline directories from your home directory/folder.
   3. Keep removing files owned by root in /tmp and the _Inline directories in your home directory, until the problem is resolved.

   Although GENESIS is a system-wide install, currently only a single account owner or user should uniquely use a single copy of GENESIS on a machine.

FAQ Acknowledgment: Alexandre Gravier.

DEVELOPER FAQ

1. How do I find the version numbers of the GENESIS components I have installed ?
   There are several ways to determine the version of the GENESIS components that are currently installed on your machine:
   • To determine the version of the G-Shell, at a command line prompt enter:

     genesis-g3 --version

   • The script neurospaces_versions gives release labels, but the details of the release procedure are currently not defined as we are pre-alpha release. So the usefulness of information returned by this script is limited.
   • The script neurospaces_status returns monotone version control numbers.
   • Either neurospaces_versions or neurospaces_status can be combined with a “--regex” argument to select software components. For example:

     neurospaces_status --regex ns-sli      /usr/local/bin/neurospaces_build: *** package ns-sli      /usr/local/bin/neurospaces_build: package ns-sli [mtn ls missing] executing      /usr/local/bin/neurospaces_build: package ns-sli [mtn ls unknown] executing      /usr/local/bin/neurospaces_build: package ns-sli [mtn status] executing      Current branch: 0      Changes against parent d13a526e58e47dcfb6163dad38c59a2a7d39b723         patched  tests/scripts/test-simplecell/simplecell-0.g

     The fact that no output followed the output lines

     /usr/local/bin/neurospaces_build: package ns-sli [mtn ls missing] executing      /usr/local/bin/neurospaces_build: package ns-sli [mtn ls unknown] executing

     in response to the monotone commands “mtn ls missing” and “mtn ls unknown”, confirms that documentation was neither missing nor unknown.

     Output following the line

     /usr/local/bin/neurospaces_build: package ns-sli [mtn status] executing

     in response to the monotone “mtn status” command shows that the NS-SLI component is under monotone version control in (default) branch 0. The string d13a5... is a monotone version identifier that is unique to the current version of NS-SLI under development on the machine where the query was made.

   • If you go to the NS-SLI source directory and do

     mtn log | less

     you get a detailed cvs-style log of development progress.

BACKWARD COMPATIBILITY FAQ

• In G-2, field variables such as V _m and I_m that are calculated by the solver are not treated differently to fixed parameters such as R_m and C_m that are set with setfield. (In fact you could set V _m with setfield, but it will be changed at the next timestep, while getfield can be used on either type of variable.) Evidently, G-3 does not show V _m with show_parameter, or make it available with getfield. But, getfield should work on both kinds of field variables. What is the reason for this?
  The Model Container registers solver information for each model being solved. This allows the software to retrieve information from the solvers (e.g. Heccer) about the model they are solving. Solved variables with common names such as V _m or dedicated names such as average_{V m}, and other information of potential interest to a user, such as what is the maximal time step so far or what is the simulation time, are local to the solver. Due to the separation of a model from its mathematical implementation, this is obviously very different from how G-2 works.
• The G-2 create command creates and initializes all fields of a compartment when it is created. In the G-Shell, the field parameters don’t seem to exist until they are initialized. Was that a design decision, and what do you think is best?
  Yes, this is a design decision. The Model Container allows the definition of “incomplete” models. It is up to other software components to decide if a model is complete or not. In G-3 completeness for a mathematical solver is quite different from completeness for a morphology analyzer.