Modify

Opened 5 years ago

Last modified 5 years ago

#1532 reopened enhancement

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

Reported by: Roland Haas Owned by: Erik Schnetter
Priority: minor Milestone:
Component: Cactus Version: development version
Keywords: Cc:

Description (last modified by Frank Löffler)

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).

Attachments (0)

Change History (11)

comment:1 Changed 5 years ago by Frank Löffler

Resolution: fixed
Status: newclosed

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.

comment:2 Changed 5 years ago by Erik Schnetter

Resolution: fixed
Status: closedreopened

"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.

comment:3 Changed 5 years ago by Frank Löffler

Component: SimFactoryCactus
Description: modified (diff)
Priority: majorminor
Summary: simfactories enabled-thorns does not check if a to be enabled thorn is actually presentThe ET should handle "optional" thorns (OpenCL ect) in a better way.
Type: defectenhancement

True. This isn't really a simfactory problem though. It already starts with GetComponents, so let's change the ticket accordingly.

comment:4 Changed 5 years ago by Frank Löffler

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.

comment:5 Changed 5 years ago by Erik Schnetter

An empty thorn list would work.

comment:6 Changed 5 years ago by Frank Löffler

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?

comment:7 Changed 5 years ago by Ian Hinder

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.

comment:8 Changed 5 years ago by Frank Löffler

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.

Last edited 5 years ago by Frank Löffler (previous) (diff)

comment:9 Changed 5 years ago by Erik Schnetter

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.

comment:10 Changed 5 years ago by Frank Löffler

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.

comment:11 in reply to:  7 Changed 5 years ago by Roland Haas

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as reopened The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.