simfactory fails for standard thornlist copied using sync

Issue #919 closed
Frank Löffler created an issue

Here is my workflow:

  • checkout ET on my local machine
  • 'sim sync remotemachine'
  • 'sim login remotemachine'
  • 'sim build --thornlist=./thornlists/einsteintoolkit.th'

This fails on lonestar because thorns are missing, specifically the OpenCL thorns. I can see why this is failing, but we should fix this before the release. Simfactory 'silentely' enabling thorns is harmful in this workflow of which I think it's not that unusual.

Keyword:

Comments (14)

  1. Frank Löffler reporter
    • removed comment

    The suggested command in the thornlist also doesn't work:

    $ ./bin/GetComponents -a --update --root=. manifest/einsteintoolkit.th

    Error: The URL for EinsteinExact/doc has changed, please perform a clean checkout.

  2. Erik Schnetter
    • changed status to open
    • removed comment

    I suggest to remove the "enabled-thorns" sections in Simfactory's MDB. People will then have to manually add/remove comments from thorn lists to use OpenCL (each time they synchronise), but they won't be surprised.

  3. Roland Haas
    • removed comment

    Simfactory 'silentely' enabling thorns is harmful in this workflow of which I think it's not that unusual.

    Yes please. This is the very same workflow that I use. I never do an actual checkout on the clusters (since for example I have darcs repositories in my usual checkout or modifications in local repositories) and consider the source code there read only and to be explicitly only a copy of the "master" source on my workstation.

    This does not seem to be the view taken by the original simfactory author but I would find it very convenient if simfactory would have an optional mode of operation that would not modify my provided files unless there are "@@" constructs. Eg. simfactory currently looks for occurences of TerminationTrigger options in the parameter file. Enabling thorns would also seem to be a bad idea to me since eg. I might not want to compile them since I use a different set of modules that will not let me compile them or just might want to keep my source tree as small as possible (eg on Kraken where Cactus lives in my home directory).

    This is just my very personal preference but in general I prefer a code that does only what I ask it to do (and might require more verbose options because of this) over a code that is helpful and then surprises me. Eg not http://www.catb.org/jargon/html/D/DWIM.html :-)

  4. Erik Schnetter
    • removed comment

    Roland's views were the same as those of the original Simfactory author. However, users complained loudly that having @@ constructs in thorn lists, option lists, or parameter files was inconvenient, because these then cannot be used without Simfactory any more. The suggested remedy was to provide "templates" that can be used without Simfactory (with reasonable default settings), and Simfactory would modify these according to its settings.

    I would like to stress that having @@ constructs in Simfactory's templates was indeed quite confusing to many people. Calling these e.g. "option list template" confused people ("what is a template?"), and with the instructions ("these are almost like real option lists, you only need to replace all @@ constructs by the settings you want") people complained ("there are syntax errors and strange @@ characters in there! your template is broken"). The original Simfactory author does not want to go back there.

    Now, one could take the stance that one simply tells people to read the documentation, but then it may be better to ask the experts to read the documentation...

    Please suggest something that makes things work out of the box for most novices, but still doesn't surprise you, and/or gives you full control if you want to disable this feature in Simfactory.

  5. Ian Hinder
    • removed comment

    If "most novices" are required to use simfactory with the ET, and we do not support people who try to run without it, then we can just insert the @...@ constructs into einsteintoolkit.th, and the thorns will then be clearly enabled or disabled by simfactory, and this will not surprise anyone who looks at the thornlist.

    Are we aiming to support people using the ET but not using SimFactory?

    In my opinion, inconveniencing and confusing simfactory users in order to keep non-simfactory users happy (i.e not having the @...@ constructs where they are needed) is not worth it. SimFactory is the standard in the ET, and this is what we should allocate resources to supporting.

    Would it be possible to teach Cactus to do something sensible with @...@ in its input files, like ignore the content?

  6. Erik Schnetter
    • removed comment

    It is perfectly fine to use Cactus without Simfactory; I expect many people to do so. It is also perfectly fine to use parts of Simfactory's MDB without using the remainder of Simfactory. Being surprised (and angry) at Simfactory's behaviour is fine as it leads to improvement; choosing radical solutions is not, since it drives people away. Simfactory has (sometimes strong) opinions about what is a "good way" of doing things, and in many cases people disagree -- mostly, because Simfactory is evolving, and finding a true "good way" of doing things requires experimentation and much feedback from the community.

    I am sure we can find a solution that is more of a consensus among the community.

    For example, if we expect most novice users to use Simfactory, then it needs to be much simpler to configure Simfactory and Cactus on random laptops and workstations. We would need examples for (say) the five most common operating systems, more elaborate self-checks, much better error messages, etc.

    One of the problems with Simfactory is that it wants to know a system's configuration up front. This requires people to find out all the details up front, instead of e.g. being able to do some of the work first and only being held up by a problem later -- which gives people a sense of progress. ("okay, now I've figured out to log in, now let's compile"; "okay, I managed to compile, now let's run".) Currently, Simfactory appears like a wall that doesn't let you through unless you specify details about a machine that you, otherwise, would only have to care about much later. In a way, that's like a web store that verifies your credit card credentials before it lets you browse: sure, this ensures you are not disappointed later, but will make people angry.

  7. Frank Löffler reporter
    • removed comment

    I think we are mixing issues now. The @..@ pairs were used in option lists. I think they were never used in thornlists so far. This issue is about _using_ simfactory in a way that I believe was envisioned as being one of the even recommended ways of using it - simply because it's the most convenient way to make sure to use exactly the same source everywhere.

    One way to deal with _this_ issue is to teach GetComponents about thorns which should be downloaded, but not used by Cactus (unless simfactory changes that). There is currently a way to mark components as such, which is fine for things like documentation components, but not really convenient for simfactory to parse (although it could be done).

    We could decide to use this mechanism and teach simfactory to look for 'disabled' thorns there, or teach GetComponents about another way to mark components as 'to be downloaded, but not used by Cactus' which simfactory then also needs to learn about in order to be able to enable certain thorns. In both cases, GetComponents would download _all_ components (unlike now), but Cactus would (using simfactory) not necessarily build all components. Not using simfactory would also still work, but would result in possibly less components than might work on a particular machine.

  8. Erik Schnetter
    • removed comment

    Note that I suggested a remedy for the release: Removing the "enabled-thorns" settings in the MDB entries. Please review this.

  9. Roland Haas
    • removed comment

    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?

  10. Ian Hinder
    • removed comment

    I don't think this is limited to the case where you sync from another machine. Or does GetComponents understand to check out commented out thorns in the thornlist by querying the simfactory MDB? Seems unlikely, and that this would be a problem even if you checked out on the remote machine using GetComponents.

  11. Erik Schnetter
    • changed status to resolved
    • removed comment

    I have removed the enabled-thorns section from the MDB.

    I will close this ticket since the original issue is now resolved. I will open another issue pointing to this one to preserve the discussion.

  12. Log in to comment