[Users] Enabling CUDA/OpenCL thorns by default in Simfactory?

Thu May 29 07:22:48 CDT 2014

On 05/28/2014 09:29 AM, Erik Schnetter wrote:
> 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.
Does Simfactory enable commented out thorns, or does it add them?

Cheers,
Steve
>
> -erik
>
> On Wed, May 28, 2014 at 6:24 AM, Steven R. Brandt <sbrandt at cct.lsu.edu 
> <mailto:sbrandt at cct.lsu.edu>> 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 <schnetter at cct.lsu.edu
>>     <mailto:schnetter at cct.lsu.edu>> wrote:
>>
>>>     On Tue, May 27, 2014 at 10:51 AM, Frank Loeffler
>>>     <knarf at cct.lsu.edu <mailto:knarf at cct.lsu.edu>> 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 list
>>     Users at einsteintoolkit.org  <mailto:Users at einsteintoolkit.org>
>>     http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
>     _______________________________________________
>     Users mailing list
>     Users at einsteintoolkit.org <mailto:Users at einsteintoolkit.org>
>     http://lists.einsteintoolkit.org/mailman/listinfo/users
>
>
>
>
> -- 
> Erik Schnetter <schnetter at cct.lsu.edu <mailto:schnetter at cct.lsu.edu>>
> http://www.perimeterinstitute.ca/personal/eschnetter/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20140529/6d1d937d/attachment.html