Use ForwardDiff.jl to compute Christoffel symbols exactly #78
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, the collocation derivative was applied to the metric tensor components to evaluate the Christoffel symbols approximately. Since the rest of the geometric information for the covariant solver is computed analytically for the spherical shell, I would like the Christoffel symbols to also be exact. Because the expressions get quite messy when differentiating by hand, an easy way to compute them is to use automatic differentiation. Since reverse-mode automatic differentiation is not needed here and Trixi.jl already has ForwardDiff.jl as a dependency, I've used ForwardDiff.jl to do forward-mode automatic differentiation.
If the Christoffel symbols needed to be recomputed frequently (e.g. in an adaptive simulation, or for a time-varying metric), perhaps there would be an argument for coding them by hand for efficiency purposes, but, since for now they are only calculated once per simulation and stored at each node, using automatic differentiation makes the most sense to me.
Now that we are computing the Christoffel symbols exactly, the sensitivity of the covariant basis vector components described in #49 can be seen from the fact that ForwardDiff returns
NaN
s when usingGlobalSphericalCoordinates
and an even number of cells per dimension on each face of the cubed sphere, presumably due to this pole problem. The default optionGlobalCartesianCoordinates
avoids this problem, and should therefore always be used instead ofGlobalSphericalCoordinates
.Note: The test values for the spherical shallow water equations have been updated accordingly. This will therefore affect the test values for the new cases added in #73. Also note that the coveralls tests fail due to there being less code to cover now, thus leading to the percentage of covered code dropping.