Debugging and Profiling¶
Debugging¶
- The preferred method for debugging C++ code in Psi4 is with gdb. To run Psi4 in this way, you must specify the Python executable as the program. Arguments are provided using the
--args
flag. Here’s an example.:: $~> gdb –args /usr/bin/python3 /path/to/psi4 input.dat
In order to debug properly, Psi4 needs to be built with the CMAKE_BUILD_TYPE
variable set to either Debug
or RelWithDebInfo
. These will output debugging symbols that will allow gdb to print line numbers and
inline function names.:
> cmake [your options here] -DCMAKE_BUILD_TYPE=Debug
> cmake [your options here] -DCMAKE_BUILD_TYPE=RelWithDebInfo
Certain symbols may not be output even with this flag set. In general, any template function used should be visible, and anything with the PSI_API
modifier will be visible. Other variables, functions, and classes will
likely be hidden from the user. To make these symbols visible, you must modify a few variables. For an example, see TiborGY’s debug branch.
Also see more debugger directions
and a [presentation] .
If building using psi4-path-advisor cmake
, one should run it straight, not within eval $(...)
, note the usage command it outputs, then edit the cache file it has produced to change CMAKE_BUILD_TYPE
to Debug
and CMAKE_CXX_FLAGS
to -O0
, then execute the noted cmake ... -C cache
command to configure.
VSCode¶
When using gdb wath VSCode, you should set the program
entry to the Python executable, just as before. Arguments can then be placed in the args
entry. If you are debugging a C++ plugin or backend code,
the launch type should be cppdbg
.
Profiling¶
Instructions on using Psi4 with a profiler, or/and discuss how timers work in Psi4… they are hierarchical…. I think we have special timers for parallel blocks.