ianhinder / kranc Goto Github PK

It is currently not possible to specify the finite differencing operators used by a calculation at runtime. At the moment, one can use Mathematica to generate multiple copies of a calculation, each with a different set of FD operators (i.e. different FD schemes). This generates multiple source files which all need to be compiled. This is inelegant and takes a lot of time during compilation.

We could instead have a conditional at the start of the calculation which selects which FD operators to use to compute each derivative. This was not done before because we thought there might be a performance hit from a conditional at every point in the loop, but this might not be an issue on modern systems, especially if you can indicate to the compiler that this variable does not change in some sense.

In a calculation, we currently have "named derivatives". A finite differencing "scheme" would be a mapping of these named derivatives to finite differencing operators. We could give each scheme a name, and the user specifies the mapping. We could then allow the user to specify a scheme for the whole thorn in the parameter file. Additionally, this could be overridden on a per-calculation basis, for example to use a different scheme for some calculations.

Kranc currently assumes that the grid is three dimensional. We might want to write a code which is 1D or 2D, and Kranc should not make this asumption. In order to be useful, the finite differencing operators would also have to be modified to not make the 3D assumption.

The function LinearEquationsToMatrices has been deprecated for several versions now:

General::obspkg:
LinearAlgebraMatrixManipulation
is now obsolete. The legacy version being loaded may conflict with
current Mathematica functionality. See the Compatibility Guide for
updating information.

DeveloperLinearExpressionToMatrix::obs: DeveloperLinearExpressionToMatrix has been superseded by CoefficientArray
s, and is now obsolete. It will not be included in Mathematica version 8.

We should use CoefficientArray instead.

Split McLachlan's calculations semi-automatically in two ways: (a) by variable, so that e.g. dot[g] and dot[K] are calculated separately, and (b) by pattern, so that advection terms, dissipation, and "everything else" are calculated separately. Also introduce parameters to choose which routines are called at run time.

This was #582 in the Einstein Toolkit Trac.

Currently non-evolved variables are scheduled manually. Typically their boundary conditions (especially symmetry boundaries) are not applied, nor are they prolongated.

Calculations of non-evolved variables should be scheduled in the group MoL_PseudoEvolution which is in EVOL. This means that they will be prolongated. Each calculation should have its own schedule group, and in this group will be scheduled both the calculation and the boundary condition group for that calculation.

Allow registering additional attributes for grid functions. This would be used to e.g. set or unset the checkpointing tags. Maybe this should be done automatically? If so, based on what criterion?

If possible, it would be good to have Kranc perform computations on grid arrays in addition to grid functions. This opens up the possibility of performing computations on 2D surfaces, for example horizons.

If a division of two constants is found in a calculation, it is replaced with a predefined version. So for example -1/(60.*dz) is preassigned to a variable pm1o60dz. Currently, not only expressions which are found in the RHSs directly, but in any of the finite differencing operators, are created. This should be restricted to those actually used in that specific calculation. The current behaviour should be harmless as the assignments are performed outside the loop, but they lead to warnings with gcc which obscure other errors.

xTensor is a much more advanced tool than the minimalist (though working) tensor code that we currently have. We should support both tensor packages through a generic abstract interface. There is an xTensor branch on which this feature is being developed.

At the moment, Kranc expands tensorial quantities in an outer wrapper function. This simplifies the code, as the inner levels don't have to know about tensors. However, it means that the lower levels cannot give intelligent error reporting, or perform optimisations (such as loops) based on this structure.

The code should be changed so that the tensor structure is kept all the way down, and only expanded at the very end when this is necessary.

The kranccode.org Kranc web site does not have a pointer to the github issue tracker (nor to the github site in general).

It is common to use keyword parameters to schedule different functions, e.g. for initial data. If this is the case, Kranc should check that all possible keyword values are handled.

This could also be implemented in a higher level by generating the keyword parameter definition automatically from annotations and scheduling directive in calculations.

Cactus supports restricting the allowed range for user parameters. This should be made available to Kranc users. Currently, this is implemented for keyword parameters. There is an AllowedValues key in the parameter structure for this, but it only works for keyword parameters. It is also used for integer parameters when generating special-case code for finite differencing operators, but there is not currently any check that the user actually specified an allowed value.

