Wrap-up current changes

[dccabanas]

Hello, everyone.

There are currently quite a few big changes hanging around (geometry/function space rewrite, multipatch, skeleteon spaces), and it seems like we have been stuck for a while figuring out the best order of operations.

To help wrap this up, what follows is a suggested order in which we should merge branches/features:

• 1. Polar spline rework -> So that we can finalize function space rewrite.
• 2. Function space rewrite -> Can be merged after 1., and will enable work on multipatch.
• 3. Multipatch work for geometry -> Can be worked on after 2., and we can include num_patches for geometry.
• 4. Geometry/Function space reordering #262 -> After 3. we can make function spaces use geometry.
• 5. Introduce topology -> After 4. we make geometry depend on topology, independently of function spaces.
• 6. Boundary/Skeleton spaces -> After 5. we can use topology to define trace spaces.
• 7. Boundary conditions -> Using 6. we can rework the way we handle boundary conditions.

This is just a sketch @J15525 and I made to help move things along. @apalha @dtoshniwal Feel free to make sugestions.

Notes:

• Points 1. to 3. should be relatively small.
• Point 4. will be quite a bit of work and bound to break stuff, so it should be handled with care and not be preceeded by any big changes/new features.
• Point 5. onwards are dependent on each other but shouldn't break the rest of the code, so we can work on other things simultaneously.

[dtoshniwal]

@J15525 @apalha I forgot to ask today: is there any progress on the topology side?

[apalha]

There is step 5, that is waiting for 4. In the meanwhile I will soon start working on the trace topology. I have a draft o paper that needs to be implemented.

[dtoshniwal]

There is step 5, that is waiting for 4. In the meanwhile I will soon start working on the trace topology. I have a draft o paper that needs to be implemented.

I don't think it's necessary to wait for 4. Implementing the topology (general, traces, effect on DOF numberings, etc.) is something that can and should be done in parallel to the other changes, since Topology is going to be a more "fundamental" module than Geometry and FunctionSpaces -- it is going to be included before the other modules, and the rest will depend on functionality provided by Topology. So progress on Topology will also benefit the implementation of Step 4 in parallel. (Step 3 is essentially complete and waiting to be merged.)

[apalha]

I agree that that parts can be done in parallel and they are being done in parallel. But we agree some meetings ago that we needed to merge the geometry reordering such that we could then add topology and check it. The reason for that was that geometry would change with this rework. To check topology with geometry, would require additional functionality which would not necessarily be compatible with the changes (which we still do not know yet).

[dtoshniwal]

I agree that that parts can be done in parallel and they are being done in parallel. But we agree some meetings ago that we needed to merge the geometry reordering such that we could then add topology and check it. The reason for that was that geometry would change with this rework. To check topology with geometry, would require additional functionality which would not necessarily be compatible with the changes (which we still do not know yet).

I agree that geometry is where topology will be tested first (to start integrating it in small steps), that was indeed the idea that we agreed upon. Still, development of Topology itself and the functionality within doesn’t need geometry (which is what you are also saying) so I wanted to know what was happening in this direction because I have the feeling that this topic is a little forgotten (at least for me because I’m not involved).