Change initialize sequence

[bergbauer]

I have a bit of a chicken-egg problem in my code because of this initialize sequence change in #599

The problem is that my operator modifies the constraints and therefore also the matrix-free object and setting up the transfer correctly works only after the final matrix-free object is set up.

https://github.com/exadg/exadg/pull/599/files#r1401973099 states that this sequence change should not affect anything and also does not change the logic of initializing things dependent on initialize_preconditioners.

[kronbichler]

I think this looks good to me. I think that the transfer is subordinate to the operators, so the order seems more reasonable to me anyway.

[nfehn]

I think the problem is it could happen that we need the transfer operators in order to initialize operators. The concrete example I am thinking of is a velocity or displacement dof-vector that needs to be interpolated to coarser grids. If the present function is called with initialize_preconditioners = true, this might lead to a bug because the operators are not initialized completely.

[nfehn]

The problem is that my operator modifies the constraints and therefore also the matrix-free object and setting up the transfer correctly works only after the final matrix-free object is set up.

So you modify again the constraints and the matrix-free objects in initialize_operators()? Doesn't this imply that you break the logic of the MultigridPreconditionerBase::initialize() function anyway, which expects the order (i) dof-handler &constraints, (ii) matrix-free, (iii) operators?

Right now, I am somewhat against this change because it seems to me that the problem is only solved for your case by "mis-using" the implementation or certain functions at other places.

We could think about making the initialize() function virtual, then you have the full freedom and you can be more explicit about what needs to be done in which order in your case? (In this context, I wonder right now why the initialize() function is not protected?)

[bergbauer]

So you modify again the constraints and the matrix-free objects in initialize_operators()?

Yes, correct. I know this is not the intended use but it needs to be done for agglomeration.

We could think about making the initialize() function virtual, then you have the full freedom and you can be more explicit about what needs to be done in which order in your case?

A virtual initialize function is not necessary. What would work is if we make everything that is currently private protected and allow a derived class full access.

[nfehn]

A virtual initialize function is not necessary. What would work is if we make everything that is currently private protected and allow a derived class full access.

I did not fully understand this. Generally, I would like to not make everything protected (which has been private before). As I explained above, the problem that I see with the suggested change is that it only works because the logic is kind of "mis-used" at another place.