Dealii: Rename ConstraintMatrix, add a template argument

[tamiko]

In reference to #1433

Currently, the internal number type of a ConstraintMatrix is double. This is a bit unfortunate if it is used together with a SparseMatrix<std::complex<double>> object - only real valued constraints can be formulated (Funny enough this works out of the box because vector and matrix types are fully templated...).

So, what about renaming the ConstraintMatrix to Constraints and add a template:

template<typename number> class Constraint;

and add ConstraintMatrix as a typedef, or inherited class:

typedef Constraints<double> ConstraintMatrix;
class ConstraintMatrix : public Constraints<double>;

[bangerth]

Why? Are you planning on storing constraints with complex valued coefficients?

[tjhei]

or is the number type only for the inhomogeneous part?

[tamiko]

Why? Are you planning on storing constraints with complex valued coefficients?

Yes.

Did I miss something? Is there a compelling argument for always storing a double independently of the number type used in SparseMatrix (and other objects)?

[tamiko]

or is the number type only for the inhomogeneous part?

complex numbers for coefficents would allow for things like periodic boundary conditions with a phase shift.

[bangerth]

OK, fair enough. I see no reason not to allow complex-valued coefficients and right hand sides.

The difficult part is the backward compatibility :-(

[bangerth]

By the way, I think the correct name for the class in question should be AffineConstraints. ConstraintMatrix was true a long time ago when we didn't allow for a rhs, but even then was more a name motivated by the way we store the data, rather than what it describes. (Which implies that the name was poorly chosen 17 years ago -- my fault; this might be the chance to choose a better name.)

[tjhei]

The difficult part is the backward compatibility :-(

If we use this situation to also rename the class to AffineConstraints we can break the interface without problems (of course keeping the old ConstraintMatrix around for a while).

[tamiko]

(of course keeping the old ConstraintMatrix around for a while).

I thought about a typedef, or inheritance to provide a backward
compatible ConstraintMatrix

[bangerth]

I think either would work. The typedef has the advantage of being cleaner in terms of compatibility because you don't have to reimplement constructors. It's more obscure to document, however.

In either case the typdef/derived class should be all that will then be left in constraint_matrix.h with everything else moving into affine_constraints.h.

[bangerth]

See also #2033 .

[davydden]

so what is the consensus so far, do we introduce a single template for both inhomogeneity and matrix elements?

@tamiko did you pursue this issue? That's one of the few issues left which prevent complex-valued PETSc from working in full with deal.ii.

[tamiko]

@davydden I need this feature more or less right now. So I'll have a look at it this week :-)

[tamiko]

@bangerth I'll refactor ConstraintMatrix into a templated AffineConstraints object. After that we typedef AffineConstraints<double> to ConstraintMatrix.

I'm also in favor of imposing the same restriction on ConstraintMatrix as we did for the VectorTools and MatrixTools stuff. After all ConstraintMatrix is created by the user beforehand, thus, this should not impose any real restriction.

[davydden]

@tamiko cool!

If I understand you correctly, in VectorTools/MatrixTools you will use AffineConstraints<number> where number is consistent with InputVector::value_type, right? If so, then :+1:

[tamiko]

@tamiko cool!

If I understand you correctly, in VectorTools/MatrixTools you will use
AffineConstraints<number> where number is consistent with
InputVector::value_type, right? If so, then :+1:

Exactly!

[bangerth]

@tamiko -- yes, this sounds like a good plan. I assume you're going to store the expansion coefficients and rhs values with the same type (which seems like the appropriate choice).

[tamiko]

@davydden The current state can be found here: https://github.com/tamiko/dealii/tree/affine_constraints

[davydden]

@tamiko i looked through https://github.com/tamiko/dealii/commit/407fa908d5e723f75612701051230dde23f0971e and it all looks good to me! There is only one FIXME, as far as I noticed. Maybe create a WIP PR?

[tamiko]

@davydden I just started tackling this issue again.

[tamiko]

@bangerth I plan to get this done over the course of this week :-]

[davydden]

@tamiko maybe you can rebase your branch ontop of develop and create a WIP PR?

[tamiko]

@tamiko maybe you can rebase your branch ontop of develop and create a WIP PR?

Jup. Let me try to resurrect this PR.

[davydden]

Jup. Let me try to resurrect this PR.

@tamiko ping.

[tamiko]

@davydden Unfortunately, I have to start from scratch. But after the last weeks I will need some serious software project again to free up my mind :-)

[davydden]

@tamiko

I have to start from scratch

how did it go? 😸

[tamiko]

@davydden Working on it now :balloon: :tada: