Einstein Hierachy Tidy Up ------------------------- Author: Tom Goodale, AEI Numerical Relativity Group, Erik Schnetter Date: 17 April 2002 Status: Final version CactusEinstein -> CauchyBase StaticConformal CoordGauge SpaceMask ADMUtils (?? for lightweight analysis) ADMMacros ADMCourant ADM ADMConstraints AHFinder Extract IDAnalyticBH IDAxiBrillBH IDBrillData IDLinearWaves Maximal PsiKadelia TimeGeodesic 1) 'einstein' thorn: --------------- Will be renamed CauchyBase. The general feeling is that this 'einstein' thorn should not do much. It should provide the basic ADM variables: metric - called g11, g12, ... extrinsic curvature - called K11, J12, ... lapse - called lapse shift - called shift1, shift2, shift3 as public variables people could inherit from. These variables should have time-levels. This means that CauchyBase will define a certain maximum number, say 3, and then the people using the variables should specify the actual number of timelevels they use in their schedule.ccl files. It will provide the following restricted parameters: initial_lapse - this is a keyword, defaulting to "one" no other values defined in CauchyBase initial_shift - this is a keyword, defaulting to "none" CauchyBase also provides "zero" as a value The default means no storage switched on for shift initial_data - this is the initial metric and extrinsic curvature dataset default is "minkowski" no other values defined in CauchyBase evolution_method - this is the metric an extrinsic curvature evolution method default is "none" no other values defined in CauchyBase lapse_evolution_method - default to "geodesic" CauchyBase also provides "static" shift_evolution_method - default to "static" no other values defined in CauchyBase metric_type - the semantics of the metric variables (physical, static-conformal, etc) default to "physical" no other values defined in CauchyBase The einstein thorn provides code to initialise the metric, extrinsic curvature, shift and lapse if the parameters are set that way. All thorns are supposed to check the value of metric_type at paramcheck time and abort or do whatever is sensible if they do not recognise the keyword. 2) Conformal factor: ---------------- This will be moved out to a new thorn StaticConformal This provides variables psi - the conformal factor psi_1, psi_2, psi_3 - its first derivatives psi_11,psi_12,... - its second derivatives and an integer grid scalar conformal_state It provides one parameter conformal_storage which is a keyword parameter specifying whether storage is on for the conformal factor, it and its derivatives, it and the 1st and 2nd derivatives. It extends the CauchyBase metric_type parameter adding "static conformal" as an allowed range. Initial data thorns which know about the static conformal stuff should inherit from this, and initialise the variables which have storage assigned if metric_type is "static conformal". They should set the value of the grid scalar to an integer indicating how many levels of the conformal data they have actually calculated - i.e. 1 for just the factor, 2 for the factor and its derivatives and 3 for all of them. Other thorns should check metric_type, and if it is "static conformal" they can then use the conformal_state grid scalar to work out what is available. A conformal_state value of 0 means the conformal factor is 1.0 at all points. 3) Gauge: ----- The current gauge selection gauge stuff will be moved out to a thorn called CoordGauge. The CoordGauge implementation schedules five groups CoordGauge LapseSelect IN CoordGauge BEFORE PickCoordGauge LapseApply IN CoordGauge AFTER PickCoordGauge ShiftSelect IN CoordGauge BEFORE PickCoordGauge ShiftApply IN CoordGauge AFTER PickCoordGauge and one function PickCoordGauge IN CoordGauge and has two public grid scalars selected_lapse selected_shift and two string parameters lapse_list shift_list It also provides four aliased functions int CoordGauge_RegisterLapse("lapse-name") int CoordGauge_RegisterShift("shift-name") CoordGauge_Lapse("lapse-name") CoordGauge_Shift("shift-name") (If someone can think of better names, please say so 8-) Then each thorn which wants to apply a coordinate gauge condition registers itself, receiving a unique integer as an id, and schedules a selection routine and an application routine in the appropriate schedule groups. The selection routine decides if this gauge condition should be applied at this time, and calls the CoordGauge_Lapse/Shift aliased function. (It should check that it is actually in the appropriate parameter as a minimum.) The PickCoordGauge traverses the list of lapses/shifts and selects the first one in the list which has called the CoordGauge_Lapse/Shift aliased function and sets the appropriate grid scalar to the id of this one. The application routine checks to see if the grid scalar is set to its id, and if so, applies the gauge condition. Evolution thorns could schedule CoordGauge at the appropriate point or points in their schedule. An advantage of this scheme over the current one is that it provides the selection routines with a full set of variables from which to decide whether they should apply a guage or not. So it becomes very easy to choose to switch off maximal if the lapse has collapsed within a certain volume, etc. This is simpler than the previous scheme as there is no arbitrary 'bid' floating around. It also allows us to keep the logic of the final selection in one place, thus allowing people to override this logic if they need to. 4) Mask ---- This will be moved out to a new thorn called SpaceMask. This will provide two integer grid functions space_mask space_table_field the first one will be a bitmask describing the point, with one bit indicating that there is extra data in a table the handle of which can be found in the corresponding point in the space_table_field. Thorns interested in the mask should inherit from this implementation. There may also be aliased query functions provided. 5) Analysis stuff -------------- The current analysis done by Einstein should be moved out into one or more analysis thorns. There is a suggestion to have a separate tensor transformation thorn which provides a library of routines to do tensor transformations. 6) Macros ------ ADM, ADM_BSSN, etc use a whole load of complicated macros. We decided that the macro mechanism should be replaced by a home-grown, or possibly m4 or something similar, inline function expansion mechanism. This would allow things like u11,u12,u13,u22,u23,u33,det = CalcMetricInverse(g11,g12,g13,g22,g23,g33) which coupled with cpp macros could then be u,det = CalcMetricInverse(g) for example. We almost certainly need optional arguments to allow things to be either calculated or re-used if they have already been calculated. The precise syntax and requirements for this stuff is still to be decided, and there will be a review of current code to find out what our precise needs are. There's some discussion still happening on the mailing list. In the short term, the macros will be moved out to a thorn ADM_Macros. 7) Courant ------- We decided to strip out the current courant stuff in the new 'einstein' as it is currently only suitable for Bona-Masso. At a future date we may provide a courant thorn which provides the appropriate wave speeds to the Time thorn. 8) Boundaries: ---------- We had a long discussion about this and agreed on a scheme which I have outlined in the boundary thread in the developers list and is currently under discussion there.