| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
This reverts commit 815307e624fdb8c0ee2eefc644c9bbd8244ad7f2, reversing
changes made to 8e006230f24be02831d390eaad9b90b7a7c77d2c.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
Tools/CodeGen/CalculationFunction.m
Tools/CodeGen/Thorn.m
|
| | |
|
| | |
|
| |
| |
| |
| | |
functions into Interface.m.
|
| | |
|
| |
| |
| |
| | |
Also move NonevolvedTimelevels to KrancGroups.m
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
| |
Vectorisation needs to be explicitly enabled by setting -DKRANC_VECTORS at build time.
|
|
|
|
| |
of dgt_i(jk).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CalculationFunction.m, and fixed bug in KrancGroups
Not sure how the function containingGroups in KrancGroups.m ever
worked. It used variablesInGroup instead of groupVariables to
determine the variables present in a group. The functions are poorly
named, but variablesInGroup requires an additional argument which was
not being supplied and has a subtly different meaning.
|
|
|
|
|
|
|
| |
This source file contained a large number of functions in no
particular order. I have split them into labelled categories. I have
also removed spaces at the ends of all lines. It's probably not worth
trying to perform a diff across this commit.
|
| |
|
|
|
|
|
|
|
|
| |
The idea of sub-block grid functions was to allow a calculation to
operate differently on different sub-blocks of the domain. This was
never used, and is now achieved by calling the calculation with
arguments which specify the region of the domain to loop over. Hence,
the old sub-block code is being removed.
|
|
|
|
|
|
|
|
|
|
| |
The original implementation of finite differencing in Kranc used
hard-coded finite difference operator macros in GenericFD. It has not
been tested in years and probably doesn't even work any more. The new
implementation allows the user to create arbitrary operators and can
do everything that the old one could. As we are planning to replace
the current implementation with something more user-friendly, to
simplify the code we are removing the old method at this point.
|
|
|
|
|
| |
Having more than one loop in a calculation is never used and it
complicates the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature was never really used, and was only introduced before we
really understood what we were doing. The idea was that you could
have multiple loops in a single calculation and you might have to sync
between them. For example, in the first loop you may compute some
quantity, and in the second you might compute its derivative. This
would have to be in the second loop because otherwise it would lead to
incorrect results. However, this scheme only allows synchronisation,
it does not take account of symmetry, interpatch or physical boundary
conditions, and possibly doesn't work correctly with mesh refinement.
Anything which can be done with this scheme can be done simply by
using a second calculation, so in the interests of maintainability and
code conciseness, the feature has been removed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This allows simultaneous declaration and assignment as per Erik's
previous commit, which seems to give a noticeable performance
increase, at least with the PGI compiler on Kraken, and also allows
multiple assignments to the same variable in a single calculation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Assignment to grid functions which are differentiated in the same
calculation leads to results which are dependent on the order of the
loop over grid points, which is almost certainly not what is intended.
Kranc will now throw an exception if you try to do this.
|
|
|
|
|
|
| |
This option, which defaults to False, prevents having grid functions
on the left hand side and the right hand side in any single
calculation.
|
| |
|
|
|
|
|
|
|
|
|
| |
Mathematica's implementation of line-breaking in CForm sometimes
splits lines in the middle of tokens and adds continuation backslashes
to the end of the split line. In combination with the indentation
that we apply in Kranc, this can cause the tokens to be broken by
whitespace. This commit inhibits Mathematica's line breaking and
replaces it with an algorithm which splits lines only on whitespace.
|
| |
|
| |
|
|
|
|
| |
TmunuBase variables.
|
|
|
|
|
|
|
|
|
|
| |
Introduce new Kranc functions DeclareAssignVariable, DeclareAssignVariableInLoop, MaybeAssignVariableInLoop, DeclareMaybeAssignVariableInLoop.
Comment out all code that only declares variables.
Change all assignments to declare variables as well.
Declare all variables as constant.
Access TmunuBase grid functions only if they have storage; otherwise, assume that they are zero.
|
| |
|
| |
|
| |
|
|
|
|
| |
value of EvolutionTimelevels. This allows choosing the number of time levels that are active by default.
|
|
|
|
|
|
| |
effect as Interior, but does not synchronise the variables. This can be used e.g. to calculate the RHS terms.
Introduce a way to access grid function that may or may not have storage. If a local variable name matches the pattern "eT*L", then it is read from the corresponding grid function only if the parameter useMatter is true; otherwise it is set to zero. This is obviously intended for the TmunuBase variables. This is implemented via a new Kranc function maybeAssignVariableInLoop.
|
|
|
|
|
|
|
|
| |
Use cctk_lssh instead of cctk_lsh to loop over grid functions
Rename schedule item "apply boundary conditions" to "select boundary conditions"
Introduce parameter for number of timelevels for RHS grid functions
|
|
|
|
| |
local variables. Intel 11 does not automatically perform this conversion.
|
| |
|
|
|
|
| |
This is now controlled with an option UseCSE to CreateThorn.
|
|
|
|
|
|
| |
There is a bug in CForm which combines indentation and splitting of
identifiers, causing the output to be incorrect. This is alleviated
significantly with a PageWidth of 120, rather than 80.
|
| |
|