#919: simfactory fails for standard thornlist copied using sync ---------------------+------------------------------------------------------ Reporter: knarf | Owner: eschnett Type: defect | Status: review Priority: major | Milestone: ET_2012_05 Component: Other | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
Review: ok with me to remove enabled-thorns for the release.
I am sorry if I sounded so very aggressive (and I am aware that I have been only complaining about simfactory but not actually put in work of fixing it).
As for modifying existing files: what would already help would be if the "silent" modifcations were all collected in one place in the simfactory code. Right now the "TerminationTrigger::max_walltime" replacement is hard coded in lib/simrestart.py.
I agree that distributing parameter files (eg in test suites) that only work with simfactory is not a good idea since there are many users around that do not use simfactory but rather their own solutions (at least two of out the Cactus users at Caltech fall in that category). On the other hand sample parameter files in a thorns par directory should face fewer restrictions since they are intended to be examples, so if someone wants to contribute a very fancy parameter file that eg. reads in Meudon data, solves the BNS inspiral with all the bells and whistles turned on then they are welcome to use whatever method of producing parameter files they choose. The '@@' tags are not really that hard to understand I find :-)
Since we seem to be accumulating Trac issues with simfactory faster than for any other component (right now: 93 open simfactory tickets vs. 62 for Cactus which is the next biggest chunk), I'd like to suggest the following (this was originally prepared within <RANT>...</RANT> tags so hopefully I sufficiently defused the wording when copying it in):
We do not currently seem to have anyone in the project who is the official maintainer of simfactory (since Michael Thomas left LSU), yes? At least no one who feels confident enough and actually has time to fix bugs as they are reported? I admit that I am not very good at fixing bugs in simfactory since I most often find the code hard to understand and too deeply nested. Given that we consider simfactory one of our core components should we at one point schedule an EVO/Skype/Email/IM simfactory bug sqashing session to try and reduce the number and more maintainers become familarized enough with the internals?