There's also a problem with the Single*Matrix
approach:
For Stokes it does in principle allow to use a MTBV
with blocks BCRS<FM<T,d,d>>
, BCRS<SCM<FM<T,d,1>>>
, BCRS<SRM<FM<T,1,d>>>
, BCRS<T>
which seems to fit to a vector with blocks BV<FV<T,d>>
and BV<T>
.
But you can't multiply the matrix with the vector because this requires mv
for FM<T,d,1>
with plain scalar T
. One may want to fix this by overloading mv()
and friends in Single*Matrix
. But one may also consider this as an indicator that the concept of hybrid indices is misleading and one should always guarantee uniform ones by zero padding in the basis.
For vectors the problem is different. Theoretically you can always chose an appropriate type. For matrices this is not even possible theoretical as long as we stay to the pattern that matrix entries are always matrices. Single*Matrix
somehow allows to weaken this pattern in a mildly intrusive way.
If you want to specify the zero-digit insertion explicitly, the most natural place is IMO the basis, because this is where we define other index transformations, too. This however is essentially what power<1>(...)
does. Maybe this can be done more explicit by introducing aliases
appendZeroDigit(preBasisFactory)
for power<1>(preBasisFactory, blockedInterleaved())
prependZeroDigit(preBasisFactory)
for power<1>(preBasisFactory, blockedLexicographic())
I also had this in mind, but it's less flexible and more complicated compared to annotating the container with this information. That's why I decided for the latter. To illustrate this: How would you want to encode this information for the 'natural' blocking of Taylor-Hood for Stokes?
BTW: You can also parametrize the backend with the termination type for multi-index resolution. Specifying this to FieldMatrix<...>::row_type
may also solve the issue in this special case.
Ah, it's in the CI MR. I was looking in the present one.
As far as I can see the issue is exactly, what SingleColumnMatrix
is for. The same problem arises, when assembling a Stokes problem with 'natural' blocking of indices.
Can you point me to this hack?
With the updated CI it works. For 2.9 it fails, because a header in dune-fufem has been moved and renamed and you're using the new location.
I just noticed that <execution>
is actually used in the colouring and thus has to persist.
We should modernize the ci config, since the compilers are to old for dune core.
E.g. clang complaints about missing <execution>
header for dune-fufem. While this include is a left over and no longer used (I'll take care), it should nevertheless exist in C++17 as required by the core.
Gräser, Carsten (cb94a532) at 11 Jan 17:56
Gräser, Carsten (6d89896e) at 11 Jan 17:56
Merge branch 'cleanup/remove-unused-includes' into 'master'
... and 1 more commit
Gräser, Carsten (0008dd6e) at 11 Jan 17:50
Gräser, Carsten (f48ee560) at 11 Jan 17:50
Merge branch 'disable-ductile-fracture' into 'master'
... and 1 more commit
This does not compile since years and thus makes the CI less usefull.
This does not compile since years and thus makes the CI less usefull.