Inconsistencies in valuetype keyword argument of FE space constructors

[santiagobadia]

valuetype is a mandatory keyword argument in the PLagrangian FE space constructor

FESpace( reffe=:PLagrangian, conformity=:L2, valuetype = Float64, order = 1, model = model)

but when one uses Float32 or Float16 it returns a conversion-related error.

On the other hand, for other methods like Raviart-Thomas FE spaces

FESpace( reffe=:RaviartThomas, conformity=:HDiv, order=2, model=model, diritags = [5,6])

it is not required and whatever one puts the result is the same.

By the way, not sure whether we should consider that the right value for vector field FE spaces that are not the composition of scalar ones should require e.g. Float64 or VectorValue{2,Float64}

[fverdugo]

valuetype is a mandatory keyword argument in the PLagrangian FE space constructor

FESpace( reffe=:PLagrangian, conformity=:L2, valuetype = Float64, order = 1, model = model)

but when one uses Float32 or Float16 it returns a conversion-related error.

This is not surprising. We have only tested for Float64. Not tested == not supported. We can fix this in the near future. Moreover, if one uses e.g. Float16 all user-defined function have to return Float16, e.g. the source term f(x) = 1.0 will not work, but f(x) = Float16(1.0) will.

On the other hand, for other methods like Raviart-Thomas FE spaces

FESpace( reffe=:RaviartThomas, conformity=:HDiv, order=2, model=model, diritags = [5,6])

it is not required and whatever one puts the result is the same.

By the way, not sure whether we should consider that the right value for vector field FE spaces that are not the composition of scalar ones should require e.g. Float64 or VectorValue{2,Float64}

I would clearly adopt VectorValue{2,Float64}. If one passes something that is not a VectorValue of the correct length for a R-T reference element, an error should be raised.

[santiagobadia]

Ok, in this case, I would probably think about using fieldtype with values :scalar, :vector, :tensor, or a number such that the field will be a 0-tensor. Mandatory keyword arg for Lagrangian FE spaces.

Leave valuetype but as optional and with Float64 as default value.

And certainly, not to consider the value fieldtype in vector-based bases.

Now we are mixing both the field type and the number type of entries and I find it confusing.

[fverdugo]

In any case, I will not use valuetype for referring to the type of the components. I would use something like componenttype. That is either define componenttype=Float64 + fieldtype=:vector, or define valuetype=VectorValue{D,Float64}. But not valuetype=Float64 + fieldtype=:vector.

componenttype is a bit long, other names?

[santiagobadia]

As soon as we distinguish the two concepts, it is OK to me. What about numbertype with :Float64 , :ComplexF64 or whatever number type in Julia you like.

[santiagobadia]

By the way, not sure we need to expose numbertype in the tutorials of the article

[fverdugo]

As soon as we distinguish the two concepts, it is OK to me. What about numbertype with :Float64 , :ComplexF64 or whatever number type in Julia you like.

scalartype ? VectorValue is in fact a number in our implementation. Moreover, I would not use symbols like :Float64. Using the name of the type, namely Float64, Complex{Float64} is enough, more explicit, and more extensible. The user could use a new user-defined scalar type here.

[santiagobadia]

Yes, that is what I wanted to mean... scalartype or numbertype should be the type of Julia to be used. Proably not using the right notation.

I think I prefer numbertype (it is what we want I would say) and scalar type for a vector field, not sure... But if you like the most scalartype it is OK to me.

[fverdugo]

Perhaps comptype (for component type)?.

In any case, I would not expose this to the users for the moment. So we are not in a hurry for deciding this now

[fverdugo]

In Julia parlance, this is specifically called eltype.

But, perhaps it is a bit confusing since we have the concept of "reference finite ELement"

[fverdugo]

I have just realized that the constructor for RaviartThomasRefFE(p:: Polytope, order::Int) has not any argument for the value type (or the component type depending on the criterion we chose).

The signature should be something like

function RaviartThomasRefFE(::Type{T},p:: Polytope, order::Int) where T
...
end

We need to decide if T is the value type or the component type.

Once we have this, we can propagate this info to the FESpace constructor