I am proposing an improved ThirdParty packages selection mechanism based on a set of package-specific, pre-defined environment variables.
Using those environment variables, one can control the selection of the full list of ThirdParty packages he/she want to compile/use by simply editing the etc/prefs.sh or etc/prefs.csh file.
Using this new approach, you will no longer have to edit the ThirdParty/AllMake.stageXXX files or the etc/settings.[sh,csh] to suit your needs; every supported package is selectable from a single environment variable specified in your prefs.[sh,csh] file, or in one of your script file.
Another benefit from this improvement will also come from supplying a set of predefined prefs.[sh,csh]-EXAMPLE files for both generic or specialized configurations and/or for specific Operating Systems. For example:
prefs.sh-EXAMPLE-Centos-7
prefs.sh-EXAMPLE-Ubuntu-14.02
prefs.sh-EXAMPLE-MacOSX_Yosemite_without_MacPorts
prefs.sh-EXAMPLE-RaspberryPi2
I also took the liberty of bumping many ThirdParty packages to the latest version available.
Pointed out by Henrik Rusche: Foam loses memory and the cause is the profiling code.
Reason was that as singleton was created with the first Time-object but never created (ratio was that when the Time-object is destroyed the program ends anyway)
This merge request fixes this by destroying the singleton in the destructor of the Time-object. The second commit makes sure that only the Time-object that created the singleton will destroy it (this is important for programs that have more than one instance of Time)
profilingPool-singleton also destroys it (for programs with more than one
Time-instance)
Also protect the initiation and destruction of the singleton so that only a
Time-instance can do this
This is a major modification to the definition and handling of global control switches, namely the DebugSwitches, InfoSwitches, OptimisationSwitches, Tolerances and DimensionedConstants defined in the
Those values are now defined as objects, and are no longer defined using simple types like scalar or int.
It is now possible to override any of those control switches from the command-line, like this:
simpleFoam -help
Usage: simpleFoam [-DebugSwitches key1=val1,key2=val2,...] [-DimensionedConstants key1=val1,key2=val2,...] [-InfoSwitches key1=val1,key2=val2,...] [-OptimisationSwitches key1=val1,key2=val2,...] [-Tol
or
simpleFoam -DebugSwitches fvVectorMatrix=1,fvScalarMatrix=1
The 'banana' test is also implemented in order to dump the list of all the known control switches for a given application. One can use any bogus key name in order to get the list:
simpleFoam -DebugSwitches banana=1
The global controlDict file '$WM_PROJECT_DIR/etc/controlDict' is gone. One can still use a file to override a whole bunch of control switches by using the environment variable FOAM_GLOBAL_CONTROLDICT
One can also override case specific controlSwitches by using the case system/controlDict file.
Here is the order of precedence for the definition/overriding of the control switches, from lowest to highest:
- source code definitions from the various libraries/solvers
- file specified by the env. variable FOAM_GLOBAL_CONTROLDICT
- case's system/controlDict file
- command-line parameters
The application 'foamDebugSwitches' is gone. Instead, one can use the command-line option '-dumpControlSwitches' to print at the console the full list of control switches for a given application. The
At the source code level, when creating a control switch object, one can now add an optional description string in order to document its behaviour or purpose. That string description will be written a
Martin Beaudoin
Reorganisation of global controlDict by Hrvoje Jasak.
