- removed reliance on ParaView_INCLUDE_DIR variable for conveying the
major.minor version information when compiling. This can be somewhat
fragile and also adds variable that is an unnecessary when running
(only used when compiling).
Instead use `have_pvplugin_support` function in paraviewFunctions
wmake script to determine the maj.min from the PV_PLUGIN_PATH
since we have already defined the output path there with paraview
maj.min numbering.
Can now build with paraview from the operating system,
provided that it has develop headers available.
ParaView_VERSION=system
In the etc/config.sh/paraview setup, the maj.min is taken from
the corresponding `paraview --version` output and used when
defining the PV_PLUGIN_PATH.
During the build, the include path taken from `paraview-config`
for a system installation, from the guess installation root
of the paraview binary, or ParaView_DIR otherwise.
NB: using a system ParaView for building runTimePostProcessing is unsupported.
- these types of builds appear to have various library resolution issues
(eg, libexpat not being loaded). Additionally, the build logic does
not yet cover this type of use case.
Previously the coordinate system functionality was split between
coordinateSystem and coordinateRotation. The coordinateRotation stored
the rotation tensor and handled all tensor transformations.
The functionality has now been revised and consolidated into the
coordinateSystem classes. The sole purpose of coordinateRotation
is now just to provide a selectable mechanism of how to define the
rotation tensor (eg, axis-angle, euler angles, local axes) for user
input, but after providing the appropriate rotation tensor it has
no further influence on the transformations.
--
The coordinateSystem class now contains an origin and a base rotation
tensor directly and various transformation methods.
- The origin represents the "shift" for a local coordinate system.
- The base rotation tensor represents the "tilt" or orientation
of the local coordinate system in general (eg, for mapping
positions), but may require position-dependent tensors when
transforming vectors and tensors.
For some coordinate systems (currently the cylindrical coordinate system),
the rotation tensor required for rotating a vector or tensor is
position-dependent.
The new coordinateSystem and its derivates (cartesian, cylindrical,
indirect) now provide a uniform() method to define if the rotation
tensor is position dependent/independent.
The coordinateSystem transform and invTransform methods are now
available in two-parameter forms for obtaining position-dependent
rotation tensors. Eg,
... = cs.transform(globalPt, someVector);
In some cases it can be useful to use query uniform() to avoid
storage of redundant values.
if (cs.uniform())
{
vector xx = cs.transform(someVector);
}
else
{
List<vector> xx = cs.transform(manyPoints, someVector);
}
Support transform/invTransform for common data types:
(scalar, vector, sphericalTensor, symmTensor, tensor).
====================
Breaking Changes
====================
- These changes to coordinate systems and rotations may represent
a breaking change for existing user coding.
- Relocating the rotation tensor into coordinateSystem itself means
that the coordinate system 'R()' method now returns the rotation
directly instead of the coordinateRotation. The method name 'R()'
was chosen for consistency with other low-level entities (eg,
quaternion).
The following changes will be needed in coding:
Old: tensor rot = cs.R().R();
New: tensor rot = cs.R();
Old: cs.R().transform(...);
New: cs.transform(...);
Accessing the runTime selectable coordinateRotation
has moved to the rotation() method:
Old: Info<< "Rotation input: " << cs.R() << nl;
New: Info<< "Rotation input: " << cs.rotation() << nl;
- Naming consistency changes may also cause code to break.
Old: transformVector()
New: transformPrincipal()
The old method name transformTensor() now simply becomes transform().
====================
New methods
====================
For operations requiring caching of the coordinate rotations, the
'R()' method can be used with multiple input points:
tensorField rots(cs.R(somePoints));
and later
Foam::transformList(rots, someVectors);
The rotation() method can also be used to change the rotation tensor
via a new coordinateRotation definition (issue #879).
The new methods transformPoint/invTransformPoint provide
transformations with an origin offset using Cartesian for both local
and global points. These can be used to determine the local position
based on the origin/rotation without interpreting it as a r-theta-z
value, for example.
================
Input format
================
- Streamline dictionary input requirements
* The default type is cartesian.
* The default rotation type is the commonly used axes rotation
specification (with e1/e2/3), which is assumed if the 'rotation'
sub-dictionary does not exist.
Example,
Compact specification:
coordinateSystem
{
origin (0 0 0);
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
Full specification (also accepts the longer 'coordinateRotation'
sub-dictionary name):
coordinateSystem
{
type cartesian;
origin (0 0 0);
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
}
This simplifies the input for many cases.
- Additional rotation specification 'none' (an identity rotation):
coordinateSystem
{
origin (0 0 0);
rotation { type none; }
}
- Additional rotation specification 'axisAngle', which is similar
to the -rotate-angle option for transforming points (issue #660).
For some cases this can be more intuitive.
For example,
rotation
{
type axisAngle;
axis (0 1 0);
angle 30;
}
vs.
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
- shorter names (or older longer names) for the coordinate rotation
specification.
euler EulerRotation
starcd STARCDRotation
axes axesRotation
================
Coding Style
================
- use Foam::coordSystem namespace for categories of coordinate systems
(cartesian, cylindrical, indirect). This reduces potential name
clashes and makes a clearer declaration. Eg,
coordSystem::cartesian csys_;
The older names (eg, cartesianCS, etc) remain available via typedefs.
- added coordinateRotations namespace for better organization and
reduce potential name clashes.
- avoids compiler ambiguity when virtual methods such as
IOdictionary::read() exist.
- the method was introduced in 1806, and was thus not yet widely used
- ignore implicit-fallthrough for ragel generated code.
- add -Wno-deprecated-declarations for c++LESSWARN.
These principally associated with older CGAL versions and their use
of particular mpfr routines.
- improvement documentation for surface sampling.
- can now specify alternative sampling scheme for obtaining the
face values instead of just using the "cell" value. For example,
sampleScheme cellPoint;
This can be useful for cases when the surface is close to a boundary
cell and there are large gradients in the sampled field.
- distanceSurface now handles non-closed surfaces more robustly.
Unknown regions (not inside or outside) are marked internally and
excluded from consideration. This allows use of 'signed' surfaces
where not previously possible.
- since PackedBoolList is now a compatibility typedef for bitSet,
it is useful to have an additional means of distinction.
STYLE: simplify internal version tests and compiler defines.
- the API version is now conveyed via the OPENFOAM define directly.
The older OPENFOAM_PLUS define is provided for existing code.
- However, the new ragel-based parser is much faster
than the others, and does not cause 'too many open files' error
that the flex-based parser does (issue #784).
The timings (using src/sampling as being somewhat representative)
$ wclean; wmakeLnInclude -u .; time wmake -s dep
3.4s wmkdepend (ragel) [now default]
5.7s wmkdep (flex)
6.1s cpp -M
- The makeDepend script is for testing purposes only, but could used as
a hook for other dependency generation systems (eg, ninja).
It simply wraps 'cpp -M' in a form that is calling compatible with
wmkdepend.
BUG: wmkdepend parser was missing optional leading space on #include match
STYLE: use -G2 (goto-based) option for wmkdepend state machine
- the machine is compact with few states and lends itself to this
This is similar to efforts (Feb 2010) but using ragel
(https://en.wikipedia.org/wiki/Ragel) instead of the now defunct
coco/r. The modified commit message from 2010:
ENH: add C++-based wmkdepend parser (uses ragel grammar).
- This avoids dependency on lex/flex and provides better encapsulation
for buffer switching. As a result, the maximum number of open files
only corresponds to the include depth.
--
Note that the flex source and rules are still available, but are not
deactivate (see wmake/rules/General/transform)
- primary points for an external user are the polyMesh constructor
- add config info for gcc-7.3.0
COMP: intel-2017. Ignore unknown pragmas. Disambiguate method resolution.
- use "-pvMAJ.MIN" suffix for similarity with the paraview convention
- use sentinel file to ensure clean change of intermediate targets
- ensure all library files are being properly removed
- support gperftools-none, gperftools-system configurations
as per other third-party packages.
STYLE: clean up more environment variables
CONFIG: testing adios rule
- these directories are sometimes used for a central, non-thirdparty, non-system
installation
- leave gmp and mpfr as is, since it is not clear how these would interact with system
versions
On 64-bit systems, the system installations of boost, cgal are under
lib64/. The behaviour for a ThirdParty build is mostly lib/ but this
can also be changing.
Boost 1_62_0 and older build into 'lib/'.
CGAL-4.9 builds into 'lib64/', older versions into 'lib/'.
Future-proof things by using lib$WM_COMPILER_LIB_ARCH for boost and
cgal build rules, and forcing these as build targets in the ThirdParty
makeCGAL as well.
--
STYLE: check for boost/version.hpp, CGAL/version.h instead their directories
- CGAL itself includes its library dependencies, we only need to
provide the -L... option to the proper ThirdParty locations.
Should help improve general build robustness.
The pre-processor macro 'OPENFOAM_PLUS' is defined with a numerical
value equal to the currently compatible version number.
This can be used judiciously within user coding to help with minor
differences between OpenFOAM versions. For example,
#ifdef OPENFOAM_PLUS
#if (OPENFOAM_PLUS >= 1612)
...
#endif
#endif
or simply
#if (OPENFOAM_PLUS >= 1612)
...
#endif
which may be optionally overridden by version-specific rules.
For example the default rules for gcc on GNU/Linux x86_64 are in the
wmake/rules/linux64Gcc directory. If there is a need to change any of
the rules for a specific version of gcc, e.g. gcc-4.8.4 the directory
wmake/rules/linux64Gcc48 may be created into which any of the language
files may be provided containing the rules to override the defaults.
On 32bit OSs long is not unambiguously int32_t (or int64_t) causing
problems for IO operator resolution. This problem is avoided by
explicitly defining the following operators:
