added ModelPart as parameter to CalculateValue of core response fct

[MFusseder]

Within this PR we add ModelPart as parameter to the function CalculateValue of the core class AdjointResponseFunction.

The reason for this modification is that we like to derive the class AdjointStructuralResponseFunction of the Structural Mechanics Application from the core response class in a next step. This will lead to a decrease of code duplication since in order to that also the adjoint schemes and the sensitivity builder of the core can used from the adjoint sensitivity analysis of the Structural Mechanics Application. The only obstacle which forbids currently this inheritance is the fact that we need to give a model part to the CalculateValue function.

@msandre, @armingeiser and me had a long discussion on this issue. The outcome was the agreement that adding the model part to CalculateValue is not best practice. But nevertheless we agreed also to do this modification for now in order to open the core class in order to enable the described inheritance.

Once the inheritance is done and the adjoint schemes and the sensitivity builder of the core are usable also from Structural Mechanics Application we will come back to this issue.

[philbucher]

can you describe why this is necessary?

[msandre]

This is so that the implementation of @MFusseder and @armingeiser can derive from the core classes without breaking. At the moment, nobody else in kratos is using this function. We agreed to make this change now so that we can merge the implementations.

[pooyan-dadvand]

As KTC is assigned to the issue I forward it to @KratosMultiphysics/design-committee

[philbucher]

This is so that the implementation of @MFusseder and @armingeiser can derive from the core classes without breaking. At the moment, nobody else in kratos is using this function. We agreed to make this change now so that we can merge the implementations.

But why is the modelpart is needed now?
@msandre you designed it without it, what is the difference in implementation in Structural-Sensitivities?
Not blocking, just curious

[MFusseder]

@philbucher in adjoint sensitivity analysis two model parts are involved: One for the primal and one for the adjoint problem. The response function is created in the adjoint solver, where we have only access to the adjoint model part but not to the primal one. So we can have the adjoint model part as member variable of the response but not the primal model part. But unfortunately in structural sensitivities we need the primal model part for the computation of the value of the response function which is done in CalculateValue. This is the reason for the new function parameter. In case of fluid sensitivities the adjoint model part and is enough for CalculateValue.

[msandre]

There are two separate analyses, adjoint and primal, each with it's corresponding model part. The response function is owned/needed by the adjoint analysis and has a reference to the adjoint model part. But, as explained to me by @MFusseder and @armingeiser, they need the primal model part in CalculateValue for some of their response functions.

We didn't want to pass the model part as a parameter to CalculateValue because the response function also provides implementations with the Initialize()/InitializeSolutionStep()/... interface, and these generally act on the internally stored reference to model part, which may or may not be the same as the model part passed to CalculateValue. However, if we don't allow this change now, we will be blocked for a longer period of time from integrating many of the adjoint-related features in structural mechanics with the core and we agreed that we want to integrate these as soon as possible to eliminate code duplication and other inconsistencies from creeping in.

[philbucher]

thanks for explaining