| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
the message affected evolved slow variables where it would output the currently
registered fast evolved variables instead of the slow ones.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@194 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
limit
Currently when a thorn tries to register more evolved/constrained/sandr
variables than the respective parameters allow, MoL aborts with an error
message "You have tried to register more evolved variables than the
accumulator parameter MoL_Num_Evolved_Variables allows. Check that you are
accumulating onto this parameter correctly." which is not terribly helpful in
finding out why this is happening.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@191 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
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@165 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
|
| |
number of stusteps that the time integrator performs for one time
step.
This information can e.g. used to automatically calculate the
necessary number of buffer zones for mesh refinement.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@124 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
|
| |
CCTK_SCALAR variables were rejected.
This is most likely just an oversight, since no one so far wanted to
integrate CCTK_SCALAR variables. The change is trivial.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@103 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
Correct some typos in warnings.
Remove some commented out variable declarations.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@102 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
|
| |
registered as SandR and then as evolved it was not correctly removed
from the SandR list, leading to incorrect evolution. Thanks to J
Thornburg for finding this one.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@86 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
| |
verbose, so that you have some idea which thorn did it.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@85 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
|
|
| |
properly try to register, e.g., evolved function with MoL before the
index arrays have been set up.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@83 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@71 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
|
|
| |
WARN(0,...) before the segmentation fault...
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@61 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@43 578cdeb0-5ea1-4b81-8215-5a3b8777ee0b
|
|
|
|
| |
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@32 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
|
|
|
|
|
|
|
|
|
| |
to evolved.
Add a load more debugging statements (ifdef'd).
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@21 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
|
|
|
|
|
|
|
| |
Remove old, buggy commented out stuff.
git-svn-id: http://svn.cactuscode.org/arrangements/CactusNumerical/MoL/trunk@6 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
|