barrywardell/einsteinexact

A Cactus arrangement containing thorns which provide analytically computed exact solutions of Einstein's Equations.

einsteinexact's Issues

\[Theta] and \[Phi] in "Coordinates" field.

The scripts for metrics containing coordinates such as [Theta] and [Phi] fail to compile, with no error message. I assume this is the reason for not having them included in EinsteinExact.m by default. What is then the recommended way to express metrics in polar coordinates?

commit 201ad2e0e71fa19109c28955ff0bc6ccc35e2447 inverted meaning of lapsefactor

with 201ad2e a lapse factor of 0.5 and a minkoswki metric otherwise generates a metric with lapse = 2 instead of the expected 0.5. A simple fix is to apply

diff --git a/m/EinsteinExact.m b/m/EinsteinExact.m
index 31948b0..a330d1a 100644
--- a/m/EinsteinExact.m
+++ b/m/EinsteinExact.m
@@ -159,7 +159,7 @@ xformEuler = Module[{Rphi, Rtheta, Rpsi, Rot, xform},
 (* Modify lapse *)
 xformSlowdown = Module[{xform},
   xform = IdentityMatrix[4];
-  xform[[1, 1]] = 1 / lapsefactor;
+  xform[[1, 1]] = lapsefactor;
   xformSimplify[xform]
 ];

Eliminate duplicated calculations

Currently, EinsteinExact creates two calculations for each metric; one for running during initial data only, and another for running during evolution. Which of these is actually run is determined by a run-time parameter. However, these calculations are identical. It would be better to create just one calculation and have it scheduled differently depending on this parameter. Creating the calculations and compiling the resulting code can take a lot of time.

Does Cactus support the following?

Schedule -> {"in ADMBase_InitialData if ADMBase::initial_data = "<>thorn, "at ANALYSIS if ADMBase::evolution_method = " <> thorn

You can include a grid scalar in the "if" clause of a schedule string, but I suspect nothing more complicated than that.

Probably we need to add a feature to Kranc to apply a different conditional to each schedule entry. I wonder if there is a higher-level or more elegant solution to this, which avoids going down the route of making Kranc just a wrapper around all existing Cactus functionality.