Problem
The gsExprAssembler enables several nice features over the gsAssembler.
However, for the gsThinShellAssembler the expressions are set in stone, especially when the material behaves as a black-box.
Currently, to perform an assembly using some extra options (i.e., weak BCs, pressure, residual) various assemble functions are called. In every call, the assembler is initialized.
In general, the thin shell assembler needs speed over flexibility in terms of expressions
Solution
To optimize the expression assembly, I would suggest to write big expressions that directly provide the full expression for matrices and vectors as a single expression. In this way, loops over actives, etc., can be done in (almost) one go.
We have to see if we can create the following:
template <short_t dim, class T, bool bending>
matrix_expr<dim,T,bending> matrixExpression(const gsFeSpace<T> & u, const gsGeometryMap<T> & ori, const gsGeometryMap<T> & def, const gsMaterialMatrixBase<T> * material);
template <short_t dim, class T, bool bending>
residual_expr<dim,T,bending> residualExpression(const gsFeSpace<T> & u, const gsGeometryMap<T> & ori, const gsGeometryMap<T> & def, const gsMaterialMatrixBase<T> * material);
//...
A.assemble(matrixExpression(u,Gori,Gdef),residualExpression(u,Gori,Gdef));
Inside the expressions, the material evaluators should be able to use the gsMapData objects from Gori.data() and the parse of the expressions should steer the pre-computation of these maps correctly.
Note on verification: Since we will write new expressions, it would be good to make unit tests to check the equivalence of the old and the new expressions.
Problem
The
gsExprAssemblerenables several nice features over thegsAssembler.However, for the
gsThinShellAssemblerthe expressions are set in stone, especially when the material behaves as a black-box.Currently, to perform an assembly using some extra options (i.e., weak BCs, pressure, residual) various assemble functions are called. In every call, the assembler is initialized.
In general, the thin shell assembler needs speed over flexibility in terms of expressions
Solution
To optimize the expression assembly, I would suggest to write big expressions that directly provide the full expression for matrices and vectors as a single expression. In this way, loops over actives, etc., can be done in (almost) one go.
We have to see if we can create the following:
Inside the expressions, the material evaluators should be able to use the
gsMapDataobjects fromGori.data()and the parse of the expressions should steer the pre-computation of these maps correctly.Note on verification: Since we will write new expressions, it would be good to make unit tests to check the equivalence of the old and the new expressions.