fix: incorrect subdivision

[dccabanas]

No description provided.

[dccabanas]

@dtoshniwal There is a problem here that will require some thought: there is no obvious way to subdivide a DiscreteGeometry. Since this structure relies entirely on some abstract evaluable function, creating a subdivision is not trivial.

[dtoshniwal]

@dtoshniwal There is a problem here that will require some thought: there is no obvious way to subdivide a DiscreteGeometry. Since this structure relies entirely on some abstract evaluable function, creating a subdivision is not trivial.

Indeed, I wanted to bring this up earlier as well. I think the DiscreteGeometry structure needs additional fields (FEM space, coefficients) that are used to construct the evaluable function. This way, one could use the additional fields to construct a subdivided representation. Otherwise, as you say, there is no other way to do this. I think these additional fields are OK because the only use case (at least the one I have in mind) is FEM geometries.

[dccabanas]

@dtoshniwal I marked this as ready because regardless of the discrete geometry issue the changes here are still bug fixes that should be merged.

[dtoshniwal]

@dccabanas One question: why are we restricting two-scale operators for B-splines/canonical spaces such that the child space is obtained by k bisections? For instance, why don't we allow trisections? I don't recall if there was a reason for this.

[dccabanas]

why are we restricting two-scale operators for B-splines/canonical spaces such that the child space is obtained by k bisections?

Can you point out where in the code this is happening? I don't recall.

[dtoshniwal]

why are we restricting two-scale operators for B-splines/canonical spaces such that the child space is obtained by k bisections?

Can you point out where in the code this is happening? I don't recall.

Here for instance:

Mantis.jl/src/FunctionSpaces/CanonicalSpaces/CanonicalSpaces.jl

Line 134 in 9490765

if num_sub_elements < 2 || !isapprox(num_ref - round(num_ref), 0.0; atol=1e-12)

[dccabanas]

why are we restricting two-scale operators for B-splines/canonical spaces such that the child space is obtained by k bisections?

Can you point out where in the code this is happening? I don't recall.

Here for instance:

Mantis.jl/src/FunctionSpaces/CanonicalSpaces/CanonicalSpaces.jl

Line 134 in 9490765

if num_sub_elements < 2 || !isapprox(num_ref - round(num_ref), 0.0; atol=1e-12)

It seems to have be introduced in this commit b67dfee. But I'm not sure why the limitation is there. Do you think it can be generalised?