Converting to New Einstein Infrastructure ----------------------------------------- Einstein was split across ADMBase ADMAnalysis ADMMacros CoordGauge SpaceMask StaticConformal and the following thorns have been converted and pass their test suites ADM ADMConstraints AHFinder Extract IDAnalyticBH IDAxiBrillBH IDLinearWaves Maximal PsiKadelia TimeGeodesic (doesn't pass testsuite yet) there are also new thorns ADMCoupling IDSimple which just does minkowski data respecting the conformal factor choice, which should be helpful for testing that thorns are doing the right thing with the conformal factor (especially if you can initialise all arrays to NaN before running). this thorn also contains the initial gauge choices formally in Einstein EvolSimple an example extremely simple evolver (note this isn't quite ready yet, it doesn't pass the testsuite) There is documentation available in doc/documentation.tex of each thorn, note that you can easily make a postscript file of all the thorns using gmake -ThornGuide Some notes on conversion ------------------------ 0. IFDEFS ------ Of course, noone is abusing ifdefs, but just in case, check that they are still looking at the right thorns ... You can search using grep -r "ifdef" " Look for things like #ifdef CACTUSEINSTEIN_EINSTEIN 1. INHERITANCE ----------- In interface.ccl you no longer inherit from einstein, but from ADMBase. Add StaticConformal if you use the conformal factor. Add ADMMacros if you use any macros (outside of the ones in ADM_BSSN). Add CoordGauge if you supply a gauge condition or need to know the gauge. Add SpaceMask if you use the mask. ADMBase doesn't inherit from "grid" (the coordinates) anymore, so if you use x,y,z,r grid functions you will need to inherit from grid yourself. All these are easy to find, since your code won't compile until you inherit from the right thorns, so don't guess, only inherit from other thorns which you really need. 2. METRIC TYPE ----------- All thorns should check that they know what metric_type they are working with. Most of our thorns can work with both the physical or conformal metric, which are differentiated with using the value of the metric_type parameter and the grid scalar conformal_state. Thorns should check the metric_type at PARAMCHECK time, look for example in ADMAnalysis and IDLinearWaves for this. Note that you need to add to your param.ccl shares: ADMBase USES KEYWORD metric_type And you also need to schedule your param checking routine schedule Extract_ParamCheck at PARAMCHECK { LANG: C } "Check parameters" Initial data should usually just check the parameters metric_type and conformal_storage and behave accordingly, - i.e setup either a physical or conformal metric and the appropriate number of derivatives. If conformal data is setup the conformal_state grid scalar should be updated to specify how many derivatives were calculated - 1 means just the conformal factor, 2 the conformal factor and first derivatives, and 3 the conformal factor and the first and second derivatives. The macro stuff copes with no conformal factor or conformal factor and two derivatives, so you should probably follow the example of the ADMConstraints thorn to check that the initial data has set this up properly. I.e. one paramcheck routine, and then another routine which checks the conformal_state grid scalar and makes sure it is either 0 or 3. The ADMConstraints and ADM thorns make sure they have storage switched on for the conformal_state flag so they can use it - StaticConformal only switches it on if metric_type is "static conformal". So these thorns set the value to zero if metric_type is "physical" to avoid having to repeatedly check the metric_type parameter. I have converted the macro stuff so that it just looks for conformal_state > 0 rather than conformal_state = 1 to detect conformality. 3. CONFORMAL FACTOR ---------------- See Section 2, also note that the names of the functions for converting between conformal and physical metrics have changed. (Use these functions sparingly, messing around with the conformal_state could be dangerous and confusing) ConfToPhys -> StaticConformal_ConfToPhysInPlace PhysToConf -> StaticConformal_PhysToConfInPlace 4. VARIABLES --------- The only variable name changes occur if you are using the full name of a variable (eg to get the index, or pass to a boundary condition). You should search your code and convert einstein::metric, curv, lapse, shift to admbase::metric, curv, lapse, shift You should change einstein::psi (etc) to staticconformal::psi (etc) You should change einstein::grr, krr, trK, etc to ADMAnalysis::grr, krr, trK, etc [for example, just do grep -i "einstein::" * in the src directory] 5. PARAMETER FILES: ACTIVE THORNS ------------------------------ You need to remove Einstein and add ADMBase and then as appropriate ADMMacros, StaticConformal, CoordGauge, SpaceMask, ADMAnalysis ... the errors when you run a parameter file with these missing should tell you exactly which thorns to add. 6. PARAMETER FILES:: OUTPUT ------------------------ You need to make the changes mentioned in Section 2. Look at the warnings when you run the parameter file, the IO thorns will tell you about any variables it doesn't know about. 7. PARAMETER FILES:: GENERAL PARAMETERS ------------------------------------ NOTE: If you run with eg ./exe/cactus_new arrangements/CactusEinstein2/Extract/par/Extract.par -parameter-level=strict Cactus will tell you about all potential problems in your parameter file Generally, you need to change the parameters einstein::initial_data -> ADMBase::initial_data einstein::evolution_system -> ADMBase::evolution_method IMPORTANT: Since practically all codes currently seem to use conformal factor, your parameter files should almost certainly have admbase::metric_type = "static conformal" to make sure the conformal stuff is used. For the slicing, I have converted the test files to use things like admbase::lapse_evolution_method = "coordgauge" coordgauge::lapse_list = "1+log" It is also possible to put admbase::lapse_evolution_method = "1+log" at the moment, i.e. the first parameter is like slicing and the second like mixed_slicing. For the mask, the parameter is now in SpaceMask einstein::use_mask -> SpaceMask::use_mask 8. INITIAL DATA ------------ ADMBase defines a schedule group ADMBase_InitialData for setting initial data which runs at CCTK_INITIAL, so if you are setting anything which doesn't care about the order, schedule the routine to run in this schedule group. schedule in ADMBase_InitialData 9. SHIFT ----- Previously there where two macros SHIFT_ACTIVE and SHIFT_INACTIVE for comparing with the value of the scalar shift_state. We removed these simply so that you don't need to include the "Einstein.h" file anymore. So SHIFT_ACTIVE -> 1 SHIFT_INACTIVE -> 0 The parameter "shift" changed name to "shift_evolution_method". 10.REMEMBER -------- You also need to convert any parameter files in the par directory. Please also check through the documentation for any needed updates.