[draft] A draft for local assembler interfaces.

added discussion label

How to handle the case that both local views are the same? Then we might want to bind only once but the local assembler needs to be "informed" about that case.

If we have two separate methods for binding the local-views, it gets a bit harder to check whether both are identical (e.g. refer to the same object). Do we want to specify an order in which the bindxxx are called? (I would say: no)

Maybe it is better to have a bindLocalViews function that gets all local-views in a defined order as arguments, or even a tuple / named struct with all local-views. (Then the order is determined by names)

Is the local-view that is passed into this bind method already bound to an element? The state of the local-view should be clearly communicated.

I would say no. There's no reason to do this.

How is the "cache" passed to the local assembler? In the bind(LocalView) method provided by the LocalView?

As mentioned earlier, I would separate the question of caching from the local assembler interface. At this level I would say, that the local assembler is responsible for managing its own cache.

But one may implement a special local assembler that provides a cache and has it's own higher level interface for local assemblers based on function evaluations.

Is this "LocalMatrix" here a single-element matrix, or a combination of all 4 matrices, e.g., a Matrix<LocalMatrix,2,2>?

This depends on what the assembler should do. But I would say, that it's never a single element matrix. It's should be one of the following

• A 2x2 block matrix for a two-sided coupling.
• A 1x2 matrix for a one-sided coupling. This would be the first row of the above.
• Only the two off-diagonal blocks of the two-sided coupling (ignoring intra-element coupling)
• Only one off-diagonal blocks of the one-sided coupling (ignoring intra-element coupling).

While we only have a single, non-blocked (rectangular) matrix in the latter case, it's not an element-matrix, because it contains the coupling between two elements.

Also here, all 4 local-views could be identical. How to recognize this situation? Is the local-assembler responsible for this optimization or can be pass this info somehow to the local-assembler. In AMDiS I have introduced a LocalViewPair that binds the local-views only once to an element. But this is not enough here, since the local-view are used by the assembler and not vice versa.

In fufem we used the following approach:

The global assembler always passes two (for the skeleton 4) local views. But if test- and trial-basis are the same, it uses the same one for both roles. When the local assembler creates caches on bind*LocalView() it can detect this and only use a single cache.

Who is responsible for binding the local-views to the element? Do we assume that this happens in the global assembler? Or is this also the task of the local-assembler? IF the latter, we need a mutable reference to the local-views passed in the bind-local-view methods.

If the local-views are already bound to an element before calling this function, the element is also given directly by the local-views. Then, maybe, this bind methods should be to something else? Or is it just an initialization method?

IMO the whole design is based on the assumption that the global assembler must bind the LocalView. This way e.g. the check if we need to bind one or two (Galerkin or Petrov-Galerkin) is centralized. This is also central for easy composability of several local assemblers.

Also the local assembler might not even use the local view, e.g. if it does a plain copy of a precomputed local matrix (for structured grids). Then it would be strange to require that the local assembler binds it, because the global one needs a bound LocalView later on to access the global indices.

mentioned in merge request !2 (closed)

merged manually