[ET Trac] [Einstein Toolkit] #515: Silently overrides DEBUG and OPTIMISE options

[Einstein Toolkit]

#515: Silently overrides DEBUG and OPTIMISE options
----------------------------+-----------------------------------------------
  Reporter:  barry.wardell  |       Owner:  eschnett
      Type:  defect         |      Status:  new     
  Priority:  major          |   Milestone:          
 Component:  SimFactory     |     Version:          
Resolution:                 |    Keywords:          
----------------------------+-----------------------------------------------

Comment (by eschnett):

 The option --debug is not about debugging symbols. As you say, there is
 almost never a reason to run without them, since the don't slow down the
 code and don't increase memory usage; the only reason to disable them
 would be if they cause an internal compiler error. What --debug does is
 enable additional debug statements in the code which perform self-tests
 and thus lead to a slower execution. Such tests could include checking for
 integer overflow, checking array bounds in Fortran, etc. What you instead
 may want to use in your case is --no-optimise, which disables optimisation
 (without adding these debug statements); this still lets you debug, but
 runs faster.

 Cactus outputs all its configuration settings when it configures, such as
 "Setting DEBUG to 'yes'". The options --debug, --optimise etc. should be
 documented, as they are prominent features.

 Yes, simfactory overwrites certain settings. Simfactory assumes that the
 MDB entries are correct, and thus propagates these settings, such as the
 cache size. The option list and the MDB really belong together and form a
 unit; it is an "implementation detail" that the option lists are stored in
 a different file and with a different format.

 In general, --debug and --optimise do not conflict. It is just that these
 don't make sense together, because --debug enables somewhat expensive
 additional self-checks, and --optimise tries to improve execution speed,
 so these goals conflict. In practice, many compilers segfault when these
 two are given together. To protect new users, the default for --optimise
 depends on the setting for --debug. It seems that the current
 implementation in simfactory doesn't quite do that, as it unconditionally
 sets --optimise when --debug is set. (--optimise isn't quite useless,
 because you can still specify --no-optimise.)

 Enabling --debug by default on a particular machine goes a bit against the
 idea of simfactory, which is to make things independent on particular
 machines. I envisioned that you have probably two configurations, one for
 debugging and one for production, and these configurations would both
 potentially exist on multiple machines. This allows you e.g. to take a
 debug session from your laptop and move on to a larger workstation if you
 run out of memory; for this to work reliably, the configuration settings
 (source tree, thorn list, etc.) need to be independent of the machine on
 which one is running. This is the working model that "sim sync" enables.
 That is, you would choose two configuration names (maybe "sim-debug" and
 "sim") for these two purposes, and sync/build these on several systems. To
 build the debug configuration, you say "sim build --debug", and "sim
 build" to build the production simulation; as described in
 <https://docs.einsteintoolkit.org/et-
 docs/Simulation_Factory_Advanced_Tutorial>.

 Your second patch is fine, please apply.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/515#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit