Tape recording debug mode

[oleburghardt]

Proposed Changes

Add feature to record a tape for debug purposes (as a tool for AD / discrete adjoint / .. developers), using CoDiPack's codi::RealReverseTag.

More precisely, instead of using a definition of the su2double floating point type that allows us to compute derivatives, we define su2double = codi::RealReverseTag by passing the compile flag -Dcodi-tape=Tag, for instance through

meson build-tapecheck -Denable-autodiff=true -Dcodi-tape=Tag --buildtype=debug

by which all variables of type su2double can instead carry an additional "tag" of type int.

When using the multizone discrete adjoint solver (for now, any single zone case must be wrapped as such one), SU2_CFD_AD that was compiled with -Dcodi-tape=Tag will automatically start the debug mode, i.e. a new function CDiscAdjMultizoneDriver::DebugRun() inside CDiscAdjMultizoneDriver.cpp that makes use of the tag-option.

We can specify two options in the config file,

• CHECK_TAPE_TYPE -- the kind of tape that we want to investigate (FULL_SOLVER_TAPE or OBJECTIVE_FUNCTION_TAPE)
• CHECK_TAPE_VARIABLES -- the kind of variables that we want to check the selected tape for (SOLVER_VARIABLES or both SOLVER_VARIABLES_AND_MESH_COORDINATES)

How does it work?

CDiscAdjMultizoneDriver::DebugRun() performs two subsequent recordings with different tags.

1. Setting tag "1" to all inputs and starting a first recording. As the recording continues, each variable that is computed from a variable carrying a non-zero tag will be assigned the same tag. Thereby each variable that is dependent on an input variable will be assigned a tag "1".
2. Subsequently, setting tag "2" to the same inputs and performing a second recording. Thereby each variable that is dependent on an input will be likewise assigned a tag "2".

How does this help to uncover recording inconsistencies that could be the cause of wrong derivatives?

Once the test mode detects a mismatch between tags, it will perform a callback (implemented through CoDiPack's tagErrorCallback in ad_structure.hpp) .

• Very likely, it reports "Use of variable with bad tag 1, should be 2".
  This means that a variable has become active (i.e. dependent on the inputs) during the first recording, and was used in the second recording still carrying its "old" tag 1. In other words, there has been at least one use of this variable without recognizing -- and recording -- its dependency on the inputs. (Detected via the second recording, but being present in any recording, of course.) This can, for instance, happen in case of an improper handling of postprocessing values.
• The message "Use of variable with bad tag 1, should be 1337" indicates a preaccumulation mistake - all inputs in a preaccumulation region carry tag 1337, a differing tag means that a variable has been missed to be registered as a preaccumulation input.

How do I know at which line of the code the mismatch has been detected?

Compiling with debug flag --buildtype=debug and setting a breakpoint inside tagErrorCallback in gdb or cdgb will guide you there ;-)

Related Work

This is a (cleaned-up) continuation of #2343.

Supposed to help finding remaining errors in #2317.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
• My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I have added a test case that demonstrates my contribution, if necessary.
• I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.