Hello all,
> I see the enabling/disabling of thorns like CUDA and MPI as part of
> the configuration process, just like deciding what compiler flags to
> use. On most machines you will fight hard to get the configuration
> right without Simfactory, and it's not much different than that.
Modifying the thornlist has a bit of a different flavor to it since (as
Steve pointed out) there is no outward sign ("@", special comment or
anything) that simfactory will modify the file. The file also does not
look like an obvious template and could be (and must since there are
many users out there that do not use the simfactory executable, only the
simfactory option lists) used without simfactory. This is similar to
simfactories current (it still does that, yes?) behaviour of scanning a
parfile for TerminationTrigger::max_walltime (which I *also* find
questionable but was apparently put in on explicit user request).If we do not want to turn them on by default (we *do* turn off some thorns we know won't compile but turning something *on* may be different since the configuration is just fine even without the thorns) then users have the option of adding an "enabled-thorns" line to the bluewaters section of their defs.local.ini file. This avoids having to modify any file that is the ET svn and (for bluewaters) users have to provide such a section anyway to specify their allocation. If we enable the thorns by default (this would be a the first time we do so, yes? At least outside of machines like nvidia or the PI computeN machines which are semi-private anyway) then we should check that compiling them is not unusually slow (though almost anything will compile faster than GRHydro these days) and does not pull in strange dependencies. So far (to me) the ET supplied thornlist had more of a character of a master thorn list that compiles as much of the toolkit as is practical (eg not Petsc since it is hard to get to work or Boost since it is huge). So in light of this I would think that the proposed solution of commenting out the OpenCL/CUDA etc thorns with a distinct comment like !DISABLED or !REQUIRES-CUDA (and then have simfactory modify only lines that start with !DISABLED or !REQUIRES.*) would seem like a decent compromise between having thorn lists that can be used without simfactory, having most of the information present at one spot (rather than in the thornlist, the machine.ini file, defs.local.ini, the simfactory sources) and allowing the use of a master thorn list in the repository. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
