- Aug 12, 2024
-
-
Sander, Oliver authored
-
- Aug 08, 2024
-
-
Sander, Oliver authored
Fix derivatives of nonconforming interpolation See merge request !158
-
Sander, Oliver authored
-
- Aug 07, 2024
-
-
Sander, Oliver authored
Fix memory access errors when density does not depend on function value See merge request !157
-
Sander, Oliver authored
Instead of with LocalGeodesicFEADOLCStiffness. The latter should be faster.
-
Sander, Oliver authored
If InterpolationDerivatives is told not to compute the derivatives for the interpolation value, then it sometimes leaves the corresponding matrix entries uninitialized. That's okay: they shall not be used anyway. However, the code still did use them: It multiplied them by zero. This is okay if the matrix entries are actual values, but they may also be NaNs. In that case, the NaNs propagate, leading to wrong results. Fix this by modifying the matrix products to really omit the uninitialized values.
-
Sander, Oliver authored
-
- Jul 11, 2024
-
-
Sander, Oliver authored
Let ADOL-C differentiate the energy density and the GFE interpolation separately See merge request !138
-
Sander, Oliver authored
-
Sander, Oliver authored
This is faster than using ADOL-C, and does not add much code.
-
Sander, Oliver authored
This will allow derived densities to implement the derivatives by hand. In some cases (e.g. the harmonic energy) these derivatives are so simple that there is no need to accept the AD overhead for this.
-
Sander, Oliver authored
Currently the user code that plugs together the assembler for a particular problems has to know that ADOL-C is used internally to compute certain derivatives. In shows because certain objects need to be instantiated with adouble as the number type. One such example is all objects derived from LocalDensity. However, if this is to be avoided, then assemblers need to have a way to turn a (e.g.) 'double' version of a density into an 'adouble' one. This commit provides this way, by adding a 'makeActiveDensity' method.
-
Sander, Oliver authored
Really more of a set of notes, currently. In particular, it describes how the element assembler works, which seems to complicated to me for having only in-code documentation.
-
Sander, Oliver authored
That construction method is simply enough that the derivatives can be computed manually. This avoids the overhead of using an AD system.
-
Sander, Oliver authored
-
The LocalIntegralStiffness assembles a tangent matrix by suitably combining derivatives of the energy density with derivatives of the geometric FE interpolation. See the detailed description in dune-gfe-manual.pdf. This patch also includes a new test in localintegralstiffnesstest.cc. It checks if the assembled matrix is the same as the one computed by LocalGeodesicFEADOLCStiffness. For a 3d Cosserat material I get a speedup of about 3x.
-
- Jul 10, 2024
-
-
Sander, Oliver authored
-
- Jul 09, 2024
-
-
Sander, Oliver authored
Fix some typos in parameterTree strings for both Riemannian-TR and Riemannian-PN & print final energy @Riemannian-pn solver See merge request !155
-
Klaus Böhnlein authored
-
- Jul 08, 2024
-
-
Klaus Böhnlein authored
-
Klaus Böhnlein authored
Remove whitespace in maxProximalNewtonSteps-string @Riemannianpnsolver (causes problem with get-method of parameterTree)
-
- Jul 07, 2024
-
-
Sander, Oliver authored
I am not too happy about this method, because for the scalar finite element is an implementation detail. But for the time being I need this method for the upcoming LocalIntegralStiffness.
-
Sander, Oliver authored
It is used by the upcoming LocalIntegralStiffness.
-
Sander, Oliver authored
It is called 'geodesic interpolation' nowadays, no matter what domain.
-
Sander, Oliver authored
Various minor fixes and improvements See merge request !154
-
- Jul 06, 2024
-
-
Sander, Oliver authored
-
Sander, Oliver authored
Previously they were returned by value, but I do not remember any actual reason for that. Return by const reference leads to a measurable speed increase when computing the derivatives of projection-based FE onto the sphere. It also fixed some undefined behavior in that code, which took const-references of the returned temporaries. Returning the coefficients by const reference is more difficult for product manifolds, because previously the interpolation rules stored the coefficients separately for each factor space. With this patch, these rules now store the coefficients twice: once in the old separate format, and once as needed for returning them by reference. Interpolation rules are not meant to exist in large numbers, and therefore I do not think that this extra space consumption matters.
-
Sander, Oliver authored
-
Sander, Oliver authored
-
Sander, Oliver authored
They were 'field_type' before, which is 'adouble' when used together with ADOL-C (the typical case). But using 'adouble' for parameters is unnecessary and wasteful.
-
Sander, Oliver authored
-
- Jul 04, 2024
-
-
Sander, Oliver authored
-
- Jun 23, 2024
-
-
Sander, Oliver authored
Fix nonconforming interpolation See merge request !153
-
Sander, Oliver authored
This broke recently (or never worked), because nonconforming discretizations were not tested anywhere. This patch therefore also generalizes harmonicmaptest to also test with a nonconforming discretization. As part of the fix, the interpolation rules get a new method `evaluateValueAndDerivative`, because the previous way to get the value and the derivative in a single call (the `evaluateDerivative` method that takes a value as an argument) only worked for the conforming case.
-
Sander, Oliver authored
This avoid two unsuccessful iterations at the beginning, and hence reduces the overall time to run the test somewhat.
-
Sander, Oliver authored
-
- Jun 22, 2024
-
-
Sander, Oliver authored
This is needed to support nonconforming discretizations.
-
Sander, Oliver authored
-
- May 29, 2024
-
-
Sander, Oliver authored
Fix: Consistent naming of parameter strings See merge request !152
-
- May 16, 2024
-
-
Klaus Böhnlein authored
-