- changed version to development version
- changed status to open
- changed milestone to ET_2013_05
- removed comment
simfactory knows about TerminationTrigger but not TriggerTerminationManual
Currently, simfactory knows about TerminationTrigger but not TriggerTerminationManual and sets the corresponding max_walltime parameter correctly for the first but not the second. This small patch does so also for the second thorn (found in Zelmani).
This should be independent of the question why there are two of these thorns (which would be a good one to answer), or whether one of them could be retired or both of them merged. They are currently both used in production and simfactory should know about both.
Keyword:
Comments (14)
-
reporter -
- 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.)
-
- 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?
-
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.
-
- removed comment
Ideally, this replacement would be in defs.local.ini, and probably also in the Einstein Toolkit example for the defs.local.ini.
-
- removed comment
Yes, keeping hard-coded file manipulation code out of simfactory's executables sounds like a good idea.
-
reporter - removed comment
Following this, the code for TerminationTrigger should also go to a configuration file?
-
- 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).
-
reporter - removed comment
Good idea. Could we apply the patch until this new facility is in place?
-
- 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.
-
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. :)
-
- removed comment
TerminationTrigger started as a merge and cleanup of TriggerTerminationManual and another, similar thorn at the AEI. Unfortunately, people never switched...
-
reporter - changed status to resolved
- removed comment
-
- changed status to closed
- edited description
- Log in to comment