[Developers] CoordBase

[David Rideout]

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 
release, etc.

Would this be practical?  It should greatly simplify the maintenance of 
collections of par files.

Cheers,
David

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.
>
> Tom
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers