Hi,
I am wondering exactly which (common) coordinate systems are 'deeply' supported in Cactus? These days of course most use Cartesians. I think I see reference to spher3D in various places but am not certain the extent to which spherical coords are fully supported. Also, I see no mention to cylindrical coordinates. So, I am asking for guidance about just what is the breadth of common 3D coordinate system support. Can you please let me know?
Thanks very much.
Comer
On 18 Jul 2012, at 15:57, Comer Duncan wrote:
Hi,
I am wondering exactly which (common) coordinate systems are 'deeply' supported in Cactus? These days of course most use Cartesians. I think I see reference to spher3D in various places but am not certain the extent to which spherical coords are fully supported. Also, I see no mention to cylindrical coordinates. So, I am asking for guidance about just what is the breadth of common 3D coordinate system support. Can you please let me know?
Thanks very much.
I believe that for anything nontrivial, only 3D Cartesian coordinates can be used.
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
-erik
On Wed, Jul 18, 2012 at 3:42 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 18 Jul 2012, at 15:57, Comer Duncan wrote:
Hi,
I am wondering exactly which (common) coordinate systems are 'deeply' supported in Cactus? These days of course most use Cartesians. I think I see reference to spher3D in various places but am not certain the extent to which spherical coords are fully supported. Also, I see no mention to cylindrical coordinates. So, I am asking for guidance about just what is the breadth of common 3D coordinate system support. Can you please let me know?
Thanks very much.
I believe that for anything nontrivial, only 3D Cartesian coordinates can be used.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
-erik
On 19 Jul 2012, at 13:02, Erik Schnetter wrote:
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
Aha. Yes. So what does CartGrid3D actually do when you ask for spherical coordinates? x, y and z are mapped to r, theta and phi, but since you set the ranges yourself anyway, what more is needed?
On Thursday, July 19, 2012, Ian Hinder wrote:
On 19 Jul 2012, at 13:02, Erik Schnetter wrote:
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder <ian.hinder@aei.mpg.dejavascript:;>
wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D,
so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
Aha. Yes. So what does CartGrid3D actually do when you ask for spherical coordinates? x, y and z are mapped to r, theta and phi, but since you set the ranges yourself anyway, what more is needed?
CartGrid3D sets the coordinate fields for each grid point, which is typically needed to set up initial conditions. CartGrid3D does nothing else. In many codes, the coordinate system also influences how derivatives are defined (e.g. Laplace looks different in Cartesian and in spherical coordinates), but since one has to define Laplace oneself when implementing finite differencing a routine, this is not an issue here.
-erik
On 19 Jul 2012, at 16:02, Erik Schnetter wrote:
On Thursday, July 19, 2012, Ian Hinder wrote:
On 19 Jul 2012, at 13:02, Erik Schnetter wrote:
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
Aha. Yes. So what does CartGrid3D actually do when you ask for spherical coordinates? x, y and z are mapped to r, theta and phi, but since you set the ranges yourself anyway, what more is needed?
CartGrid3D sets the coordinate fields for each grid point, which is typically needed to set up initial conditions. CartGrid3D does nothing else. In many codes, the coordinate system also influences how derivatives are defined (e.g. Laplace looks different in Cartesian and in spherical coordinates), but since one has to define Laplace oneself when implementing finite differencing a routine, this is not an issue here.
So the grid::x, y and z coordinate grid functions will be filled with the Cartesian coordinate values, computed as if the underlying grid is r, theta, phi?
On Thu, Jul 19, 2012 at 3:29 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 16:02, Erik Schnetter wrote:
On Thursday, July 19, 2012, Ian Hinder wrote:
On 19 Jul 2012, at 13:02, Erik Schnetter wrote:
On Thu, Jul 19, 2012 at 11:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jul 2012, at 11:19, Erik Schnetter wrote:
Comer
Do you intend to use existing thorns to evolve e.g. the Einstein equations, or do you plan to write your own thorns?
If you use existing thorns: As written, they will not be able to handle the coordinate singularities on the axes. Instead, we use multi-block methods.
If you write your own thorns: Since you will be implementing your own differencing methods, the Cactus coordinates are basically only needed to label grid point. CartGrid3D can handle this; e.g. spherical or cylindrical coordinate systems are orthogonal. You will only need to correctly specify the respective coordinate ranges (e.g. using [0,rmax] for r and [0,2pi] for phi) in your parameter file. The unification of f(phi=0) and f(phi=2pi) would be handled via a periodicity condition, which is provided e.g. by thorn Periodic.
What remains is that Cactus labels the coordinates x,y,z instead of r,z,phi... but this is mainly a small inconvenience. Altogether, it is straightforward to use spherical or cylindrical coordinates with existing thorns, and we therefore never bothered to implement any new coordinate systems for this.
I think that CoordBase does not support anything other than CartGrid3D, so you won't be able to use any thorn which uses CoordBase.
What I describe above uses CartGrid3D...
Aha. Yes. So what does CartGrid3D actually do when you ask for spherical coordinates? x, y and z are mapped to r, theta and phi, but since you set the ranges yourself anyway, what more is needed?
CartGrid3D sets the coordinate fields for each grid point, which is typically needed to set up initial conditions. CartGrid3D does nothing else. In many codes, the coordinate system also influences how derivatives are defined (e.g. Laplace looks different in Cartesian and in spherical coordinates), but since one has to define Laplace oneself when implementing finite differencing a routine, this is not an issue here.
So the grid::x, y and z coordinate grid functions will be filled with the Cartesian coordinate values, computed as if the underlying grid is r, theta, phi?
No.
In your mind, you rename the coordinates x,y,z to r,z,phi. You then use CartGrid3D to define the ranges you want to simulate, i.e. [0,2pi] for phi. You also set up periodic boundary conditions in the phi direction. These are then cylindrical coordinates.
Cylindrical (and spherical) coordinates have equidistant grid points in the r,z,theta,phi direction, and their grid lines are orthogonal; this is the same as for Cartesian coordinates. This is the only thing relevant here.
What one usually means by "coordinate system" includes also the respective metric terms when calculating derivatives. However, as this is not handled by CartGrid3D, this is not relevant here.
-erik
users@lists.einsteintoolkit.org
-
Comer Duncan -
Erik Schnetter -
Ian Hinder