| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
The latter has higher overhead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New integrator Euler. This is an explicit, first-order method, mostly
useful for debugging.
New integrators AB (Adams-Bashforth) with various orders. These are
explicit integrators using several past timelevels to provide
higher-order integration with a single RHS evaluation each.
Introduce LinearCombination, a generic routine to calculate linear
combinations of grid functions. This simplifies existing code, and can
be overloaded if MoL should run on a device (e.g. with OpenCL).
Replace cctk_lsh with cctk_ash where necessary.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@190 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
| |
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@182 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
| |
|
|
|
|
|
| |
than one map) exist on the current process
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@147 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I just encountered a weird case where evolving Minkowski with the
efficient RK4 implementation was not static. It turns out that the
reason was floating-point round-off error in RK4. During each of the
substeps, RK4 adds terms with factors of 1/3 and 2/3, and for the
final step, adds a term with a factor of 4/3. Due to round-off, these
terms do not cancel exactly, so that the time-evolved lapse is
slightly different from 1 (although all the lapse RHS terms are 0).
The same goes for the diagonal terms of the metric.
The attached patch keeps track of the round-off error when adding
these terms, leading to a more accurate integration result.
The problem described above is not always visible, but also depends on
optimisation settings.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@145 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
| |
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@129 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
| |
|
|
|
|
|
|
|
| |
arrays. This gets around the problems with the driver allocating the
scratch space differently on multiprocessors from the individual
arrays.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@116 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@113 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
