feat: separate GTB functionality from periodicity

[dtoshniwal]

Currently, periodicity needs to go through the GTB struct, but maybe it would be better to specialize it to a different struct. So all strictly GTB functionality stays with the GTB struct, but when something needs to be periodicity, we create a PeriodicFESpace. This will also allow specialization of methods to periodicity (e.g., when considering boundary integral computation, or when checking for minimal intersections).

[dccabanas]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

[dtoshniwal]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

I was not thinking of it but I guess it makes sense to have a periodic geometry first, and then build a FE space on top of it. But what would change for such a geometry have? For the FE space there would be new things (e.g., extraction operators change, dof partition changes).

[dccabanas]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

I was not thinking of it but I guess it makes sense to have a periodic geometry first, and then build a FE space on top of it. But what would change for such a geometry have? For the FE space there would be new things (e.g., extraction operators change, dof partition changes).

Just a few simple things.

In principle a periodic geometry would have an infinite number of elements, which of course would be impractical. So for this, I was thinking something along the lines of a “tiling” parameter that would limit how many repetitions we export. Not sure if this would be useful.

The other thing is that this structure would already handle the “periodic” logic, using mod. For example, if we had a periodic geometry starting from

|----|----| ( 2 elements )

Then evaluate(geo, 1, points) would match evaluate(geo, 3, points) up to the translation.

[dtoshniwal]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

I was not thinking of it but I guess it makes sense to have a periodic geometry first, and then build a FE space on top of it. But what would change for such a geometry have? For the FE space there would be new things (e.g., extraction operators change, dof partition changes).

Just a few simple things.

In principle a periodic geometry would have an infinite number of elements, which of course would be impractical. So for this, I was thinking something along the lines of a “tiling” parameter that would limit how many repetitions we export. Not sure if this would be useful.

The other thing is that this structure would already handle the “periodic” logic, using mod. For example, if we had a periodic geometry starting from

|----|----| ( 2 elements )

Then evaluate(geo, 1, points) would match evaluate(geo, 3, points) up to the translation.

These are changes that make mathematical sense, but I'm not convinced that they are needed practically.

• Repetitions: not sure what the application here would be, or why the number of repetitions would be bounded by a specific number.
• Mod logic: the number of elements should be fixed to the original number of elements (e.g., assembly will use this to loop over elements). But then not sure what the use of allowing evaluate calls for elem_id > n_elements will accomplish. I can see this introducing uninentional bugs.

[dccabanas]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

I was not thinking of it but I guess it makes sense to have a periodic geometry first, and then build a FE space on top of it. But what would change for such a geometry have? For the FE space there would be new things (e.g., extraction operators change, dof partition changes).

Just a few simple things.
In principle a periodic geometry would have an infinite number of elements, which of course would be impractical. So for this, I was thinking something along the lines of a “tiling” parameter that would limit how many repetitions we export. Not sure if this would be useful.
The other thing is that this structure would already handle the “periodic” logic, using mod. For example, if we had a periodic geometry starting from
|----|----| ( 2 elements )
Then evaluate(geo, 1, points) would match evaluate(geo, 3, points) up to the translation.

These are changes that make mathematical sense, but I'm not convinced that they are needed practically.

* Repetitions: not sure what the application here would be, or why the number of repetitions would be bounded by a specific number.

* Mod logic: the number of elements should be fixed to the original number of elements (e.g., assembly will use this to loop over elements). But then not sure what the use of allowing `evaluate` calls for `elem_id > n_elements` will accomplish. I can see this introducing uninentional bugs.

My idea with the repetitions was more for visualisation purposes, and it would then require the mentioned evaluation logic.

[dtoshniwal]

@dtoshniwal I was thinking about this, and I'm not sure about the geometry aspect. I suppose that for this to make sense, such a PeriodicFESpace would have to be define in a PeriodicGeometry. Was this what you were thinking?

I was not thinking of it but I guess it makes sense to have a periodic geometry first, and then build a FE space on top of it. But what would change for such a geometry have? For the FE space there would be new things (e.g., extraction operators change, dof partition changes).

Just a few simple things.
In principle a periodic geometry would have an infinite number of elements, which of course would be impractical. So for this, I was thinking something along the lines of a “tiling” parameter that would limit how many repetitions we export. Not sure if this would be useful.
The other thing is that this structure would already handle the “periodic” logic, using mod. For example, if we had a periodic geometry starting from
|----|----| ( 2 elements )
Then evaluate(geo, 1, points) would match evaluate(geo, 3, points) up to the translation.

These are changes that make mathematical sense, but I'm not convinced that they are needed practically.

* Repetitions: not sure what the application here would be, or why the number of repetitions would be bounded by a specific number.

* Mod logic: the number of elements should be fixed to the original number of elements (e.g., assembly will use this to loop over elements). But then not sure what the use of allowing `evaluate` calls for `elem_id > n_elements` will accomplish. I can see this introducing uninentional bugs.

My idea with the repetitions was more for visualisation purposes, and it would then require the mentioned evaluation logic.

That's a plotting modification. Nothing needs to change in the geometry. Plots could have a specialized function like this for plotting periodic geometries with some repetitions (if needed). Although I would still argue that even Plots shouldn't have this kind of functionality - it's a duplication that should be possible within all reasonable visualization software (Paraview certainly allows it). So in that case again nothing new would be implemented for such a geometry.

[dccabanas]

it's a duplication that should be possible within all reasonable visualization software

That's fair, I hadn't thought about that. Then we can probably do with just the PeriodicSpace.