The ET should handle "optional" thorns (OpenCL ect) in a better way.

Create issue
Issue #1532 open
Roland Haas created an issue

Currently, some thorns within the ET only work on some machines (for good reasons), and are thus disabled by default in the thornlist. This has several problems (they are not checked out by default, nor then synced to machines where they are supported and might be needed). We need to improve this.

We could find a way to tag these as "optional" and then have a corresponding tag per machine that can enable them, if they are present. This way (at least most of them) could always be checked out, but Cactus would skip their compilation if they are not present, or not supported on that machine (indicated by something "missing" in the option list probably).

Keyword:

Comments (11)

  1. Frank Löffler
    • changed status to resolved
    • removed comment

    I disabled these on bluewaters. Currently, this option should probably only be used on a user-by-user basis, and not as default. Even if a thorn is present a user might not want to compile it in a configuration, so even then I don't think doing just that would be correct.

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

    "Even if a thorn is present a user might not want to compile it in a configuration"

    That is true for many thorns.

    What we need to address instead is that these thorns -- which are fully functional, are part of the ET, and are working fine on Blue Waters -- are not checked out automatically.

  3. Frank Löffler
    • removed comment

    In todays call a workaround was discussed: putting optional thorns "commented" into the thornlist, analogous to some documentation repositories right now - and to use the enabled-thorns mechanism in simfactory. This would have everyone checkout all thorns, but Cactus would not build all by default. Simfactory can then, on a machine-basis enable thorns.

    The downside would be (and we would need to discuss this), that this only works well for a complete ET checkout. Any other application using simfactory would will fail, because it might not contain all the optional thorns listed (still as required for some machine). The simplest case is an empty thornlist, no thorns checked out. This should only compile the flesh, and should probably always work. It wouldn't with this mechanism.

  4. Frank Löffler
    • removed comment

    An empty thornlist (assuming I check out the flesh and some tools, obviously), would not contain thorns mentioned as 'enabled-thorns' in simfactory. Wouldn't simfactory add them to the 'to-be-compiled' thornlist, forcing Cactus to complain while building about them being missing?

  5. Ian Hinder
    • removed comment

    If the thorns are commented in the thornlist, how do they get checked out?

    I think that when someone downloads the ET, everything should be downloaded. It should then all be synced to remote machines. What we need to decide is at what point the thorns which don't work there acknowledge this fact. When running tests etc, I don't want to have to do something special for certain machines.

    One solution is for the thorns to complain at run-time, but only if they are used. So if I have an OpenCL thorn, Cactus would still successfully build the thornlist, but at runtime, if I try to activate the thorn, it will complain that it does not work on this machine. This would have the effect that tests would fail rather than just not be run, and this option might be difficult to implement.

    The alternative is to have an external agent (simfactory) responsible for modifying thornlists, which I don't like very much, as it leads to a lot of confusion, as most people think the thornlist they see is the one that Cactus uses, not a modified thornlist. But this might be the best overall solution. Rather than having an enabled-thorns entry, I think we should have a disabled-thorns entry; after all, it should be exceptional that thorns fail to work. SimFactory could also add a message to the thornlist explaining that it has disabled the thorn, so that someone who digs into the configs directory to find out why a thorn is not compiled in will see the reason. I still don't like the fact that users will be surprised that the thorn just isn't included in the executable, despite it being in the thornlist. Maybe we can put a comment in the main ET thornlist next to each of these thorns which explains that it is disabled on some machines, and to look in the mdb file to see which ones. The downside of using disabled vs enabled is that thorns using libraries which are not available everywhere will cause trouble for new users unless we build those libraries ourselves.

    This is not an easy problem to solve.

  6. Frank Löffler
    • removed comment

    They are not commented out, at least not for GetComponents. They appear in the one (!) line after !CHECKOUT. Cactus ignores that one line, GetComponents does not.

  7. Erik Schnetter
    • removed comment

    Empty thornlists: Simfactory does not add thorns to the thorn list, it enables them in the sense of removing the comment character. If a thorn is not there (and commented out), it will not be added.

  8. Frank Löffler
    • removed comment

    I see. Good - then other projects would indeed work with this solution. Thanks for the clarification. That also means that the thorns in the ET thornlist would need to be listed twice. Certainly not nice, but something I could live with for now.

  9. Roland Haas reporter
    • removed comment

    The alternative is to have an external agent (simfactory) responsible for modifying thornlists, which I don't like very much, as it leads to a lot of confusion, as most people think the thornlist they see is the one that Cactus uses, not a modified thornlist. But this might be the best overall solution. Rather than having an enabled-thorns entry, I think we should have a disabled-thorns entry; after all, it should be exceptional that thorns fail to work. SimFactory could also add a message to the thornlist explaining that it has disabled the thorn, so that someone who digs into the configs directory to find out why a thorn is not compiled in will see the reason. I still don't like the fact that users will be surprised that the thorn just isn't included in the executable, despite it being in the thornlist. Maybe we can put a comment in the main ET thornlist next to each of these thorns which explains that it is disabled on some machines, and to look in the mdb file to see which ones. The downside of using disabled vs enabled is that thorns using libraries which are not available everywhere will cause trouble for new users unless we build those libraries ourselves.

    The thorns in question are the OpenCL thorns. They do in fact fail to run on most machines.

  10. Log in to comment