Hi,
Following on from the discussion in the last Einstein Toolkit meeting, this is an update of the status of the transition from svn to git.
* (Almost) all Cactus and Einstein Toolkit arrangements have now been converted to git and merged into a one-repository-per-arrangement layout. * The repositories are available on Bitbucket under the Cactus < https://bitbucket.org/cactuscode%3E and EinsteinToolkit < https://bitbucket.org/einsteintoolkit%3E team pages. * The git testing thornlist < http://svn.einsteintoolkit.org/manifest/trunk/git_testing.th%3E has been updated to point to the new repositories. I have verified that it is possible to checkout and build the Einstein Toolkit using this thornlist. * The conversion process is automated using scripts provided in the ET git transition repository https://bitbucket.org/ianhinder/etgittransition. * All master, ET release and Cactus release branches have been checked to perfectly match (i.e. no missing commits, no file differences) their svn counterparts. Similarly for the ET and Cactus release tags. * There is a list of known outstanding issues available < https://bitbucket.org/ianhinder/etgittransition/src/master/issues.md%3E. It's likely that most, if not all of these issues are sufficiently minor that they can be ignored.
To proceed further it would be helpful if people (particularly those responsible for maintaining thorns and those who have opinions on how the final layout should appear) could take a look at the repositories and report any issues or suggested changes. In particular, it would be helpful to have feedback on how to handle AEIThorns, LSUThorns, ExternalLibraries, GRHydro, and the TAT thorns.
Regards, Barry
On Sun, Aug 17, 2014 at 08:34:13PM -0400, Barry Wardell wrote:
AEIThorns, LSUThorns
These stay where they are, except if a thorn author requests a move.
ExternalLibraries
These stay svn repos for now, until we implemented the newly proposed mechanism for downloading them.
GRHydro
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
the TAT thorns.
I don't know what Erik wanted to do with them. We can always leave them where they are right now, but I would guess moving them to a TAT git arrangement would probably best.
Frank
On Mon, Aug 18, 2014 at 10:58 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
GRHydro
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
I have removed these thorns from the Einstein Toolkit arrangements. Should I also create a GRHydro arrangement? My understanding is that GRHydro starts out as a git repository, so maybe it's better to just work directly with that instead?
the TAT thorns.
I don't know what Erik wanted to do with them. We can always leave them where they are right now, but I would guess moving them to a TAT git arrangement would probably best.
As agreed on the call, I have moved these thorns into CactusElliptic and CactusUtils.
Barry
On Mon, Aug 18, 2014 at 10:58 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Sun, Aug 17, 2014 at 08:34:13PM -0400, Barry Wardell wrote:
AEIThorns, LSUThorns
These stay where they are, except if a thorn author requests a move.
ExternalLibraries
These stay svn repos for now, until we implemented the newly proposed mechanism for downloading them.
GRHydro
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
I don't recall this decision. Do you have a pointer to the discussion?
I know that it is difficult to place GRHydro_InitData into a particular arrangement, but at the same time, reducing the number of arrangements is also important.
-erik
On 18 Aug 2014 15:41, "Erik Schnetter" schnetter@cct.lsu.edu wrote:
On Mon, Aug 18, 2014 at 10:58 AM, Frank Loeffler knarf@cct.lsu.edu
wrote:
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
I don't recall this decision. Do you have a pointer to the discussion?
I know that it is difficult to place GRHydro_InitData into a particular
arrangement, but at the same time, reducing the number of arrangements is also important.
As far as I remember this was suggested because GRHydro is internally a git repository, so it doesn't seem sensible to convert it to separate svn repositories only to convert back to git and merge again. I think the suggestion was to instead just directly use the GRHydro git repository.
Barry
Hello all,
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
I don't recall this decision. Do you have a pointer to the discussion?
There are notes on the wiki in the "repository transition" page, the closest thing to discussion notes are likely the minutes from 03/18/2014 (BTW: any progress on getting links to the archived email into the mailing list email footers? This would be really helpful and there were some suggestions on how to make this work on the trac ticket).
GRHydro_InitData would be treated as a "Test" thorn (not ID in there is actually used for a real simulation) and thus would be "related" to GRHydro. The two thorns are also very tightly coupled since GRHydro_InitData directly calls some of GRHydro's routines.
I know that it is difficult to place GRHydro_InitData into a particular
arrangement, but at the same time, reducing the number of arrangements is also important.
As far as I remember this was suggested because GRHydro is internally a git repository, so it doesn't seem sensible to convert it to separate svn repositories only to convert back to git and merge again. I think the suggestion was to instead just directly use the GRHydro git repository.
As far as I know there is no GRHydro git repository. The svn repo in the ET is the official GRHydro thorn.
There *is* a version of GRHydro that is in a git repository, namely the version in Caltech's Zelmani repository. This is actually where most development happens and for a long time I regularly would sync (by hand by cherry picking commits) the two repositories. Since I have not done so for a bit, I don't know how much they differ by now.
Zelmani contains other things than GRHydro (eg a copy of RNSID) so it cannot be made public in its entirety. Also the version of GRHydro in Zelmani is "experimental" and contain some hacks the were rejected from the svn repo (and it *will* fail often since all of Caltech's development happens there and the group tries many things).
So I would actually use the current svn repo as a starting point, then given that we may only want a single repo for all of it (which may not be feasible since eg some branches in Zelmani are used to provide a consistent set of thorns from *multiple* external repositories [eg McLachlan, LocalInterp]) make some branches for the Caltech and other stuff that will never make it into master.
Given the amount of changes and experiments going on in Zelmani it is (I suspect) not possible to have a situation where before an ET release we "clean up" and "safeguard" experiments in GRHydro and make the result the released version (this would introduce many half-baked things into the released version).
Yours, Roland
On Tue, Aug 19, 2014 at 4:25 PM, Roland Haas <roland.haas@physics.gatech.edu
wrote:
Hello all,
I might be wrong, but didn't we want GRHydro+GRHydro_Initdata as one "GRHydro" arrangement?
I don't recall this decision. Do you have a pointer to the discussion?
There are notes on the wiki in the "repository transition" page, the closest thing to discussion notes are likely the minutes from 03/18/2014 (BTW: any progress on getting links to the archived email into the mailing list email footers? This would be really helpful and there were some suggestions on how to make this work on the trac ticket).
GRHydro_InitData would be treated as a "Test" thorn (not ID in there is actually used for a real simulation) and thus would be "related" to GRHydro. The two thorns are also very tightly coupled since GRHydro_InitData directly calls some of GRHydro's routines.
I suggest to keep GRHydro in EinsteinEvolve, and to either have GRHydro_InitData there as well, or maybe to move it to EinsteinTest, and maybe rename it to GRHydro_Test.
-erik
I know that it is difficult to place GRHydro_InitData into a particular arrangement, but at the same time, reducing the number of arrangements is also important.
As far as I remember this was suggested because GRHydro is internally a
git
repository, so it doesn't seem sensible to convert it to separate svn repositories only to convert back to git and merge again. I think the suggestion was to instead just directly use the GRHydro git repository.
As far as I know there is no GRHydro git repository. The svn repo in the ET is the official GRHydro thorn.
There *is* a version of GRHydro that is in a git repository, namely the version in Caltech's Zelmani repository. This is actually where most development happens and for a long time I regularly would sync (by hand by cherry picking commits) the two repositories. Since I have not done so for a bit, I don't know how much they differ by now.
Zelmani contains other things than GRHydro (eg a copy of RNSID) so it cannot be made public in its entirety. Also the version of GRHydro in Zelmani is "experimental" and contain some hacks the were rejected from the svn repo (and it *will* fail often since all of Caltech's development happens there and the group tries many things).
So I would actually use the current svn repo as a starting point, then given that we may only want a single repo for all of it (which may not be feasible since eg some branches in Zelmani are used to provide a consistent set of thorns from *multiple* external repositories [eg McLachlan, LocalInterp]) make some branches for the Caltech and other stuff that will never make it into master.
Given the amount of changes and experiments going on in Zelmani it is (I suspect) not possible to have a situation where before an ET release we "clean up" and "safeguard" experiments in GRHydro and make the result the released version (this would introduce many half-baked things into the released version).
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
I suggest to keep GRHydro in EinsteinEvolve, and to either have GRHydro_InitData there as well, or maybe to move it to EinsteinTest, and maybe rename it to GRHydro_Test.
I would try and have both GRHydro and GRHydro_InitData in the same repository, since eg GRHydro_InitData has a test for con2prim which calls GRHydro's prim2con and con2prim routines directly. Renaming GRHydro_InitiData to GRHydroTest might also be a good idea (one an also most likely remove eg. the TOV code in there and the code that relied on BAM if that still exists, though that may have been only in WhiskyIVP).
There will likely be a bit of mess looking at all commits in EinsteinEvolve since most likely both IllinoisGRMHD and GRHydro (which are both in EinsteinEvolve) will see development so the commits will intersperse. However since the codes do not depend on each other, all rebases due to eg "git pull -r" should be fine.
Yours, Roland
On Tue, Aug 19, 2014 at 08:42:16PM -0700, Roland Haas wrote:
I would try and have both GRHydro and GRHydro_InitData in the same repository
I agree here. We should not split test thorns from the thorns they test, if they depend on each other as closely as these two do, depending on a case-by-case basis. I don't really care how the final repository is called (GRHydro/EinsteinEvolve), or what else is in there. It would just be impractical to split these two.
Frank
On Wed, Aug 20, 2014 at 9:48 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Tue, Aug 19, 2014 at 08:42:16PM -0700, Roland Haas wrote:
I would try and have both GRHydro and GRHydro_InitData in the same repository
I agree here. We should not split test thorns from the thorns they test, if they depend on each other as closely as these two do, depending on a case-by-case basis. I don't really care how the final repository is called (GRHydro/EinsteinEvolve), or what else is in there. It would just be impractical to split these two.
I have moved GRHydro and GRHydro_InitData into EinsteinEvolve. The repositories are based off the svn versions, as suggested by Roland.
Barry
Barry
Can we also convert Carpet in a similar way? I would like to combine the arrangements into a single arrangement, dropping some of the outdated thorns.
-erik
On Sun, Aug 17, 2014 at 8:34 PM, Barry Wardell barry.wardell@gmail.com wrote:
Hi,
Following on from the discussion in the last Einstein Toolkit meeting, this is an update of the status of the transition from svn to git.
- (Almost) all Cactus and Einstein Toolkit arrangements have now been
converted to git and merged into a one-repository-per-arrangement layout.
- The repositories are available on Bitbucket under the Cactus <
https://bitbucket.org/cactuscode%3E and EinsteinToolkit < https://bitbucket.org/einsteintoolkit%3E team pages.
- The git testing thornlist <
http://svn.einsteintoolkit.org/manifest/trunk/git_testing.th%3E has been updated to point to the new repositories. I have verified that it is possible to checkout and build the Einstein Toolkit using this thornlist.
- The conversion process is automated using scripts provided in the ET git
transition repository https://bitbucket.org/ianhinder/etgittransition.
- All master, ET release and Cactus release branches have been checked to
perfectly match (i.e. no missing commits, no file differences) their svn counterparts. Similarly for the ET and Cactus release tags.
- There is a list of known outstanding issues available <
https://bitbucket.org/ianhinder/etgittransition/src/master/issues.md%3E. It's likely that most, if not all of these issues are sufficiently minor that they can be ignored.
To proceed further it would be helpful if people (particularly those responsible for maintaining thorns and those who have opinions on how the final layout should appear) could take a look at the repositories and report any issues or suggested changes. In particular, it would be helpful to have feedback on how to handle AEIThorns, LSUThorns, ExternalLibraries, GRHydro, and the TAT thorns.
Regards, Barry
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Barry Wardell -
Erik Schnetter -
Frank Loeffler -
Roland Haas