Difference between revisions of "Repository transition"

From Einstein Toolkit Documentation
Jump to: navigation, search
Line 4: Line 4:
 
* EinsteinBase
 
* EinsteinBase
 
* EinsteinEOS
 
* EinsteinEOS
−
* EinsteinEvolve RH: do we want to keep NewRad in here? It does not really provide evolution from a user's point of few rather it provides a boundary condition (which is implemented by modifying the RHS). It would seem to be more suitable for CactusNumerial (but has the wrong license) FL: This would "combine" GRHydro and the Illinois code, plus any other GR-related evolution thorn. Is this wanted?
+
* EinsteinEvolve: LegoExcision: out, NewRad -> EinsteinNumerical/NewRad, GRHydro -> GRHydro arrangement
 
* EinsteinInitialData
 
* EinsteinInitialData
 
* EinsteinUtils
 
* EinsteinUtils
Line 17: Line 17:
 
* CactusElliptic
 
* CactusElliptic
 
* CactusIO
 
* CactusIO
−
* CactusNumerical
+
* CactusNumerical (TestLocalReduce moved in here)
 
* CactusUtils
 
* CactusUtils
 
* TAT
 
* TAT
Line 23: Line 23:
 
* PITTNullCode
 
* PITTNullCode
 
* CactusConnect
 
* CactusConnect
−
* EinsteinInitialData/GRHydro_InitData -> EinsteinTest arrangement?
+
* EinsteinInitialData/GRHydro_InitData -> GRHydro arrangement
 
* CactusExamples
 
* CactusExamples
−
* CactusTest (GRHydro_InitData goes here, as Test_GRHydro, RH: this is a license conflict. GRHydro_InitData is GPL), FL: EinsteinTest arrangement?
+
* CactusTest, everything stays there, except TestLocalReduce, which moves to CactusNumerical (next to LocalReduce)
 
* CactusWave
 
* CactusWave
 
* CactusPUGH
 
* CactusPUGH
−
 
−
== possible conflicting locations ==
 
−
* it would make sense to keep thorn X and its TestX thorn in the same repository. They should then not be split up into X in EinsteinEvolve and TestX in Cactus Test. This affects:
 
−
** GRHydro and GRHydro_Init_Data
 
−
** MoL and TestMoL
 
−
** Carpet and its Test thorns (currently Carpet / CarpetExtra arrangements)
 
−
In particular for the case of GRHydro, GRHydro itself has had many more frequent changes requiring updates to test data than GRHydro_Init_Data so it makes sense to keep the test parfiles and test data with GRhydro rather than with GRHydro_Init_Data (the future Test_GRHydro).
 

Revision as of 09:41, 16 June 2014

Arrangements should go into one git repository each, except where noted:

  • EinsteinAnalysis
  • EinsteinBase
  • EinsteinEOS
  • EinsteinEvolve: LegoExcision: out, NewRad -> EinsteinNumerical/NewRad, GRHydro -> GRHydro arrangement
  • EinsteinInitialData
  • EinsteinUtils
  • incoming
  • manifest
  • pyGWAnalysis
  • tools
  • VizTools/CarpetHDF5
  • VizTools/CarpetN5
  • VizTools/DataVaultXVSutils
  • CactusBase
  • CactusElliptic
  • CactusIO
  • CactusNumerical (TestLocalReduce moved in here)
  • CactusUtils
  • TAT
  • flesh
  • PITTNullCode
  • CactusConnect
  • EinsteinInitialData/GRHydro_InitData -> GRHydro arrangement
  • CactusExamples
  • CactusTest, everything stays there, except TestLocalReduce, which moves to CactusNumerical (next to LocalReduce)
  • CactusWave
  • CactusPUGH
Retrieved from "https://docs.einsteintoolkit.org/et-docs/index.php?title=Repository_transition&oldid=3730"