drideout at hamilton.edu
Fri Feb 18 12:52:08 CST 2005
I think that something like this has been mentioned before, but this seems
like a good context to bring it up (again?)...
It would be quite handy to have a perl script which checks and automatically
updates parameter files. This seems to be a common problem with Cactus, that
parameter files get old and out-of-date and cease to run in a relatively
short time span. With such a script, each time someone made a change which
would break parameter files, that person would also be responsible for
updating the parameter file updating script to account for the new changes.
The script may need to interact with the user to decide what changes to make
in some situations. It could take arguments such as 'convert from ADM_BSSN
to BSSN_MoL' etc. It would also need to be modular so that one can provide
for updates that are only relevant to users of a particular arrangement.
Then this script could be run on all Cactus par files and testsuites before a
Would this be practical? It should greatly simplify the maintenance of
collections of par files.
On Wednesday 16 February 2005 12:26 pm, Tom Goodale wrote:
> On Wed, 16 Feb 2005, Jonathan Thornburg wrote:
> > Hi, David,
> >> CoordBase currently contains many parameters which seem to refer to a 3d
> >> Cartesian coordinate system. The original design of CoordBase was to be
> >> completely generic, in that it should make no reference to any
> >> particular coordinate system. Perhaps these parameters do not
> >> necessarily require Cartesian coordinates, but simply require that the
> >> coordinate patch have a '3-ball' topology? If so then they should be
> >> renamed to something more generic, e.g. x, y, z --> 1, 2, 3 or some such
> >> thing. And this assumption should be clearly documented, as an
> >> additional feature which applies only to
> >> such coordinate systems. If not then this code belongs in a Cartesian
> >> coordinate thorn.
> I was rather annoyed when I saw these parameters appear, and do want to
> remove them. Stuff for specific 3D should either be in CartGrid3D or in a
> seperate thorn.
> This is the sort of stuff I was talking about a while back as being
> something we need to clean up before final release.
> >> Otherwise there is a danger that CoordBase will morph into a 3d
> >> Cartesian coordinate thorn, no? I would like to use it in a more
> >> general setting. I realize that this affects a lot of code and a lot of
> >> users, but would like to
> >> know the status of CoordBase.
> > _I_ think such a change would be great... but because it will break
> > every par file in existence I doubt you will succeed in convincing
> > all the Cactus* maintainers.
> It needs doing, we just need to take care of the migration path.
> > A related point...
> > CactusEinstein/ADMBase says that the 3-metric components have the
> > names gxx gxy gxz gyy gyz gzz .
> > When we were designing ADMBase I argued that the names should be
> > the more generic g11 g12 g13 g22 g23 g33
> > but in the end the majority went with avoiding any changes to
> > existing thorns (which assumed the gxx et al names).
> > So again, we have xyz names.
> > Of course, this only applies to the coordinate *names*,
> > not their semantics... but it's still a bit of an irritant.
> > Both the Erik/LSU multipatch effort (thorn AEIDevelopment/MultiPatch)
> > and mine (thorn AEIDevelopment/GZPatchSystem) use the same mapping
> > between Cactus (x,y,z) and our own per-patch coordinate names,
> > with (x,y) <--> two angular coordinates and z <--> a radial coordinate.
> I would be quite happy to make this change, as it was agreed on during the
> einstein redesign. I think the objection was that most of the tools
> assume cartesian topology. Now that we have the new coordinate stuff it
> should be easy for tools to work out if the topology is one they can't
> deal with.
> However, this would be a really big change, so we need to make sure
> everyone is ok with it and that it can be done swiftly enough not to
> disrupt people's work.
> Developers mailing list
> Developers at cactuscode.org
More information about the Developers