See commit b627924a4bf104521b567d3aa3dc80c864325b1a
Allwmake: Added scripted changes for REALTYPEWIDTH and IDXTYPEWIDTH
Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2085
Rather than requiring each functionObject to handle failed construction
internally (using the active_ flag) the static member function "viable"
is provided which returns true if construction of the functionObject is
likely to be successful. Failed construction is then handled by the
wrapper-class which constructs the functionObject,
e.g. "OutputFilterFunctionObject".
Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so
volScalarField::DimensionedInternalField -> volScalarField::Internal
In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions. To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.
Patch contributed by Bruno Santos:
- "etc/config.sh/CGAL":
- Indented the contents of the recently added if block.
- Added comment about using system versions.
- Library paths are now only added if the respective version is not "boost-system" and "cgal-system".
- "src/renumber/Allwmake":
It now relies on the previous file to get the version for
Boost (the same way as in "makeCGAL"). This is so that it will also
build "SloanRenumber" if "boost_version" is set to "boost-system".
- "applications/utilities/mesh/generation/Allwmake":
It now also relies on the script "config.sh/CGAL" to get the
version for CGAL. If "cgal_version" is set to "cgal-system", it
will now also build "foamy*Mesh" utilities and respective
libraries.
Resolves report http://www.openfoam.org/mantisbt/view.php?id=1232
1. "foamCompiler" was changed to a more permanent "WM_COMPILER_TYPE"
environment variable, so that it can be used by 3rd party
installation scripts, such as "makeGcc", "makeLLVM" and so on. More
on this will be provided in issue #1215.
2. The script functions such as "_foamSource()" and "_foamAddPath()"
were moved to a new file "etc/config.sh/functions". It has the
ability to set or unset, depending on whether "WM_BASH_FUNCTIONS" is
defined or not. This allows for these functions to be reused by
other scripts, such as "makeGcc".
3. The script "etc/config.sh/CGAL" relies on whether a local
environment variable "SOURCE_CGAL_VERSIONS_ONLY" is defined or not,
so that it will load only the version settings if it's defined. This
is to make it easier to call this script from "makeCGAL". Although
it still feels a bit of a clunky hack, but I didn't manage to deduce
any other way we could do this :( I didn't add indentation within
the if-block, to make it easier to read the changes. In addition,
the local variable "common_path" is used to shorten the length of
the lines and use slightly less repeated code.
4. Added another new script "etc/config.sh/compiler", which has only
the version numbers for the compilers taken out from the "settings"
file. It currently depends on "WM_COMPILER_TYPE" for setting the
variables, the same way it did with "foamCompiler". This script is
now always sourced from the "settings" file, for the following
reasons:
- "makeGCC" and "makeLLVM" can now take advantage of this script file.
- The example "compiler" script (detailed next) can rely on this
script file and then override parameters on-demand, as well as
allowing for system compilers to have dedicated settings, such as
setting "WM_CC". This is similar to how the example environment
script for "paraview" works.
5. To the script "etc/config.sh/example/compiler" were added a few more examples:
- It now starts with a block where it first loads the default "compiler" script.
- Has a "WM_COMPILER=Gcc48u" case example for when we try to use GCC
4.8 in Ubuntu 15.10. This is just to give the idea that in a
particular system, we might have several system-wide compiler
versions. For example, in Ubuntu 15.10, there is GCC 4.7, 4.8 and
5.2, which could be used for testing performances or compatibility
with some other 3rd party library.
- Has the "WM_COMPILER=Icc" case example, related to the original bug
report, where "WM_CC=icc" and "WM_CXX=icpc", so that the user then
simply copies this file to their own local preferences folder.
6. Small bug fix in "etc/config.sh/mpi", where unsetting "minBufferSize" was missing at the end of the script.
7. Small change in "etc/config.sh/paraview", where "CMAKE_ROOT" is set
along with "CMAKE_HOME". This is due to a rare issue that occurs on
people's systems where they have a custom system-wide CMake version
installed and which is used by having "CMAKE_ROOT" set on that
environment. This can mess up OpenFOAM's custom ParaView builds,
given that conflicting CMake versions can lead to not building
ParaView at all.
- For more details about "CMAKE_ROOT":
https://cmake.org/Wiki/CMake_Useful_Variables [^]
8. The scripts "_foamAddPath _foamAddLib _foamAddMan" were not being
unset at the end of "settings". They are now unset at the end of
"bashrc", through a call to the new double-use "functions" script.
Additionally all references to "foamCompiler" have been changed to
"WM_COMPILER_TYPE".
See also http://www.openfoam.org/mantisbt/view.php?id=1232
etc/config.sh and etc/config.csh
This structure is more convenient to add support for other shells, e.g. zsh, fish etc.
Resolves feature request to simplify support for other shells in
http://www.openfoam.org/mantisbt/view.php?id=1232
Function1 is an abstract base-class of run-time selectable unary
functions which may be composed of other Function1's allowing the user
to specify complex functions of a single scalar variable, e.g. time.
The implementations need not be a simple or continuous functions;
interpolated tables and polynomials are also supported. In fact form of
mapping between a single scalar input and a single primitive type output
is supportable.
The primary application of Function1 is in time-varying boundary
conditions, it also used for other functions of time, e.g. injected mass
is spray simulations but is not limited to functions of time.
