Hi,
Recently Ian Hinder and I have created an arrangement of thorns called EinsteinExact which provide some exact solutions for use in Cactus. The scope of these thorns is similar to that of the Exact thorn but with some notable improvements:
* The extrinsic curvature is computed symbolically rather than using finite differencing so it should be accurate to within roundoff. This means that EinsteinExact is more exact than Exact. * The solutions used in EinsteinExact come from a database of metrics which have been correctness-tested, e.g., by checking symbolically that they are a solution of the Einstein equation. * EinsteinExact is written in Mathematica and uses Kranc, so the raw source is very small (~250 lines) and easy to understand. * Adding a spacetime is as simple as typing the components of the metric into Mathematica.
So far, the spacetimes included are Minkowski, Kerr-Schild, gauge wave and shifted gauge wave, but the list can easily be extended in the future. There is also support for arbitrary rotations, using the same conventions as the Exact thorn uses. We have not yet included the other transformations supported by Exact, but they shouldn't be difficult to add.
We have checked that for these spacetimes the Exact solutions converge to the EinsteinExact solutions at the correct finite differencing order used by Exact.
We would like to propose the EinsteinExact arrangement for inclusion in the EinsteinToolkit. If you would like to try it out, you can get it using:
git clone --recursive git://github.com/barrywardell/EinsteinExact
Any comments or suggestions are welcome.
Regards, Barry
Is there any interest in including this in the ET?
On Fri, Nov 25, 2011 at 6:46 PM, Barry Wardell barry.wardell@aei.mpg.dewrote:
Hi,
Recently Ian Hinder and I have created an arrangement of thorns called EinsteinExact which provide some exact solutions for use in Cactus. The scope of these thorns is similar to that of the Exact thorn but with some notable improvements:
- The extrinsic curvature is computed symbolically rather than using
finite differencing so it should be accurate to within roundoff. This means that EinsteinExact is more exact than Exact.
- The solutions used in EinsteinExact come from a database of metrics
which have been correctness-tested, e.g., by checking symbolically that they are a solution of the Einstein equation.
- EinsteinExact is written in Mathematica and uses Kranc, so the raw
source is very small (~250 lines) and easy to understand.
- Adding a spacetime is as simple as typing the components of the metric
into Mathematica.
So far, the spacetimes included are Minkowski, Kerr-Schild, gauge wave and shifted gauge wave, but the list can easily be extended in the future. There is also support for arbitrary rotations, using the same conventions as the Exact thorn uses. We have not yet included the other transformations supported by Exact, but they shouldn't be difficult to add.
We have checked that for these spacetimes the Exact solutions converge to the EinsteinExact solutions at the correct finite differencing order used by Exact.
We would like to propose the EinsteinExact arrangement for inclusion in the EinsteinToolkit. If you would like to try it out, you can get it using:
git clone --recursive git://github.com/barrywardell/EinsteinExact
Any comments or suggestions are welcome.
Regards, Barry
On 23 Apr 2012, at 23:35, Barry Wardell wrote:
Is there any interest in including this in the ET?
Yes, I think it should be included.
1. Using Exact for test suite initial data is extremely problematic due to the fact that Exact uses finite differencing with a very small timestep to compute the extrinsic curvature. The very small timestep makes the solution very sensitive to roundoff differences, and we typically have trouble generating the same solution using different compilers (e.g. Intel and PGI). This was mitigated somewhat by the use of higher order finite differencing with a large timestep in Exact, but the solution persisted. Eventually, I used an unphysically large timestep for the regression tests. This is an indication that the initial data from Exact is not suitable for simulations where high accuracy is required. The EinsteinExact arrangement avoids this problem completely by computing derivatives analytically. If EinsteinExact were included, the test suites could be regenerated using it, which would be a much cleaner solution.
2. The EinsteinExact solutions are generated automatically from the Metrics database, which can be rigorously correctness-tested in an automated way by running a notebook/script. There is currently no automated way to test the Exact thorn, so we have only anecdotal evidence that the solutions are correct (and in fact, bugs have been found in the past).
3. The inclusion of the Metrics database, independent of the EinsteinExact Cactus arrangement, is also of value. This can be used from Mathematica with, for example, the xAct tensor manipulation package, for doing symbolic calculations on exact solutions. This could provide a well-tested canonical source of exact solutions for other applications. Automated conversion of the solutions into other formats for other packages would be straightforward to implement.
I believe the requirements for inclusion should be that the code has tests and documentation, is considered by an independent reviewer to be of sufficiently high quality, and is expected to be generally useful. I think all we are missing is documentation and the independent reviewer (volunteers?).
I propose that EinsteinExact and the Metrics database be included in the ET contingent on documentation being written and the approval of someone who has looked at the code other than Barry and me.
On Fri, Nov 25, 2011 at 6:46 PM, Barry Wardell barry.wardell@aei.mpg.de wrote: Hi,
Recently Ian Hinder and I have created an arrangement of thorns called EinsteinExact which provide some exact solutions for use in Cactus. The scope of these thorns is similar to that of the Exact thorn but with some notable improvements:
- The extrinsic curvature is computed symbolically rather than using finite differencing so it should be accurate to within roundoff. This means that EinsteinExact is more exact than Exact.
- The solutions used in EinsteinExact come from a database of metrics which have been correctness-tested, e.g., by checking symbolically that they are a solution of the Einstein equation.
- EinsteinExact is written in Mathematica and uses Kranc, so the raw source is very small (~250 lines) and easy to understand.
- Adding a spacetime is as simple as typing the components of the metric into Mathematica.
So far, the spacetimes included are Minkowski, Kerr-Schild, gauge wave and shifted gauge wave, but the list can easily be extended in the future. There is also support for arbitrary rotations, using the same conventions as the Exact thorn uses. We have not yet included the other transformations supported by Exact, but they shouldn't be difficult to add.
We have checked that for these spacetimes the Exact solutions converge to the EinsteinExact solutions at the correct finite differencing order used by Exact.
We would like to propose the EinsteinExact arrangement for inclusion in the EinsteinToolkit. If you would like to try it out, you can get it using:
git clone --recursive git://github.com/barrywardell/EinsteinExact
Any comments or suggestions are welcome.
Regards, Barry
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 24 Apr 2012, at 09:30, Ian Hinder wrote:
On 23 Apr 2012, at 23:35, Barry Wardell wrote:
Is there any interest in including this in the ET?
Yes, I think it should be included.
Using Exact for test suite initial data is extremely problematic due to the fact that Exact uses finite differencing with a very small timestep to compute the extrinsic curvature. The very small timestep makes the solution very sensitive to roundoff differences, and we typically have trouble generating the same solution using different compilers (e.g. Intel and PGI). This was mitigated somewhat by the use of higher order finite differencing with a large timestep in Exact, but the solution persisted. Eventually, I used an unphysically large timestep for the regression tests. This is an indication that the initial data from Exact is not suitable for simulations where high accuracy is required. The EinsteinExact arrangement avoids this problem completely by computing derivatives analytically. If EinsteinExact were included, the test suites could be regenerated using it, which would be a much cleaner solution.
The EinsteinExact solutions are generated automatically from the Metrics database, which can be rigorously correctness-tested in an automated way by running a notebook/script. There is currently no automated way to test the Exact thorn, so we have only anecdotal evidence that the solutions are correct (and in fact, bugs have been found in the past).
The inclusion of the Metrics database, independent of the EinsteinExact Cactus arrangement, is also of value. This can be used from Mathematica with, for example, the xAct tensor manipulation package, for doing symbolic calculations on exact solutions. This could provide a well-tested canonical source of exact solutions for other applications. Automated conversion of the solutions into other formats for other packages would be straightforward to implement.
I believe the requirements for inclusion should be that the code has tests and documentation, is considered by an independent reviewer to be of sufficiently high quality, and is expected to be generally useful. I think all we are missing is documentation and the independent reviewer (volunteers?).
I propose that EinsteinExact and the Metrics database be included in the ET contingent on documentation being written and the approval of someone who has looked at the code other than Barry and me.
EinsteinExact is hosted on GitHub, in case anyone wants to browse through the code.
https://github.com/barrywardell/EinsteinExact
Some interesting files are:
* Shifted gauge wave metric (for example): https://github.com/barrywardell/Metrics/blob/master/metrics/ShiftedGaugeWave... * All available metrics in Metrics database: https://github.com/barrywardell/Metrics/tree/master/metrics * Convert metrics into thorns using Kranc: https://github.com/barrywardell/EinsteinExact/blob/master/EinsteinExact.m * Generated thorns: https://github.com/barrywardell/EinsteinExact/tree/master_thorns * For example, ShiftedGaugeWave: https://github.com/barrywardell/EinsteinExact/tree/master_thorns/ShiftedGaug...
On Tue, Apr 24, 2012 at 8:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
I believe the requirements for inclusion should be that the code has tests and documentation, is considered by an independent reviewer to be of sufficiently high quality, and is expected to be generally useful. I think all we are missing is documentation and the independent reviewer (volunteers?).
What type of documentation is required? Currently there is only a basic README file. Should there also be some sort of Cactus documentation which describes the arrangement/thorns? Is there anything more than this needed?
Barry
On Tue, Apr 24, 2012 at 5:49 AM, Barry Wardell barry.wardell@gmail.com wrote:
On Tue, Apr 24, 2012 at 8:30 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
I believe the requirements for inclusion should be that the code has tests and documentation, is considered by an independent reviewer to be of sufficiently high quality, and is expected to be generally useful. I think all we are missing is documentation and the independent reviewer (volunteers?).
What type of documentation is required? Currently there is only a basic README file. Should there also be some sort of Cactus documentation which describes the arrangement/thorns? Is there anything more than this needed?
There needs to be documentation, but it does not have to be at the thorn level -- documenting all thorns combined works fine. I would expect information on how to use the thorns, how to regenerate them, and how to modify or add a new metric. In particular, the thorns' parameters need to be explained. Test cases are also required.
-erik
Barry
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Tue, Apr 24, 2012 at 1:27 PM, Erik Schnetter schnetter@cct.lsu.eduwrote:
On Tue, Apr 24, 2012 at 5:49 AM, Barry Wardell barry.wardell@gmail.com wrote:
On Tue, Apr 24, 2012 at 8:30 AM, Ian Hinder ian.hinder@aei.mpg.de
wrote:
I believe the requirements for inclusion should be that the code has
tests
and documentation, is considered by an independent reviewer to be of sufficiently high quality, and is expected to be generally useful. I
think
all we are missing is documentation and the independent reviewer (volunteers?).
What type of documentation is required? Currently there is only a basic README file. Should there also be some sort of Cactus documentation which describes the arrangement/thorns? Is there anything more than this
needed?
There needs to be documentation, but it does not have to be at the thorn level -- documenting all thorns combined works fine. I would expect information on how to use the thorns, how to regenerate them, and how to modify or add a new metric. In particular, the thorns' parameters need to be explained. Test cases are also required.
OK, I will write documentation for all thorns combined as most of the information is common between them. There are already Cactus testsuites and correctness tests for all of the thorns.
users@lists.einsteintoolkit.org
-
Barry Wardell -
Barry Wardell -
Erik Schnetter -
Ian Hinder