When you use variables from another thorn, you don't know that they have been given storage. Kranc could check this, and that there are the expected number of timelevels, earlier on in the run than when they are first written to, which would presumably result in a segfault.

Kranc declares a set of constants that may or may not be used in the generated code. If they are not used, they generate compiler warnings about unused variables. This can be prevented by using CCTK_DECLARE_INIT to declare these constants, which uses a system-specific way to suppress warnings about unused variables.

This happens because execution never gets as far as RunKranc.m, and Mathematica does not return nonzero unless you specifically tell it to using Quit[code]. We need to find some other way of detecting this failure in the kranc script. For example, we could make RunKranc.m write a specific file on successful completion, and only if this file is present will the kranc script return 0.

The last patch to the main branch of Kranc breaks thorns whose Kranc scripts designate a tensor as SymmetricDecreasing. The sorting action included in DeleteDuplicates breaks the order of tensor component declarations in the resulting interface.ccl file for these tensors. Is this really necessary?

Currently, if you want even symmetry BCs to be applied, you need to specify parameters for the boundary conditions of the evolved variables. It is very easy to forget to do this, and then symmetries are not applied. If we change the default from "skip" to "none", then users won't need to worry about this parameter.

Support multi-argument Max and Min calls in Kranc.

Kranc was originally designed to generate Cactus thorns using either C or Fortran. Partly this was to show how automated code generation could be used to do something like this, and partly because there was a belief that maybe Fortran could be faster in some situations than C.

Kranc is now used exclusively with C, and the Fortran code has not been maintained or updated for many years, and almost certainly does not work correctly.

To make things simpler in the code, we could remove the support for multiple output languages and standardise on C.

Mathematica 8 includes a new feature called "symbolic-C" for representing C code. We could replace much of CodeGen.m with this, but this would introduce a dependency on Mathematica 8.

There is a lot of code in Kranc which is commented out, badly formatted, badly named, or redundant. This should be tidied up.

Currently, an error in a calculation is reported along with the offending calculation, which leads to a huge amount of output.

Error reporting should be improved so that only the offending line in the calculation is reported. Line numbers will be difficult to get, as the entire MMA script is loaded into MMA using Get[...]. In principle we could load it in line-by-line and try to identify lines with calculations, but this is probably too difficult. It should be possible to identify "equation 4 in calculation " and to print just that equation. Or "the Shorthands entry of calculation etc".

Linked to this is the fact that these errors should show the tensorial version of the calculation, but this depends on the tensor version being available at the low levels of Kranc.

Kranc currently deletes the generated thorn and replaces it with the new version. This causes the CCL files to have a different datestamp, and the CST to be re-run. In many cases, this is unnecessary and takes a lot of time.

We could instead keep the old version of the thorn, and only update the files if they have changed. This should lead to the minimal amount of recompilation. This could be done by writing a temporary version of each file and using an external diff tool to see if the new and old versions are the same. If they are the same, just remove the temporary. If they are different, replace the original with the temporary. There might be a problem with spawning many versions of "diff". Should investigate if diff can be given pairs of files to check on a single invokation.

Given the stencil size of the operators being used in a calculation, check that the ghost_size is sufficiently large to accommodate it. This will help to prevent user error.

Teach Kranc that certain grid functions may have predicates. They can only be accessed if a certain parameter or grid scalar is set; otherwise, these grid functions cannot be accessed are are assumed to have the value zero.

This is useful e.g. for TmunuBase.

We currently get the error

Set::wrsym: Symbol Quiet is Protected.

when running Kranc. We should use another symbol instead.

Mathematica offers parallelisation features that essentially allow independent calculations to be performed simultaneously in different threads. This could be used to speed up Kranc by evaluating different calculations simultaneously.

This would be used to register the ADMBase variables as constrained.

The attached Kranc script, which is very similar to the sample script SimpleWave.m, produces duplicate definitions for the Cactus parameters phi_bound_scalar etc. These parameters are generated automatically by Kranc.

