- provide default WM_DIR if not already set, to improve robustness if a
reduced environment is used
- add etc/ to WM_PROJECT_SITE search. This makes the site directory
structure consistent with the OpenFOAM structure.
Eg,
WM_PROJECT_SITE/etc/..
WM_PROJECT_SITE/bin/..
WM_PROJECT_SITE/platforms/..
- Don't set/export WM_OSTYPE. The default is POSIX and is properly
defaulted throughout, including in CMakeLists-OpenFOAM.txt (also for
Catalyst)
- was PREFIX/site, now PROJECT/site
This avoids several issues when installing OpenFOAM in clusters
without an intermediate OpenFOAM-specific installation prefix.
The 'site' directory may have a reserved meaning in these situations
and it is undesirable to 'leak' upwards into the parent directory to
look for configuration files.
Placing the default within the project directory avoids this.
Alternative locations can be given via the WM_PROJECT_SITE variable.
- 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.
Description
Calculates the energy spectrum for a structured IJK mesh
Usage
Example of function object specification:
energySpectrum1
{
type energySpectrum;
libs ("libfieldFunctionObjects.so");
}
Where the entries comprise:
\table
Property | Description | Required | Default value
type | type name: energySpectrum | yes |
log | write info to standard output | no | yes
\endtable
Output data is written to the file \<timeDir\>/energySpectrum.dat
- generalize output text wrapping, use for usage notes
- add -help-man option for generating manpage content for any OpenFOAM
application or solver.
bin/tools/foamCreateManpage as helper
- this helps for many cases outlined in issue #1007, but can also be
useful when simply using symlinks for shorter or reorganized
directory structures.
- with the 'cwd' optimization switch it is possible to select the
preferred behaviour for the cwd() function.
A value of 0 causes cwd() to return the physical directory,
which is what getcwd() and `pwd -P` return.
Until now, this was always the standard behaviour.
With a value of 1, cwd() instead returns the logical directory,
which what $PWD contains and `pwd -L` returns.
If any of the sanity checks fail (eg, PWD points to something other
than ".", etc), a warning is emitted and the physical cwd() is
returned instead.
Apart from the optical difference in the output, this additional
control helps workaround file systems with whitespace or other
characters in the directory that normally cause OpenFOAM to balk.
Using a cleaner symlink elsewhere should skirt this issue.
Eg,
cd $HOME
ln -s "/mounted volume/user/workdir" workdir
cd workdir
# start working with OpenFOAM
- foamCleanPath now only splits the environment variable on ':', which
allows other directories with spaces or '(..)' etc to pass through
without major issue.
- The filter arguments are split on whitespace, colons or semi-colons.
- use the dictionary 'get' methods instead of readScalar for
additional checking
Unchecked: readScalar(dict.lookup("key"));
Checked: dict.get<scalar>("key");
- In templated classes that also inherit from a dictionary, an additional
'template' keyword will be required. Eg,
this->coeffsDict().template get<scalar>("key");
For this common use case, the predefined getXXX shortcuts may be
useful. Eg,
this->coeffsDict().getScalar("key");
- this also removes the '-newTimes' option cruft from appearing
everywhere. reconstructPar and redistributePar are unaffected by this
since they define their own -newTimes option independently.
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.
- instead of dict.lookup(name) >> val;
can use dict.readEntry(name, val);
for checking of input token sizes.
This helps catch certain types of input errors:
{
key1 ; // <- Missing value
key2 1234 // <- Missing ';' terminator
key3 val;
}
STYLE: readIfPresent() instead of 'if found ...' in a few more places.
Previously had 3 possibilities for handling exposed internal faces
1. use default "oldInternalFaces"
2. specify -patch, to use the specified (existing) patch
3. specify -patches, to use the geometrically closest patches
Now relaxed the restriction on -patch to allow specification of a new
(not yet existing) patch name. This improves flexibility, but won't
catch typing mistakes.
Harmonize behaviour of -patches and -patch. When -patches is used to
specify a single, non-regex patch name, it now behaves identically to
-patch. Since the getList handling for options already allows special
treatment for single parameter lists, the following will work
identically:
subsetMesh -patch patch0
subsetMesh -patches patch0
subsetMesh -patches '( patch0 )'
In the future it might be reasonable to fully combine the behaviour of
'-patch' and '-patches' and treat them as aliases for each other.
ENH: support subsetMesh on a cellZone.
- when the '-zone' option is specified, the command argument is treated
as the name (or names) of cellZones to be selected instead of as the
name of the cellSet.
The command argument can be a single word, regex, or list of
word/regex.
Eg,
subsetMesh -zone -patch mypatch mixer
subsetMesh -zone -patch mypatch '(mixer "moving.*" )'
STYLE: simplify set handling and other code cleanup in subsetMesh
- The test condition
[ -n "$cur" -a ... ]
fails if $cur starts with '-le', which bash interprets as a further
test op. Splitting the test condition solves the problem:
[ -n "$cur" ] && [ ... ]
- With argList::noFunctionObjects() we use the logic added in
4b93333292 (issue #352)
By removing the '-noFunctionObjects' option, we automatically
suppress the creation of function-objects via Time (with argList
as a parameter).
There is generally no need in these cases for an additional
runTime.functionObjects().off() statement
Use the argList::noFunctionObjects() for more direct configuration
and reduce unnecessary clutter in the -help information.
In previous versions, the -noFunctionObjects would have been redundant
anyhow, so we can also just ignore it now instead.
General:
* -roots, -hostRoots, -fileHandler
Specific:
* -to <coordinateSystem> -from <coordinateSystem>
- Display -help-compat when compatibility or ignored options are available
STYLE: capitalization of options text
- since 1612, FOAM_INST_DIR and foamInstDir longer have any
special meanings when sourcing the bashrc or cshrc files.
Thus no need for special treatment in any of the dispatch wrappers.
Retained FOAM_INST_DIR as (unexported) variable in etc/bashrc,
just in case people are using patched versions of etc/bashrc
as part of their installation.
ENH: relax prefix restrictions on foamCreateVideo (issue #904)
- shift the implicit '.' to be part of the default prefix. This allows
things like "-image myimages_00" to work as might be expected.
- corrected the mass based correction and updated the misleading function
arguments
- moved the option to the optimisation switches, e.g.:
OptimisationSwitches
{
experimentalDdtCorr 1;
}
- default remains off/no (0)
- this avoids a situation when an aborted sourcing of the etc/bashrc
file can leave WM_SHELL_FUNCTIONS defined, which causes all
subsequent sourcing to fail.
- can be used to test the behaviour of the decomposion and its
characteristics without writing any decomposition to disk.
Combine with -cellDist to visualize the expected decomposition
result.
- FOAM_CONFIG_NOUSER
Suppress use of user/group configuration files.
This is useful when packaging for a central installation.
- allow additional user tuning of compiler settings.
Per-compiler overrides in "compiler-$WM_COMPILER" files
- relocate some standard functionality to TimePaths to allow a lighter
means of managing time directories without using the entire Time
mechanism.
- optional enableLibs for Time construction (default is on)
and a corresponding argList::noLibs() and "-no-libs" option
STYLE:
- mark Time::outputTime() as deprecated MAY-2016
- use pre-increment for runTime, although there is no difference in
behaviour or performance.
