This variable controls the amount of debugging information generated by Octopus. You can use include more than one option with the + operator.
(default) Octopus does not enter debug mode.
Octopus prints additional information to the terminal.
Octopus generates a stack trace as it enters end exits
subroutines. This information is reported if Octopus stops with
The trace is printed to the terminal as Octopus enters or exits subroutines. This slows down execution considerably.
The trace is written to files in the debug
directory. For each node (when running in parallel) there is a file called
debug_trace.<rank>. Writing these files slows down the code by a huge factor and
it is usually only necessary for parallel runs.
This enables Octopus to perform some extra checks, to ensure
code correctness, that might be too costly for regular runs.
Octopus generates a dot file containing the graph for a multisystem run.
Octopus generates a dot file containing the graph for a multisystem run including ghost interactions.
Octopus generates a file with information for the propagation diagram.
If true, trap signals to handle them in octopus itself and print a custom backtrace. If false, do not trap signals; then, core dumps can be produced or gdb can be used to stop at the point a signal was produced (e.g. a segmentation fault).
If true, allows the use of certain parts of the code that are still under development and are not suitable for production runs. This should not be used unless you know what you are doing. See details on wiki page.
Normally Octopus determines automatically the type necessary for the wavefunctions. When set to yes this variable will force the use of complex wavefunctions.
Warning: This variable is designed for testing and
benchmarking and normal users need not use it.
When debugging the code in parallel it is usually difficult to find the origin of race conditions that appear in MPI communications. This variable introduces a facility to control separate MPI processes. If set to yes, all nodes will start up, but will get trapped in an endless loop. In every cycle of the loop each node is sleeping for one second and is then checking if a file with the name node_hook.xxx (where xxx denotes the node number) exists. A given node can only be released from the loop if the corresponding file is created. This allows to selectively run, e.g., a compute node first followed by the master node. Or, by reversing the file creation of the node hooks, to run the master first followed by a compute node.
If true, after each SCF iteration Octopus will print information about the memory the code is using. The quantity reported is an approximation to the size of the heap and generally it is a lower bound to the actual memory Octopus is using.