simfactory knows about TerminationTrigger but not TriggerTerminationManual

Comments (14)

1. 

   Frank Löffler reporter

   • changed version to development version
   • changed status to open
   • changed milestone to ET_2013_05
   • removed comment

   • 2013-03-02T22:21:37+00:00
2. 

   Erik Schnetter

   • removed comment

   There should not be two thorns that essentially do the same thing. Simfactory should support only the thorn found in the Einstein Toolkit.

   TriggerTerminationManual can be handled via an additional command line argument to Simfactory; something like

   --replace=TriggerTerminationManual::walltime=@WALLTIME@
   

   should do the trick. ("--replace" replaces options and parameter values.)

   • 2013-03-03T10:26:17+00:00
3. 

   Ian Hinder

   • removed comment

   I would argue that SimFactory should not be in the business of supporting individual thorns; it shouldn't really know anything about Cactus either! Perhaps it would be better for SimFactory to expose this sort of information in some other way. I would suggest environment variables which can be picked up by the thorn, but there are probably issues with ensuring that the full environment is available on every MPI process.

   Why can the user not just put @WALLTIME@ into their parameter file? That is the solution that I always use. Is this because they might want to use their parameter file without simfactory?

   • 2013-03-03T11:24:25+00:00
4. 

   Frank Löffler reporter

   • removed comment

   Replying to [comment:3 hinder]:

   I would argue that SimFactory should not be in the business of supporting individual thorns.

   I agree. The command line option might work, but I wouldn't want to type this every time, or forget doing so.

   Why can the user not just put @WALLTIME@ into their parameter file? That is the solution that I always use. Is this because they might want to use their parameter file without simfactory?

   Yes, in 'my' case this is the case as well. It it much more convenient to have parameter files also work without simfactory.

   • 2013-03-03T11:43:42+00:00
5. 

   Erik Schnetter

   • removed comment

   Ideally, this replacement would be in defs.local.ini, and probably also in the Einstein Toolkit example for the defs.local.ini.

   • 2013-03-03T13:33:39+00:00
6. 

   Roland Haas

   • removed comment

   Yes, keeping hard-coded file manipulation code out of simfactory's executables sounds like a good idea.

   • 2013-03-03T14:19:03+00:00
7. 

   Frank Löffler reporter

   • removed comment

   Following this, the code for TerminationTrigger should also go to a configuration file?

   • 2013-03-03T14:46:01+00:00
8. 

   Erik Schnetter

   • removed comment

   I was thinking of adding a facility whereby one can add arbitrary "replace" statements to defs.local.ini. The code handling TerminationTrigger should then also go there (or maybe into defs.ini).

   • 2013-03-03T15:08:44+00:00
9. 

   Frank Löffler reporter

   • removed comment

   Good idea. Could we apply the patch until this new facility is in place?

   • 2013-04-25T09:13:43+00:00
10. 

    Erik Schnetter

    • removed comment

    I am not convinced that it is a good idea to support a new thorn that is not part of the Einstein Toolkit. Does TriggerTerminationManual have any features that make it superior to TerminationTrigger? Is there a plan to propose it for inclusion into the Einstein Toolkit?

    At the moment, having a private modification to Simfactory seems like a workable solution. In the long run, the best course of action may be to switch to using TerminationTrigger.

    • 2013-04-25T09:29:12+00:00
11. 

    Frank Löffler reporter

    • removed comment

    Ideally, the two thorns should be merged. I proposed the patch since TriggerTerminationManual seems to be used quite a bit especially at Caltech, and the patch is so trivial. Also, I don't think simfactory must only support thorns included in the ET. On the other hand, I agree that some pressure to actually merge the two thorns might do good in the end. :)

    • 2013-04-25T09:33:15+00:00
12. 

    Erik Schnetter

    • removed comment

    TerminationTrigger started as a merge and cleanup of TriggerTerminationManual and another, similar thorn at the AEI. Unfortunately, people never switched...

    • 2013-04-25T09:41:55+00:00
13. 

    Frank Löffler reporter

    • changed status to resolved
    • removed comment

    • 2013-05-10T13:26:48+00:00
14. 

    Roland Haas

    • changed status to closed
    • edited description

    • 2019-02-21T20:07:25+00:00
15. Log in to comment