Steve Simfactory can do both. Disabling certain thorns is used for exceptions, e.g. if a machine is currently broken and can currently not build a particular thorn. If this thorn is "unimportant" (e.g. pciutils), then most likely no one will notice. Of course, disabling BSSN in this way would not be a good idea.
-erik On Wed, May 28, 2014 at 6:24 AM, Steven R. Brandt <[email protected]>wrote: > I think that processing things inside comments is confusing (if that's > what's happening), unless there's some special tag in the comment, e.g. @@. > Wouldn't it make more sense for SimFactory to accept the list of > uncommented thorns, and disable if appropriate? > > Cheers, > Steve > > > On 05/27/2014 12:01 PM, Ian Hinder wrote: > > > On 27 May 2014, at 17:23, Erik Schnetter <[email protected]> wrote: > > On Tue, May 27, 2014 at 10:51 AM, Frank Loeffler <[email protected]>wrote: > >> On Tue, May 27, 2014 at 09:46:29AM -0500, Frank Loeffler wrote: >> > Wouldn't that mean that every checkout on such a machine fails, because >> > simfactory would unconditionally add these thorns to the thornlist, >> > regardless of whether they are actually present or not? >> >> Replying to myself: Is this really what Simfactory does - or does it >> only "enable" these thorns when they are present in the thornlist, but >> commented out? If the latter is the case I think it should be fine, >> although it might still confuse people that don't even look at the >> simfactory configuration of the machine, and use a thornlist with such a >> thorn commented out, but not present. Could we somehow let these users >> give a hint why Cactus fails with 'thorn not found', when the original >> thornlist clearly commented it out? >> > > As per our previous discussion, the standard ET thorn list will (and > this is the current state) > 1. Check out all CUDA and OpenCL thorns, on ALL machines > 2. Disable all CUDA and OpenCL thorns when building Cactus, on ALL machines > If you are using this standard thorn list directly, then this is the only > reasonable way to go; other choices don't make sense. > > Simfactory pre-processes thorn lists, in the same way it pre-processes > option lists and parameter files, expanding variables. It is important to > have such a pre-processing step, since it avoids having to do this > manually. This is how Simfactory "fixes" things for various machines, it is > an important part of how it works. > > Blue Waters supports both CUDA and OpenCL. We now have two options: > 1. Use the standard ET thorn list there, i.e. disabling CUDA and OpenCL by > default > 2. Automatically enable CUDA and OpenCL thorns > > As others mentioned, it does not make sense to enable CUDA and OpenCL > everywhere, since it would not be supported everywhere. Enabling the thorns > but adding a mechanism that turns these thorns into dummy thorns that do > nothing also doesn't make sense -- think of a BSSN thorn written in CUDA; > turning it into a dummy thorn that does nothing on a non-CUDA machine would > just mean that BSSN evolution doesn't happen there. There are machines that > support CUDA and there are machines that don't, and if you want to use CUDA > then you will need to get an error message when you try to use a machine > that doesn't support CUDA. > > So -- how do we want to support CUDA on Blue Waters? > > 1. Ask people to manually change the thorn list, in effect asking them > to maintain one thorn list per machine > 2. Let Simfactory do this, since it already knows what works on what > machine and what doesn't > > I don't think there are any other choices. > > In case you are wondering: What I propose won't break checking out > thorns on any machine, and won't break the build on any machine, and won't > require people to do special things for special machines. I regularly build > on many machines, and I do so in an automated manner, and I don't maintain > per-machine thorn lists or parameter files. Simfactory has an MDB that > encodes all the machines' peculiarities, and the information there is > sufficient to use all of our machines efficiently, and in an automated > manner. > > There is the argument of "this would surprise people". If we are worried > about people being surprised that a CUDA thorn can't be activated on a > non-CUDA machine, then maybe we need to raise our expectations a bit. > > > I have been "surprised" in the past when I saw a thorn commented out in > the thornlist, and Cactus trying to build it because SimFactory has enabled > it on a particular machine. I had no idea what was going on, and couldn't > believe that simfactory was doing this when I found that it was. I think > if something is commented out, it should be ignored. > > Maybe we could add a feature to the Cactus thornlist language for > "included if available"? e.g. > > ? Arrangement/Thorn > > SimFactory could expand this, and Cactus would ignore it by default. > This is similar to the existing "!" comments which are used by > GetComponents, and ignored by Cactus. At least this way, it doesn't look > like it has been commented out. > > -- > Ian Hinder > http://numrel.aei.mpg.de/people/hinder > > > > _______________________________________________ > Users mailing > [email protected]http://lists.einsteintoolkit.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.einsteintoolkit.org/mailman/listinfo/users > > -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
