Automatically create adjoint parameters from primal parameters

[armingeiser]

I think it would make sense to create a process that automatically creates the parameters for the adjoint analysis from the primal parameters.

That would reduce the amount of settings that need to be adaptetd and checked for the sensitivity analysis.

What do you think about this? @MFusseder @msandre @jcotela @sunethwarna

[msandre]

I agree it would be very useful to automate the adjoint problem from the primal. But currently with the parameters, I see two issues. First, they are highly problem dependent. If we need to implement a process for each adjoint problem this will be a huge effort. Second, they change often. If we have to update the process each time a primal parameter changes, maintenance would be impossible. @sunethwarna had some ideas about this. As far as I understood his idea was to reference the primal parameters from a separate adjoint parameters file. This might be a way to go. Alternatively some sort of adjoint model part generator that operates on a primal model part (the model part is far more stable than the parameters) could be useful. E.g., replacing elements and conditions, variables, dofs, bcs etc. At the moment though I see this as a big effort would suggest adding it to the roadmap but not starting with the implementation of more features until we have unified and cleaned up the response functions and adjoint solvers.

[armingeiser]

@msandre :+1: for your comment on not opening a new topic until other things have settled.

Still i would collect some thoughts:

The current way i deal with these parameters in the responses/optimization is to reference primal and adjoint parameters file inside the response settings.

    "kratos_response_settings":{
        "response_type"    : "adjoint_linear_strain_energy",
        "gradient_mode"     : "semi_analytic",
        "some_more_settings": "...",
        "primal_settings"  : "rectangular_plate_parameters.json",
        "adjoint_settings"  : "rectangular_plate_adjoint_parameters.json"
    }

These primal settings and adjoint settings are then used to create the primal/adjoint analysis in the python "response" class. This could be a good place to do the conversion, however it might look like. By adding an additional boolean setting "automatically_create_adjoint_settings": true, this would still offer the "expert" mode to manually define the adjoint parameters. Also adding the HDF5 process to the primals could be done there, so a generic primal parameters file could be used without modification.

[armingeiser]

For our linear structural responses, it would currently boil down to:

• dirichlet condition processes: switch primal with adjoint dofs
• load condition processes: are not reused from primal
• add HDF5 input/output
• change the scheme to "adjoint_static_linear"

@MFusseder can you add some requirements for nonlinear cases, as you work on them currently?

[MFusseder]

For the geometric nonlinear problems I work on currently, the four requirements listed by @armingeiser are also enough for those. Please note I just started with nonlinear problems so maybe there are some issues I don't see now. The only different point could be the definition of a specific pseudo-time for which state the adjoint analysis should be executed. Until now I always do sensitivity analysis on the state of the last computed step of the primal analysis.

[sunethwarna]

I totally agree with @msandre , at the moment we have issues on transient adjoints when trying to get the total time duration, start time, etc from the primal solution. But I hope with the unified way of adjoint solvers, and the responses being open to python level, then we will be able to find a cleaner way to do this :)

[philbucher]

Closing since inactive Please reopen otherwise