#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- 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.
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by knarf):
* status: new => review * version: => development version * milestone: => ET_2013_05
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
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.)
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
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?
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
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.
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
Ideally, this replacement would be in defs.local.ini, and probably also in the Einstein Toolkit example for the defs.local.ini.
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
Yes, keeping hard-code file manipulation code out of simfactories executables sounds like a good idea.
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
Following this, the code for TerminationTrigger should also go to a configuration file?
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
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).
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
Good idea. Could we apply the patch until this new facility is in place?
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
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.
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by knarf):
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. :)
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: review Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by eschnett):
TerminationTrigger started as a merge and cleanup of TriggerTerminationManual and another, similar thorn at the AEI. Unfortunately, people never switched...
#1275: simfactory knows about TerminationTrigger but not TriggerTerminationManual --------------------------+------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: closed Priority: minor | Milestone: ET_2013_05 Component: SimFactory | Version: development version Resolution: wontfix | Keywords: --------------------------+------------------------------------------------- Changes (by knarf):
* status: review => closed * resolution: => wontfix
trac@lists.einsteintoolkit.org