[ET Trac] [Einstein Toolkit] #919: simfactory fails for standard thornlist copied using sync

[Einstein Toolkit]

#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?

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/919#comment:11>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit