WIP: Docs

assembly/src/include/ae108/assembly/notes.md

+### Assembler and Assembler Plugins
+- why featureplugins with assembler plugins?
+in Solvers, computeSolution functions "assembleStiffnessMatrix" are called on the assembler. Assembler needs to have those requires function as member function (there is not check like with a concept).
+
+Could also be one using free functions?
+
+- Solvers are templated on assembler and member functions are called ("assembleStiffnesMatrix")
+- if free functions, solver need to be configurable. Mixins are a nice solution but at least needs a concept to verify that assembler matches signature.
+
+Does assembler need to be a featureplugin?
+
+```cpp
+assembler<ElementConcept Element, 
+          class Policy = cpppetsc::SequentialComputePolicy,
+          template<typename> typename... AssembleFunctions
+          >
+class assembler : private AssembleFunctions<assembler<Element,Policy,AssembleFunctions...>>...
+{
+
+};
+```
+
+`this->assembler().meshElements()` makes sure that the `this` type is casted into the the correct assembler to get the right elements.
+
+Should be basically the same thing; `FeaturePlugins` is using crpt/mixins, `Assembler` is just another derived class
+
+
+#### Issues
+- Hard to see through mixin architecture
+- Solvers and assemblers are inherently coupled (namely through the methods of the plugins like `assembleMassMatrix`)
+- Assemblers (or Assembler plugins) are coupled to the elements they support. At least a concept is needed.
+- Assembler plugins are defined in a macro in order to instantiate the whole machinery
+- Solver and Assembler are coupled by the same mesh.
+
+#### Open Questions
+- How are elements assigned to assemblers? Manually?
+- Could Assembler objects be replaced by free functions configured in the solves?
+
+### Solvers
+- Compute solution of a problem using member functions of the configured Assembler(Group), e.g. `assembleEnergy`, `assembleForceVector`, `assembleStiffnessMatrix`.
+- Each solver depends on different member functions of the Assembler(Group).
+
+
+#### Improvements
+- Solver could use functors, function objects to trigger the assembly instead of typedefs. This would requires to store the elements of the assembler some where or mark them in order to pass them to the correct assembler.
+
+
+### 
+```cpp
+class Assembler : public FeaturePlugins<AssembleEnergyPlugin, StiffnessMatrixPlugin>::type{};
+
+class FeaturePlugins : Plugins<Assembler>...{
+};
+
+// Plugins is a concrete plugin
+class AssembleMassMatrixPlugin : FeaturePlugin<Assembler, AssembleMatrixPlugin>{
+
+  void AssembleMassMatrix(){ // interface function
+    if constexpr (IsGroup<>){
+      std::apply(...); // apply over group
+    }
+    else{
+      execute(); // impl function
+    }
+  }
+
+};
+```
+
+in solver, `AssembleMassMatrix` is called directly? 
+
+- DefaultFeaturePlugins:
+ - `assembleForceVector`: used in solvers for RHS. Used in all solvers?
+ - `AssembleStiffnessMatrixPlugin`: used in most solvers
+ - `AssembleEnergyPlugin`: used in TAO
+ - `UpdateInternalVariablesPlugin`: ?
+
+
+### Assembler Group?
+
+Assemblers work on one type of element. If there are different types of elements, different assemblers are needed. In order to have a unified interface (tbc), the `AssemblerGroup` was created. Elements still need to be added to the correct assembler of that group.
+
+
+
+
+#### Issues
+- `AssemblerLike` Concept seems to fail because of missing `value_type`?
+
+#### Questions
+- Does AssemblerGroup dispatch the `assembleEnergy` function calls correctly to Plugins correctly?
+- Not sure if the interface holds for all `Assembler` types in the `AssemblerGroup`
+
+#### Improvements
+
+
+
+### TODOs:
+
+- Add Assembler concepts to solvers: documents/ensures solver types
+- Simplify Assembler plugins:
+  - Switch between group and non group assembler
+  - add assembler method (unique, matching concept)
+  - ``this->assembler().meshElements()` needs to work correctly?
+
+
+```cpp
+template<ElementLike Element>
+class EnergyAssemblerPlugin{
+  void assembleEnergy()    ;
+  void emplaceElement(AnnotatedElement e);
+
+  
+};
+
+
+template<typename ...Plugins>
+class EnergyAssembler{
+  void assembleEnergy();
+
+  template<int N>
+  auto getPlugin();
+
+};
+
+auto energyAssembler = EnergyAssembler<EnergyAssemblerPlugin<Element>, EnergyAssemblerPlugin<ForceElement>>{};
+
+
+// Each plugin still depends on a specific element type. Elements that shall be used
+// the assembly need to be addded to the corresponding plugin
+// 
+// The key difference between an AssemblerGroup and the new Assembler are that the former work with the
+// same elements for all plugins but the method the plugins provide may be different.
+// The latter will work on different elements but provide the same method (i.e. assembleEnergy).
+assembler.getPlugin<0>().emplaceElement(Element{});
+assembler.getPlugin<1>().emplaceElement(ForceElement{});
+
+
+// No assembler (template) argument in constructor anymore
+// Make depency on poligy and mesh explicit
+auto solver =  Solver::NonLinearSolver<Policy, Mesh>();
+
+// Explicit usage of specific assembler types enforced by concept
+// - EnergyAssemblerLike: has function assembleEnergy
+// - ForceVectorAssemblerLike: has function assembleForceVector
+// - ...
+solver.computeSolution((..), energyAssembler)
+
+```
+