Some parameter settings are inconsistent with others, e.g. certain combination of gauge parameters. Kranc could offer a way to detect these in the paramcheck bin. For example, one could specify such conditions as an If statement that Kranc then evaluates in paramcheck.

This would be used to register the "slicing condition" with CoordGauge.

We recently discovered that the current version of Kranc requires at least Mathematica version 7. We should define a Mathematica version with which Kranc is guaranteed to run. Features from newer versions should only be used if we are willing to stop supporting older Mathematica versions.

It would be useful to be able to access the values of other thorns' parameters. There is currently some logic for "friend" thorns, but it doesn't seem to be implemented fully.

An error in registering boundary conditions should be fatal. I believe it used to be fatal, and has now become a warning. An error in applying boundary conditions usually indicates a severe inconsistency either in variable declarations and scheduling, and should abort the code.

These would be keyword parameters in Cactus, but would be translated to enums outside the kernel loop, so that one can use efficient switch statements inside the kernel.

In the original version of Kranc, we provided several example thorn scripts. These were removed when the API changed drastically, but should be reinstated with the new API.

The documentation has been out of date for some time. Before making another release, it should be updated. It should describe all the options that are implemented in the code.

Mathematica can compile Mathematica expressions and export the result as C. It has features such as common-subexpression elimination built in. We should investigate if this can give a performance improvement.

In the current version of Kranc, the user needs to group the evolved variables into named "groups" which become Cactus groups. Most users of Kranc are using tensorial variables, and Cactus requires (for symmetries to work correctly) that each tensor is in its own group. As a result, there is no reason for the user to have to specify groups, as this could be automatically determined from the tensors. Removing the need for users to specify groups would simplify the interface and make it easier to use.

We would still need group information for variables from other thorns.

Kranc currently assumes that the variables it reads and writes are valid pointers. Sometimes they will not be as storage isn't allocated for them. Each calculation could contain a check that all the variables being read or written are non-NULL.

A second covariant derivative of a tensor of rank > 0 leads to a partial derivative of a Christoffel symbol. These are usually shorthands, and cannot be differentiated numerically.

Currently the directory structure of Kranc is quite inconvenient. Mathematica packages are located in several different places, necessitating multiple entries on the $Path variable. The directory structure was designed to be generic and extendable, but this is probably not necessary.

The structure should be changed to be more friendly. We can in future rearrange it if it becomes necessary. For example:

kranc/
doc/
All documentation
bin/
Script for invoking Kranc
mma/
All Kranc Mathematica packages in a single directory
support/
GenericFD and other support thorns
examples/
Mathematica scripts, parameter files, generated thorns, example output for the example thorns

It is currently quite cumbersome to specify finite differencing operators. It should be possible to define finite differencing operators in an intuitive and conventional way.

These would be better than integer parameters that one has to set to 0 or 1.

Allow adding schedule groups to simplify scheduling of e.g. evolution code and boundary conditions.

Allow specifying where the auto-generated routines (boundary selection and application) are scheduled.

This may be subsumed under the "boundary conditions for non-evolved variables" issue.

Kranc should output its directory and branch when it runs. This should go to the screen, and probably also to the generated thorn's README or a small source file. This may help prevent surprises if people accidentally run the wrong version.

(Requested by Erik Schnetter in https://trac.einsteintoolkit.org/ticket/698)

Currently there is no way to constrain the possible values of parameters. It should be possible to specify the ranges that are eventually used in the param.ccl file, and also to specify customised inequalities which can be checked programatically in ParamCheck. (Request from Tanja Bode)

Allow calling self-made boundary conditions, e.g. the NewRad boundary conditions implemented in LSUThorns/NewRad.

This would probably be superfluous if the one-sided differencing near outer boundaries were implemented correctly, so maybe this should be the issue instead.

It would be nice if Kranc allowed defining tensor quantities globally, such as e.g. gu[ua,ub] or Rt[la,lb]. In this way, they would need to be defined only once, not once per calculation, and their different definitions could not become inconsistent.

This would in the end also allow replacing the "equations" of a calculation with just the list of quantities to be calculated, as their definitions would be available elsewhere.