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 <[email protected] <mailto:[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]
    <mailto:[email protected]>> wrote:

    On Tue, May 27, 2014 at 10:51 AM, Frank Loeffler
    <[email protected] <mailto:[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 list
    [email protected]  <mailto:[email protected]>
    http://lists.einsteintoolkit.org/mailman/listinfo/users


    _______________________________________________
    Users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.einsteintoolkit.org/mailman/listinfo/users




--
Erik Schnetter <[email protected] <mailto:[email protected]>>
http://www.perimeterinstitute.ca/personal/eschnetter/

_______________________________________________
Users mailing list
[email protected]
http://lists.einsteintoolkit.org/mailman/listinfo/users

Reply via email to