- on ArchLinux, everything is installed under /usr/include/scotch.
The detection script uses SCOTCH_ARCH_PATH as an initial guess for
ptscotch as well. However, on the second pass, it has an absolute
value ("/usr") instead of a logical one ("scotch-system").
This resulted in the logic for handling scotch+ptscotch subdirs
being bypassed.
- the problem arises when output fields are missing on some
processors.
When the information is combined, the resulting HashTables can have
different insertion orders. This poses an issue when there are hash
key collisions and thus different chaining.
- Use sorted order.
- specifying gradientExpr without a valueExpr, a missing fractionExpr
should be treated as 0 (gradient only), not as 1 (value only)
ENH: improve sanity checks + evaluation short-cuts in exprMixedFvPatchField
- slipped in with changes to csvTableReader (commit 59ed3ba18d) so
only affects the 2006 version.
- adjust constructor to expect "componentColumns", but also accept
"valueColumns" as 1912 and earlier-compatibility. This not only
fixes the reported bug, but also ensure proper compatibility with
older files.
ENH: use "refColumn" instead of "timeColumn" for csvTableReader
- consistent with the CSV Function1.
Support 'timeColumn' as 1912 and earlier-compatibility.
TUT: remove unused table-reader entry
- experienced while reusing src/Pstream/Allwmake-mpi to create
additional mpi-layers after installation. Since the copied sources
are not located within the OpenFOAM source-tree (and/or the
source-tree is non-writable), it should not and does not use the
central build/WM_OPTIONS directory.
However, when exploring for the appropriate local Make directory, it
searched for the current '.' directory instead of checking for the
resolved directory.
This fails, since there is no src/Pstream/Make directory.
Must check for src/Pstream/mpi/Make directory first!
- Adjust wclean to always remove a local build directory
(Make/WM_OPTIONS) for additional safety.
After which, attempt to remove central build/WM_OPTIONS version too.
- the various information queries MUST be executed with
the '--no-print-directory' or risk polluting values
in the information queries.
This is mostly seen with the 'canCompile' test for tutorials running
in parallel.
- When OpenFOAM is under git control and a 'debian/' directory exists,
this could mean two things:
1) Additional debian control has been added to OpenFOAM
2) OpenFOAM has been imported into a debian project
For the case that OpenFOAM has been imported into a debian project,
using the git information would be highly misleading. There will be no
OpenFOAM SHA1 correspondence.
However, if additional debian control has been added to OpenFOAM the
SHA1 will be valid.
The ad hoc solution is to use an additional "openfoam.debian"
directory to flag the addition of debian controls into openfoam.
When a "debian/" directory exists without a "openfoam.debian", assume
that the OpenFOAM has been imported into debian and do not use the SHA1.
