modifications for constraints for problems with multiple unknowns

[chmerdon]

attempt to fix issue #112 , seems to work but needs polishing

[pjaap]

Thanks a lot for this fix. I looked at it for a while and I think that this is currently the only solution to fix this.
It will polish it a bit, such that it is not breaking. (use default = 1 for the unknown?)

But I would really prefer that the restrictions are global algebraic restrictions, just like SC.A.entries is a global matrix. We should discuss this after this PR here. The main issue lays in the FES ... we do not have one FES, but one for each variable. Personally, and biased from DUNE, if prefer a single FE space. So something like

FES = Product_FES(FES1, FES2)

for two unknowns. Then, the FES contains the local<->global index mappings.
Also in DUNE, we had power spaces for multidimensional images of the FE functions

FES = Power_FES(FES1, 3)

for H1P1{3}, since H1P1 is in my limited world view always scalar 🤔

Then, the, e.g., coupling matrices have global size and only entries in the corresponding index ranges.

But this is something for later discussions and ExtendableFEM 2.0.

[chmerdon]

Yes, such a product spaces would be interesting and probably can replace the ncomponents parameter in some FESpaces who are just products of scalar spaces, but as you said, that is definitely something that needs to be implemented in the 2.0 version of ExtendableFEMBase first.

However, isn't the situation similar to the assembly of operators who also just know their unknown-dependency. That's why the assembly function gets the SolverConfiguration which knows the size of the problem and the offsets for all unknowns and then all information can be combined to write into the correct blocks of matrices and vectors, or, as we maybe should do it in the case of restrictions, we could use the information to scale the coupling matrix (or one dimension of the B matrix in general) to the correct global size.