- no limit to the number of ways of filing ptscotch libraries.
RedHat/Fedora/CentOS should look for these directories:
ptscotch include=/usr/include/openmpi-x86_64
ptscotch library=/usr/lib64/openmpi/lib
when MPI_ARCH_PATH=/usr/lib64/openmpi
and mpicc --showme:compile yields -I/usr/include/openmpi-x86_64
ENH: limit output to 25 cell types per line for readability
- makes it easier to trace potential format errors etc
STYLE: downgrade warning about polyhedrals to a simple info message
- can assume that polyhedral support is widespread enough to not
warrant a warning.
- had calculated boundaries (default) for the evaluated variables,
which meant they retained their initialized values (usually Zero).
This normally goes unnoticed, since the boundary values are largely
irrelevant in the volField expressions. However, when applying
functions that balk at a zero value - eg, log() - this raises a
floating point exception.
These boundary should be zeroGradient, since the evaluated variables
correspond to the internalField only. Could continue to use
calculated, but then need to set the calculated boundary values from
the patch internal field manually.
- 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.
