| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
This is the same as ML_BSSN_sgw3d_harmonic apart from using conformalMethod = 0 instead of conformalMethod = 1.
|
| |
|
|
| |
This makes the test pass on my laptop
|
| |
|
| |
This corresponds to a change made in Coordinates previously
|
| |
|
| |
This is unfortunately necessary because nothing currently initialises the intersection of the outer and interpatch boundary on the initial data. This would need a modification to Kranc to call certain routines twice.
|
| |
|
|
|
|
|
|
| |
* Enable dissipation after parameter default change in 129cc3ba1a89b8336ffa0355fc74c2f1b60e8255
* Remove memory limitation as it seems to cause a segfault
Existing test data should be OK. O8 test passes, multipatch test fails, possibly due to a change in grid structure in Llama.
|
| |
|
|
| |
This reverts commit 76d692d840e042006df4b2355ecdf506f6b3d1d6.
|
| | |
|
| |
|
|
|
|
|
| |
These are modifications of existing testsuites, adapted to use
EinsteinExact in place of Exact. I have checked that in both tests
for all variables the Exact equivalent agrees with/converges at
the appropriate order to the EinsteinExact solution on iteration 0.
|
| |
|
|
|
| |
This parameter was unset before, so the default was used, and the
default has now been changed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
For those tests which use Exact, the extrinsic curvature is computed using finite differencing. With a small timestep, this is very sensitive to roundoff. The timestep can be increased by using fourth order finite differencing, which we do here. In order to form robust regression tests which give consistent results on different machines, we also run with an unphysically large timestep in Exact. This is OK for a regression test, but note that the constraint violations will not converge away with the evolution grid spacing.
|
| |
|
|
| |
The ML_BSSN_MP_O8_bh test still fails with NaNs in the outer boundary, probably due to the issue with setting points which are both interpatch and outer boundary, so those test results are not being committed and still fail.
|
| | |
|
| |
|
|
| |
The test mechanism checks for NaNs, and if you terminate the run, variables which are unrelated to the NaNs will show up as different in the test analysis because they have not been output on all iterations.
|
| | |
|
| |
|
|
|
|
| |
It was only the tests which were wrong.
This reverts commit 05347a08d0c9bd2a87846ab4ad8990fe26274a4a.
|
| |
|
|
|
|
|
|
| |
These are causing NaNs when run with poison. I don't know if this is
due to the tests or the code, so I am reverting the commits from
863a3e5b25e7150148f9d2b60b4b362628c675f7 to
2725eb1eb32525486df76a3686f8e550155c8e0c while the problem is being
diagnosed.
|
| | |
|
| |
|
|
|
|
|
| |
The Jacobian gridfunction groups are no longer hard-coded into McLachlan, and the Coordinates thorn is no longer inherited. Instead, the user must use GenericFD parameters to specify the Jacobian to use. The new Kranc Jacobian implementation allows a single map to be specified on which the Jacobian is not applied, which greatly improves performance in typical multipatch simulations. To use the new Jacobian method with Llama, set
GenericFD::jacobian_group = "Coordinates::jacobian"
GenericFD::jacobian_derivative_group = "Coordinates::jacobian2"
GenericFD::jacobian_identity_map = 0
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Exact thorn uses finite differencing to compute the extrinsic
curvature rather than using the analytic result. The step size used
is independent of the Cactus grid. Using a very small step size for
accuracy can lead to the subtraction of floating point numbers which
are very close to each other, leading to a large loss of precision.
This loss of precision can amplify differences between compilers and
optimisation settings.
A recent Exact commit implements 4th order differencing and a
configurable step size. Hence for a given finite differencing error,
a larger step size can be used, reducing the loss of precision.
This commit to the McLachlan testsuites (parameter files and data)
implements this change by enabling 4th order differencing and a step
size of 2e-4. A convergence test in the step size has shown that this
leads to a finite differencing error of ~1e-14. It also leads to more
consistent results across compilers and optimisation settings. The
data was generated with gcc using -O2 and the testsuites pass with
the Intel compiler also using -O2.
This testsuite data also takes into account the modification to the
constraint boundary condition in the previous commit.
|
| |
|
| |
The current Cactus testsuite mechanism does not allow you to set per-variable absolute and relative tolerances. The constraints are typically very small in comparison to the evolved variables used to compute them. This means that roundoff errors in the evolved variables can lead to large relative errors in the constraints. The correct solution would be to specify only an absolute tolerance for the constraints, but this is not possible at the moment. In future, a separate test could be written to test that the constraints are being correctly computed on constraint-violating initial data. For now, we omit the tests of the constraints from the testsuites.
|
|
|
For some reason, this test only passes when run with
OMP_NUM_THREADS=1. If you use OMP_NUM_THREADS=2, or leave it unset on
a multi-core machine, there are differences above tolerance in the
Hamiltonian constraint, though the evolved variables are OK.
|
