Debug

Name Debug
Section Execution::Debug
Type flag
Default no

This variable controls the amount of debugging information generated by Octopus. You can use include more than one option with the + operator.

Options:

• no:
  (default) Octopus does not enter debug mode.
  
• info:
  Octopus prints additional information to the terminal.
  
• trace:
  Octopus generates a stack trace as it enters end exits subroutines. This information is reported if Octopus stops with an error.
  
• trace_term:
  The trace is printed to the terminal as Octopus enters or exits subroutines. This slows down execution considerably.
  
• trace_file:
  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.
  
• extra_checks:
  This enables Octopus to perform some extra checks, to ensure code correctness, that might be too costly for regular runs.
  
• interaction_graph:
  Octopus generates a dot file containing the graph for a multisystem run.
  
• interaction_graph_full:
  Octopus generates a dot file containing the graph for a multisystem run including ghost interactions.
  
• propagation_graph:
  Octopus generates a file with information for the propagation diagram.
  
• instrument:
  Octopus adds instrumentation to functions specified in an InstrumentFunctions block.
  

Name DebugTrapSignals
Section Execution::Debug
Type logical
Default yes

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).

Name ExperimentalFeatures
Section Execution::Debug
Type logical
Default no

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.

Name ForceComplex
Section Execution::Debug
Type logical
Default no

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.

Name InstrumentFunctions
Section Execution::Debug
Type block

This input options controls which routines are going to be instrumented for the tools selected using the Debug option.

%InstrumentFunctions
  function_name | instrumentation_tool
%

Here is an example to better understand how this works:

%InstrumentFunctions
  grid/grid.F90/grid_init_from_grid_stage_1 | verrou
%

NOTE: Currently only a single function can be instrumented!

Available instrumentation tools:

Options:

• verrou:
  Verrou helps you look for floating-point round-off errors.
  

Name MPIDebugHook
Section Execution::Debug
Type logical
Default no

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.

Name ReportMemory
Section Execution::Debug
Type logical
Default no

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.