| Commit message (Collapse) | Author | Age |
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@202 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
this is to allow bit-wise recovery of Hydro data since con2prim runs in MoL_PostStep. Also we should be able to read in all data from a checkpoint and thus mol_poststep should not be required. Thorns that want to be clever and re-compute some quantities that can be recomputed from the checkpointed data should schedule themselves explicitly in Post_Recover_Variables.
See extensive discussion at https://trac.einsteintoolkit.org/ticket/1256
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@199 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
| |
This can be used as performance improvement, if timelevel cycling is
also modified to perform this copy instead.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@196 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
boundary conditions (and synchronization, and prolongation)
to the initial data.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@181 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
| |
Flags indicate whether it is time to execute slow RHS computation.
For instance, in the RK4-RK2 scheme, there are 4 substeps in total, but the RK2 RHS are only evaluated in the very first and in the very last step of the four substeps.
From: Christian Reisswig, minor changes by Roland Haas
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@175 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, MoL initialises the RHS variables to zero before calling
the CalcRHS routines. This is (a) superfluous in a well-written code,
and (b) makes it impossible to re-use a RHS that has been calculated
ahead of time, e.g. at the end of the previous time step.
This patch adds a parameter to disable this behaviour.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@173 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@120 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@113 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
| |
This integrator is similar to the existing RK45 integrator. It also
supports adaptive time stepping, but uses slightly different
coefficients. The Numerical Recipes say that it has "slightly better
error properties".
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@110 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
As yet not altered to do grid arrays.
As with RK45, adaptive timestepping does not work with mesh refinement.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@106 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://www.cactuscode.org/pipermail/developers/2005-March/000815.html
add a new parameter copy_ID_after_MoL_PostStep to control precisely
*when* in CCTK_POSTINITIAL MoL_FillAllLevels is scheduled
if initial_data_is_crap is set.
The default (MoL_FillAllLevels is scheduled *before* MoL_PostStep)
matches the previous behavior, so there's no change required to par
files unless you want the new behavior (MoL_FillAllLevels is scheduled
*after* MoL_PostStep).
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@87 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
| |
Note that if you want to use this with Carpet you currently have to
use the development (darcs) version of Carpet together with the
parameter
carpet::adaptive_stepsize = "yes".
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@82 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fourth order accurate evolution with an additional fifth order step for error estimation. How much sense the error makes is unclear to me, but hey.
For the moment the error is stored in an internal MoL array ErrorEstimate; there is one per evolved variable. At a later point this may be moved out to user thorns who can register their own etc.
As the implementation uses 6 evaluations of the RHS (necessary) and 6 levels of scratch space (one more than necessary - laziness kicked in) then this is very expensive.
This is a partial fix for PR/1840.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@74 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
| |
Agrees with other RK3's to floating point round off (except at
boundaries) for linear case. Uses more storage and is slower than
standard RK3 so I don't recommend it.
This showed up (so I fixed) a bug with the generic methods when used
with Carpet.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@72 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
| |
report the names of all registered variables. Closes PR 1771.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@69 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
direct through the header file.
Add parameter to say if we want to use this function (by default we do, so nothing changes).
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@56 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@45 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@39 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@34 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
| |
RK3. The optimized version of the TVD RK3 solver. Requires no scratch space so is about as efficient as ICN, but third order.
Generic method from a parameter table. By specifying the number of intermediate steps and the alpha and beta arrays, create your own method at parameter time. Not well (or at all) documented because it doesn't seem to work correctly at the moment.
Some tidying of extraneous code as well.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@29 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
| |
steps are always at t+dt.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@24 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
| |
the default but should have no effect).
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@23 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
| |
MoL. Don't know why I did this in the first place.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@15 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
| |
To use the complex variable stuff right now you need to uncomment the appropriate groups in the interface.ccl and #def MOLDOESCOMPLEX in the appropriate files. It still probably won't work.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@13 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
Only works with ICN or RK2 for now - in fact this commit may break the generic RK methods temporarily.
Note the documentation isn't quite right - there's no longer a seperate function for each different type...
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@12 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
| |
Change the grid scalar used in the schedule.ccl from MoL2->MoL (necessary).
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@4 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
MoL provides generic integration methods for multiple thorns simultaneously. By providing a layer between the driver and evolution thorns, this should mean that some technical issues to do with mesh refinement can be ignored. It also allows you to choose different evolution methods (in time, at least). But the primary purpose is to unambiguously evolve models in different thorns at the same time.
This is version 2 - the one that will work with mesh refinement. It's a straight copy of HawkeCVS/Public/CactusMoL2/MoL2 and I haven't checked that it will work "as is" with the new name (one of the reasons it goes into Alpha).
At the moment the only evolution method guaranteed to work with mesh refinement is ICN, although RK2 should. The generic RK methods will do something that will be subtly wrong...
Note that the "old" way of registering variables (through the functions declared in header files) is still there. As soon as function aliasing settles down, this will be removed.
Also to be done:
Better documentation
Tidy up the code (especially the debugging statements)
Optimize
Add various useful time evolution methods.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@2 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|