Quoting Ian Hinder <ian.hin...@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 _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users