Hello all,
Present were: Peter, Steve, Christine, Ian, Elo, Matt, Roland
Tickets: 1667 include elliptic solver: * several options present themselves (1) use CactusEllitpic (2) use new arrangement Elliptic (3) use a arrangement collecting the author's thorns (4) postpone the decision * Roland objects to adding the solver to CactusElliptic since it is explicitly tied to Carpet and Carpet is not part of Cactus * a general issue exists in that we either have CactusXXX arrangements or EinsteinXXX arrangements but no neutral XXX arrangement
ET workshop: There will be an update email to the mailing list with instructions concerning on how to ask for time for a regular talk and how to sign up for lightning talks.
Yours, Roland
On 23/06/15 22:59, Roland Haas wrote:
Hello all,
Present were: Peter, Steve, Christine, Ian, Elo, Matt, Roland
Tickets: 1667 include elliptic solver:
- several options present themselves (1) use CactusEllitpic (2) use new
arrangement Elliptic (3) use a arrangement collecting the author's thorns (4) postpone the decision
- Roland objects to adding the solver to CactusElliptic since it is
explicitly tied to Carpet and Carpet is not part of Cactus
- a general issue exists in that we either have CactusXXX arrangements
or EinsteinXXX arrangements but no neutral XXX arrangement
Thanks Roland for summing up nicely the result of the discussion. It is true that historical reasons are creating a bit of an impasse with arrangements named *Elliptic: the existing CactusElliptic implies more about its thorns than the fact that they apply to elliptic problems; on the other hand, the creation of additional *Elliptic arrangements would make life harder for (and potentially hide tools from) users who are just looking for an elliptic solver.
I am now leaning towards a mix of (3) and (4), perhaps under the form of a *Thorns or *Development arrangement (replace * with "Cosmo", or my current institution, or any other meaningful prefix). It seems to me that arrangements named this way have been used as incubators for newborn thorns, which may or may not be moved elsewhere once it's clear where (or whether at all) they belong inside Cactus or the ET.
For instance, would anyone object to a CataniaThorns arrangement?
ET workshop: There will be an update email to the mailing list with instructions concerning on how to ask for time for a regular talk and how to sign up for lightning talks.
Roland made me notice that there was never a written call for talks for ET, so it's worth repeating here what we mentioned in past calls: if you have something you'd like to present at the ET workshop, please get in touch with either me or Oleg Korobkin. There will also be the opportunity to sign up for spontaneous, lighning talks on the first day of the workshop, but these will only give you about 5 minutes to pitch your project. If you need more time, please get in touch now.
Best, Eloisa
On 24 Jun 2015, at 12:24, Eloisa Bentivegna bentivegna@cct.lsu.edu wrote:
On 23/06/15 22:59, Roland Haas wrote:
Hello all,
Present were: Peter, Steve, Christine, Ian, Elo, Matt, Roland
Tickets: 1667 include elliptic solver:
- several options present themselves (1) use CactusEllitpic (2) use new
arrangement Elliptic (3) use a arrangement collecting the author's thorns (4) postpone the decision
- Roland objects to adding the solver to CactusElliptic since it is
explicitly tied to Carpet and Carpet is not part of Cactus
- a general issue exists in that we either have CactusXXX arrangements
or EinsteinXXX arrangements but no neutral XXX arrangement
Thanks Roland for summing up nicely the result of the discussion. It is true that historical reasons are creating a bit of an impasse with arrangements named *Elliptic: the existing CactusElliptic implies more about its thorns than the fact that they apply to elliptic problems; on the other hand, the creation of additional *Elliptic arrangements would make life harder for (and potentially hide tools from) users who are just looking for an elliptic solver.
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.
I am now leaning towards a mix of (3) and (4), perhaps under the form of a *Thorns or *Development arrangement (replace * with "Cosmo", or my current institution, or any other meaningful prefix). It seems to me that arrangements named this way have been used as incubators for newborn thorns, which may or may not be moved elsewhere once it's clear where (or whether at all) they belong inside Cactus or the ET.
For instance, would anyone object to a CataniaThorns arrangement?
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.
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
users@lists.einsteintoolkit.org
-
Eloisa Bentivegna -
Ian Hinder -
Roland Haas