Difference between revisions of "Repository transition"

From Einstein Toolkit Documentation
Jump to: navigation, search
(comment on NewRad)
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)
+
* 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?
 
* EinsteinInitialData
 
* EinsteinInitialData
 
* EinsteinUtils
 
* EinsteinUtils
Line 23: Line 23:
 
* PITTNullCode
 
* PITTNullCode
 
* CactusConnect
 
* CactusConnect
* EinsteinInitialData/GRHydro_InitData
+
* EinsteinInitialData/GRHydro_InitData -> EinsteinTest arrangement?
* CactusExamples:
+
* CactusExamples
* CactusTest (GRHydro_InitData goes here, as Test_GRHydro, RH: this is a license conflict. GRHydro_InitData is GPL)
+
* CactusTest (GRHydro_InitData goes here, as Test_GRHydro, RH: this is a license conflict. GRHydro_InitData is GPL), FL: EinsteinTest arrangement?
 
* CactusWave
 
* CactusWave
 
* CactusPUGH
 
* CactusPUGH

Revision as of 08:16, 16 June 2014

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

  • EinsteinAnalysis
  • EinsteinBase
  • 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?
  • EinsteinInitialData
  • EinsteinUtils
  • incoming
  • manifest
  • pyGWAnalysis
  • tools
  • VizTools/CarpetHDF5
  • VizTools/CarpetN5
  • VizTools/DataVaultXVSutils
  • CactusBase
  • CactusElliptic
  • CactusIO
  • CactusNumerical
  • CactusUtils
  • TAT
  • flesh
  • PITTNullCode
  • CactusConnect
  • EinsteinInitialData/GRHydro_InitData -> EinsteinTest arrangement?
  • CactusExamples
  • CactusTest (GRHydro_InitData goes here, as Test_GRHydro, RH: this is a license conflict. GRHydro_InitData is GPL), FL: EinsteinTest arrangement?
  • CactusWave
  • 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).