Forcing an exact solution

We have been unable to locate any one-dimensional exact solutions to Einstein’s equations incor- porating a fluid (even for the test-fluid approximation) for a non-Minkowski space-time (in Cartesian coordinates), and so we use a different approach. The intention is to test the algorithm on the evolution of a fluid in a non-Minkowski regime. The flux terms are fairly straightforward, with little difference between those for Minkowski space and the general metric case. The source terms, however, require a large amount of calculation, and could well be the source of errors.

One approach to testing these is to implement a forced exact solution to Einstein’s equations. This technique can be applied to any system of equations, and can be used to track down coding errors.

Given a general set of PDEs of the form

∂u

∂t +∂Fⁱ(u)

∂xⁱ =S(u), (5.2)

we can take an analytic functionuexact(xⁱ, t), and define R(xⁱ, t) =∂uexact

∂t +∂Fⁱ(uexact)

∂xⁱ −S(uexact). (5.3)

We now know that the functionuexact(xⁱ, t) is an exact solution of the set of PDEs

∂u

∂t +∂Fⁱ(u)

∂xⁱ =S(u) +R(xⁱ, t), (5.4)

and therefore, if we incorporate the extra source termR into our code, we can check to see whether our calculation ofR, usually generated using software such as Maple^TM, agrees with that ofF andS. We can test fluxes and sources separately, as we use Maple^TM to calculate both exact fluxes and exact sources, so that the exact flux term can be combined with the numerically calculated sources, and vice-versa. Note that we may also need to adjust any boundary conditions used in order to take into account the new setup.

This system is not perfect for the following reasons: we do not check that the coded expressions are correct, as such, only that the two different ways of calculating them, through Maple^TM and through the main code, agree. It is sufficient, however, to catch typographical errors in the implemented algorithm and probably some errors due to algebraic manipulation.

Even with an exact solution, the sources and fluxes will not necessarily balance, since we advance the flux terms using a conservative scheme, and the source terms using a Runge-Kutta scheme. It is not likely that this will be a problem for us, but there do exist systems of equations where this failure to balance is a major problem, and much research has been done to rectify it, e.g. Hubbard and Garcia-Navarro [60].

Note that, since the new system only differs from the original by the addition of source terms, it will have the same stability character as the original system, and therefore any error reductions in this system will likely be present in the original system as well.

Even given all these caveats, this approach still provides another way to check whether the algorithm and its implementation are functioning as they should. We note that it is not necessary only to look at final numerical evolutions; we can also compare the raw source terms calculated using the two different methods inside a debugger.

We can use this approach to test the effect of some of the numerical corrections suggested in§4.4 and

§4.7. We evolve a simple test-case using this forced-exact solution, and compare the resulting errors. The corrections are simple variations on a theme that we know to be largely correct, so that we know that they should be applicable to evolving fuller, unforced, systems. (Simply aiming for accurate capturing of the fluxes and sources would tend to suggest high-order finite-difference methods, which would not be suitable.)

The five corrections we test are:

1. Whether to limit on primitive or conserved variables (§4.7)

2. Whether or not to perform the more careful metric averaging suggested in§4.7 3. Whether or not to include the flux/source balancing term (§4.4.3 - 1D only)

4. Whether or not to use the Simpson’s rule improvement to the source calculation (§4.4.2) 5. Whether to use the combined source splitting, or Strang splitting (§4.4.1)

6. Whether to use the GFORCE flux or the HLL flux (both without multi-staging) (§4.2.3 and§4.2.4) We test these in all possible combinations as applied to the following setup:

• Metric given by the stationary propagating gauge pulse of§3.7. This avoids having to use the metric evolution terms. We have to use a solution of the Einstein equations here as we wish to compare different ways of calculating the source terms that rely on Einstein’s equations holding (see§3.2).

• Ideal fluid (§3.3.2) with adiabatic index Γ = 4/3 and initial state given by

ρ= 10⁻¹+ 10⁻²cos(2πx), vx= 10⁻¹+ 10⁻²cos(2πx), p= 2·10⁻³+ 2·10⁻⁴cos(2πx) (5.5)

1 2 3 4 5 6 kρerrork∞

X × × × × GFORCE 0.013297

X × × × X GFORCE 0.012816

X × × X X GFORCE 0.012765

× × × X X GFORCE 0.012753

× X × X X GFORCE 0.012656

Table 5.4: We show a short chain of gradual improvements to the evolution of a fluid on a curved space- time. The key to the columns is as follows: 1) Primitive variable limiting (§4.7) 2) Metric averaging correction (§4.7) 3) Flux-source balancing (§4.4.3) 4) Simpson’s Rule correction (§4.4.2) 5) Flux-source combination (§4.4.1) 6) GFORCE or HLL scheme (§4.2.3 and§4.2.4)

• Periodic boundary conditions (the initial conditions are periodic, and this removes any problems caused by boundary effects)

• Extra forcing term calculated so as to keep the fluid fixed at its initial state, assuming no numerical errors in the evolution.

• Evolve on a domain [−1,1], with 100 cells, i.e. ∆x= 1/50 up to timeT= 0.1.

In order to compare the methods, we calculate the error that occurs in each of the variablesρ, vx, and p, and take two norms of this, theL∞ norm and theL¹ norm. The effect of the corrections is, in most cases, sufficiently small for these tests that whether the correction appears to be beneficial depends on the variable and norm used.

As an example, we show in Table 5.4 the sequence of changes made between the greatest and least errors in the maximum error inρ. As we can see, the improvement overall is only about 5%, and we have chosen to show this chain for the variable and norm showing the greatest improvement.

Looking at the combinations that give the smallest error for each of the variables and error norms, we see that we should

1. Limit on the conserved variables 2. Use the more careful metric averaging 3. Not use the flux/source balancing term

4. Possibly use the Simpson correction, which only contributes to the least error for the velocity 5. Use combined source splitting (only fails to contribute to the least error when taking theL∞norm

of the pressure)

6. Use the GFORCE flux (only fails to contribute forL∞norm of velocity)

We have performed more general checks where we see how often setting a specific option to one state reduces the error as compared to the identical setup with the option set to its other state. These are not completely conclusive either, except that using the combined sources almost always helps and that using the metric averaging correction usually helps. The Simpson correction helps to reduce theL∞norm, not theL1 norm.

We emphasise, however, that the previous tests were carried out in fairly simple situations, and may not reflect the performance of the numerical schemes proposed in far more testing regimes. Also, most of these schemes require extra computation, and so it may be more beneficial to reduce the error by increasing the resolution, rather than introducing new schemes. This applies in particular to our method of combining the sources with the fluxes.