Dear reader,

Let me give a little bit background first:

When a massflow is prescribed for periodic flow (KIND_STREAMWISE_PERIODIC= MASSFLOW), then a pressure drop is iterated(/adapted in each iteration) to fulfill that massflow requirement. In the Volume Source term only this pressure drop is used. The initial value at solver start is the value given in STREAMWISE_PERIODIC_PRESSURE_DROP= ?? and for restarted/adjoint simulations the STREAMWISE_PERIODIC_PRESSURE_DROP from flow.meta is taken.

Now this PR:

Until now, the update of the pressure drop, based on the difference between current and prescribed massflow, was done in the Flow solver Preprocessing. That causes some trouble as that routine is called multiple times during normal starts, restarts and even twice(!) for every normal iteration. So do not put any iterated quantities in those like I did. I now did put the update right in front of where it is used -> in the Source_Residual. Like so there shoulnd't be that much trouble of correct taping in that one iteration for the adjoint and it makes the logic of Inner_iter/outer_iter==0 etc unnecessary.

I am not sure the changes up until now are necessary but I am not sure whether they are enough tbh. I will update this description accordingly:

Update: So to give you an idea of the current state of gradient validation. My setup is the good'ol 2D periodic Pin case (fluid-only) with the Design variables being FFD-parameters only around the middle pin (so no Periodic Interface shenanigans up to now) and I have 4 OF: Avg_Temp and Drag on the middle-Pin Surface as well as the Pressure-drop between In/outlet plus massflow through in- OR outlet (which is the same in value but maybe not for the gradient 🤔 ):

1. For prescribed pressure drop I get a very good agreement for Avg_Temp and Drag (below 0.1% relative diff across the board).
   
   For Massflow and pressure drop the gradients are off by quite a bit but not too shabby (a good optimizer certainly could make good use of those gradients). Of course the Pressure-drop gradient should be 0 but there are prob some numerical gains to be made. The Pressure-drop gradient is O(1e-5) where the others are O(1 - 1e4) so I consider that to be ok
2. For prescribed massflow (and I differentiate here between the code before this PR and ...well this PR): The gradient for Avg_Temp and drag are okay-ish but far from being validated (just like for massflow and dp for prescribed dp)
   
   For massflow OF I get wrongly reported gradients by the adjoints, both before and after this PR
   
   and pressure drop OF
   

Two other aspects.

1. the PRESSURE_DROP OF is computed in streamwise periodic flow using the Recovered_Pressure (as the "standard" Pressure is the same on both faces). There I need to make sure that the recovered values are computed as well after the iteration (but with the Flow Preprocessing after the MultiGridCycle that seems to be the case)
2. As pressure drop is iterated to get the correct flow solution, is it necessary to treat is specially in the adjoint like a solution variable? <- turns out, that was the case and also is the majority of work done in this PR

Le fin

Related Work

#773 initial implementation
#1527 first step in getting a consistent restart for massflow prescribed flow by storing the pressure drop in massflow-meta file

PR Checklist

• 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, or simply --warnlevel=2 when using meson).
• 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.