Quoting Ian Hinder ian.hinder@aei.mpg.de:
Putting it in an institution-specific arrangement would do the same. In fact, it could be worse, as the name of the arrangement would not reflect the content, but the origin of the code, making it harder to find "an elliptic solver", if you didn't know where it was originally developed.
Well, I didn't suggest this as a definitive solution, but just as a temporary parking until we figure out where this code should go, based on interest and on what else gets developed. I do realize however that temporary solutions have the dangerous tendency to become de-facto final.
I wouldn't object, but it wouldn't be my first choice. The reason is that software authors tend to move between institutions, and code is often developed collaboratively between authors from different institutions. Very little of the code in AEIThorns is now developed by people at AEI, nor that in LSUThorns by people at LSU, and the TAT arrangements have nobody at TAT at all. So my preference would still be to have a place where "community" thorns can be placed. If this shouldn't be in an arrangement with a Cactus prefix, then I think we should create new arrangements.
$ ls AEIThorns LSUThorns TAT AEIThorns: ADMMass PunctureTracker Trigger AEILocalInterp SystemStatistics
LSUThorns: PeriodicCarpet QuasiLocalMeasures SummationByParts Vectors
TAT: TATPETSc TATelliptic
The non-GR-related thorns would all be covered by a "Numerical" and a "Utils" arrangement. If the Cactus* arrangements are off-limits, and the Einstein* arrangements are not appropriate due to the code not being related to the Einstein equations, then we should have an alternative for this sort of code. Note: I'm not suggesting that we actually move the above thorns (though for AEIThorns and LSUThorns we want to stop using the respective SVN servers, so we may take the opportunity to do so), I'm just illustrating how the thorns would fit into my proposed arrangements.
If Numerical and Utils are too generic, maybe we could have a prefix, such as Community, User, or something like that. But maybe Numerical and Utils are OK.
This suggestion sounds good to me. One could even conceive splitting off part of the helper thorn that currently comes with CT_MultiLevel to make a GR-specific interface to CT_MultiLevel (which could be included in e.g. EinsteinInitialData, just to be visible to users looking to solve the Einstein constraints).
Eloisa