Expression language for custom output fields

[talbring]

Proposed Changes

The is a first step in updating the output structure in order to make it a little bit more flexible and easier to maintain. The plan is to eventually have a consistent way of defining objective functions and/or define custom output quantities on individual surfaces.

I introduced a new structure to store scalar quantities for the history output. This makes it much easier to filter and loop through a specific subset of fields. Next step is to have per surface values stored in the same structure. Furthermore, creating structure to compute problem-specific outputs like aerodynamic coefficients, time-averaged quantities, surface quantities and so on.

Related Work

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 the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
• My contribution is commented and consistent with SU2 style.
• 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.

[talbring]

I am currently testing an expression parser to define custom fields in the config file. For this I modified the handling of the curly brackets {}. They now declare a "literal" interpretation, which means everything inside is considered as one string and will not be split while strings are tokenized when reading the config file.

When you declare the output fields you can then use expressions involving all available fields, e.g.

SCREEN_OUTPUT= INNER_ITER, RMS_DENSITY, {sqrt(LIFT)/DRAG**2}

At the moment only inline expression are possible. But I am considering also to use a file to define more complex functions. The goal is to make that framework more flexibel to that we can use it also to define custom integrals over markers, functions defined on the whole flow field, custom boundary conditions, inlet conditions and so on.

Important to note is that I already differentiated the parser, which means everything that is defined can be used also for the adjoint solver.

[pcarruscag]

Looks like we are going to get some very cool features, very nice 👍

[talbring]

@pcarruscag Thanks. I already incorporated your comments!

I extended the expressions to the volume output fields. Similar to the SCREEN_OUTPUT you can now define custom volume field variables directly in the VOLUME_OUTPUT option, e.g,

VOLUME_OUTPUT= COORDINATES, SOLUTION, {MOMENTUM_X/DENSITY}

This required to remove all - in the field names for obvious reasons.

Note that at the moment it is required that all fields used in the expression are also added manually to the output. I will probably make that automatic soon.

[pcarruscag]

Don't forget #1025 @talbring since you are moving some code into modules.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions.

[erangit]

Tim,
Stale is taking over this PR. I think it is useful, not only for the ventilator's effort. Would you like to pack at least the part that is completed and merge to develop?
Thxs,
Eran

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions.