- Mar 19, 2024
-
-
Sander, Oliver authored
Together with the new test, this commit also contains a number of fixes for the SurfaceCosseratEnergy class. This class was not unit-tested previously, and unintentionally I messed it up badly during my recent modernization work. Finally, SurfaceCosseratEnergy had apparently never been tested without dune-curvedgeometry, which is however only an optional dependency. The commit therefore also adds the necessary conditionals. Then problem then is that the derivative of the outer normal of an intersection is not available from the standard grid interface. If dune-curvedgeometry is not available, this derivative is simply set to a zero matrix. Depending on the grid manager this may not actually be correct, though.
-
- Feb 12, 2024
-
-
Sander, Oliver authored
CollectiveCommunication has been deprecated for a while, and has recently been removed from dune-grid.
-
Sander, Oliver authored
They do the same thing, essentially.
-
- Feb 07, 2024
-
-
Sander, Oliver authored
This is what the non-mixed ADOL-C assembler does, and I want to merge the two.
-
Sander, Oliver authored
Both classes are meant to do the same thing.
-
Sander, Oliver authored
This makes the interface more consistent.
-
Sander, Oliver authored
-
Sander, Oliver authored
-
Sander, Oliver authored
These two exist in base classes, and they are inherited anyway.
-
Sander, Oliver authored
This allows to get rid of a lot of (all) multiple inheritance.
-
Sander, Oliver authored
Previously, LocalEnergy would accept an arbitrary number of template arguments, and (with the exception of the first one) they would be interpreted as the factors of a product target space. This patch replaces this template list by a single template parameter, which has to be ProductManifold if a product space is desired. This has implications throughout the code. In particular, there are now two energy methods: One that still accepts coefficients sets in the form std::vector<TargetSpace> and a second one which accepts TupleVector<std::vector<Factors>...> The second one really only makes sense for product manifolds. However, as the 'energy' methods are pure virtual, they cannot be disabled by SFINAE or C++20 concepts. Therefore, the second 'energy' method exists always, accepting TupleVector<std::vector<TargetSpace> > if TargetSpace is not a product.
-
Sander, Oliver authored
-
Sander, Oliver authored
In the long run this is cleaner than setting up the type in the LocalStiffness class itself.
-
Sander, Oliver authored
This will later simplify merging the mixed and non-mixed versions of the assembler code.
-
Sander, Oliver authored
The rest of the HarmonicEnergy class is now independent of the density. It is functionally equivalent to the LocalIntegralEnergy class, and shall be replaced by that eventually. However, LocalIntegralEnergy still has the deformation/rotation-split hard-coded in a few places, and that needs more work.
-
Sander, Oliver authored
Currently, Cosserat materials are hard-wired in the interface. This patch changes the interface a little bit towards being more general.
-
Sander, Oliver authored
That's another step closer towards merging the MixedLocalGeodesicFEStiffness and the LocalGeodesicFEStiffness. Also, it is necessary to be later able to generalize the code for product spaces with more than two factors.
-
Sander, Oliver authored
-
Sander, Oliver authored
It is deprecated, and not used anymore.
-
Sander, Oliver authored
... rather than two separate spaces. This is one step towards getting rid of it altogether.
-
Sander, Oliver authored
-
- Feb 05, 2024
-
-
Sander, Oliver authored
-
Sander, Oliver authored
... regarding ambiguous logical expressions.
-
- Jan 19, 2024
-
-
Klaus Böhnlein authored
-
- Jan 15, 2024
-
-
Sander, Oliver authored
-
Sander, Oliver authored
The ProductManifold class generalizes RigidBodyMotion, and can do everything that the RigidBodyMotion class can. Therefore there is no point in keeping RigidBodyMotion any longer. Having two implementations for the same thing will just confuse people.
-
Sander, Oliver authored
It contained code for mixed-dimensional domain decomposition algorithms involving Cosserat materials. This code has moved to a separate modul 'dune-gfe-coupling' a long time ago, and it is not used from anywhere else in dune-gfe.
-
- Jan 08, 2024
-
-
Sander, Oliver authored
-
- Jan 07, 2024
-
-
Sander, Oliver authored
-
- Jan 05, 2024
-
-
Sander, Oliver authored
-
- Jan 02, 2024
-
-
Sander, Oliver authored
They should be installed, but since dune-gfe doesn't have any downstream dependencies, nobody has missed the files yet.
-
Sander, Oliver authored
It was essentially a reimplementation of Rotation::orthonormalFrame, just with a different interface. It was not directly used by any code.
-
-
- Nov 23, 2023
-
-
Lisa Julia Nebel authored
-
Lisa Julia Nebel authored
-
Lisa Julia Nebel authored
-
- Oct 30, 2023
-
-
Lisa Julia Nebel authored
-
- Oct 27, 2023
-
-
Lisa Julia Nebel authored
-
- Oct 26, 2023
-
-
Lisa Julia Nebel authored
-
- Oct 04, 2023
-
-
Lisa Julia Nebel authored
Divide the regularization parameter through the scaling parameter in the PN solver instead of multiplying In the PN solver, we add identity*regularization/scaling to the stiffness matrix. This has two effects: - make the system matrix positive definite - penalize large corrections to ensure an energy decrease in each step The regularization parameter is adapted if either the system matrix is not positive definite if there is an energy increase. This works similar to the trust-region radius in the TR solver. The correction must be inside the trust-region, this ensures there is an energy decrease in each step. For each component of the correction, the trust-region radius as well as the regularization parameter is multiplied with a scaling factor, because the correction for the displacement works depends on the grid size where the correction for the rotation does not. To align the effect of the scaling parameter, we need to divide through the scaling parameter in the PN solver and multiply with it it in the TR solver.
-