Replace `dolfinx.fem.Constant` with a real function space

[jorgensd]

Currently, DOLFINx uses two UFL concepts, namely ufl.Constant and ufl.Coefficient.
The ufl.Constant is tied to a domain (dolfinx.mesh.Mesh), even if it doesn't leverage any information from it.
The primal motivation for having a domain in Constant is differentiation (ref: FEniCS/ufl#313 (comment)).
However, we don't use this in DOLFINx atm.

Pros with dolfinx.fem.Constant:

• Faster packing, as there is only one value per domain

Cons with dolfinx.fem.Constant:

• Extra input to kernels, i.e. extra code and special handling in FFCx
• Extra packing routines in DOLFINx, i.e extra code
• No clear instructions on ownership of the values in the constant. One is required to manually sync this value.

Pros with dolfinx.fem.FunctionSpace(real_element)

• Clear ownership of values
• Differentiability
• Less code in FFCx and DOLFINx for packing and passing data to kernels.
  Cons:
• Slightly more packed data (real space is equivalent to packing a DG-0 function.

[jorgensd]

To fix the packing of real spaces, one could do:

a = pack_data_of_one_constant_cell.flatten()
b =  np.lib.stride_tricks.as_strided(a, shape=(repeats, len(a)), strides=(0, a.itemsize))

This is illustrated in:
scientificcomputing/fenicsx_jax@50018d4#diff-0654a0e1d0afa67b21f86c5c6e6051b5d8214be39d641cebb86cf1fa7f1ffe1eR136-R141

[garth-wells]

My reservation here is that real spaces is a historic hack (hijacking DG0 elements) that hasn't been properly worked through, so we should be very cautious in building on them.

I don't recognise the first two 'cons' as cons. Interfaces are simpler when broken into multiple logical arguments. Separate packing for constants is a deliberate design choice to allow fine-grained control of when constants are 're-packed'. I don't follow the ownership point.

[jorgensd]

My reservation here is that real spaces is a historic hack (hijacking DG0 elements) that hasn't been properly worked through, so we should be very cautious in building on them.

But they are a valid function space (especially in terms of optimization), as pointed out by the pros above.
I do not think the original implementation hijacked the DG-0 element, as there was the concept of a globally shared degree of freedom.

I don't recognise the first two 'cons' as cons. Interfaces are simpler when broken into multiple logical arguments. Separate packing for constants is a deliberate design choice to allow fine-grained control of when constants are 're-packed'. I don't follow the ownership point.

The ownership point: A constant stores a data-array on each process. This array has no MPI awareness, i.e.

c = fem.Constant(domain, 2.0)
if domain.comm == 0:
    c.value[:] = 1
else:
    c.value[:] = 2

cannot cause an invalid form, in the sense that the cells owned by rank 0 use c=1, while others use c=2.
We do not have the option to do c.scatter_forward() or c.scatter_reverse(dolfinx.la.InsertMode.add)
as with a dolfinx.fem.Function/dolfinx.la.Vector.

Secondly, if you are saying that you do not want to re-introduce the real function space, why does the dolfinx.fem.Constant take in a mesh? The only reason for having the mesh as input is such that one can get differentiability by reconstructing a real function space argument at a later stage.