The freestreamFvPatchField previously employed a fixed value when supplying
the inlet values. This commit extends the BC so that users can use another
patch to supply the values via the new freestreamBC entry, e.g. to set the
velocity to an atmospheric boundary layer profile:
inlet
{
type freestream;
freestreamBC
{
type atmBoundaryLayerInletVelocity;
flowDir (1 0 0);
zDir (0 0 1);
Uref 20;
Zref 20;
z0 uniform 0.1;
zGround uniform 935;
}
}
The earlier specification is also maintained for backwards compatibility, e.g.
inlet
{
type freestream;
freestreamValue uniform (300 0 0);
}
- 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)
- Uses the user-specified value for outputTemperature:
{
type externalCoupledTemperature;
outputTemperture fluid; // or wall;
}
Otherwises uses 'wall' as a default (for compatibility) and emits a
warning.
The T.out header now reflects the type of output. Eg,
# Values: area Tfluid qDot htc
- tutorials based on squareBend used Default_Boundary_Region explicitly
defined since they predated the defaultPatch renaming (2008).
The name 'Default_Boundary_Region' was for convenience as the default
name when converting to PROSTAR or CCM formation, but can now be
changed to something more generic.
- define wall boundary conditions for squareBend using a general regex
to allow future splitting of wall types by name.
- check if the first argument corresponds to an OpenFOAM value for
'true' (as per Switch).
True == 't', 'y', 'true', 'yes', 'on'. Everything else is not true.
- when the first argument is '-dict', it initializes the value
with a query via foamDictionary.
Eg,
isTrue -dict mydict -entry parallel
==> value=$(foamDictionary mydict -entry parallel -value)
isTrue $value
a missing entry is silently treated as false.
ENH: add getNumberOfPatchFaces function in RunFunctions
- simple extraction of nFaces from boundary file for given patch/region
- append the commit hash value with the commit date when creating
the build string information and drop the version prefix.
This provides an immediate overview of when the code was last
changed. The prefixed version information can be dropped from
the build string, since it is readily available in other forms.
- 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.
- cfindObject() for const pointer access.
- getObject() for mutable non-const pointer access, similar to the
objectRegistry::getObjectPtr()
- cfindObject(), findObject(), getObject() with template type access
to also check the headerClassName.
For example,
cfindObject("U") -> good
cfindObject<volVectorField>("U") -> good
cfindObject<volScalarField>("U") -> nullptr
This allows inversion of looping logic.
1) Obtain the names for a particular Type
for (const word& objName : objs.sortedNames<Type>())
{
const IOobject* io = objs[objName];
...
}
2) Use previously obtained names and apply to a particular Type
for (const word& objName : someListOfNames)
{
const IOobject* io = objs.cfindObject<Type>(objName);
if (io)
{
...
}
}
- if FOAM_EXT_LIBBIN is unset and some scripts set this to /usr/lib*
as a fallback (eg, to avoid an undefined value) this will cause a
system library to be found before appropriate *_ARCH_PATH entry.
This was noticed during a scotch compilation without third-party:
resulting in the system library (/usr/lib64/libscotch.so) to be found
instead of the SCOTCH_ARCH_PATH location
(/usr/lib64/mpi/gcc/openmpi/lib64/).
Simply changing the search order doesn't work for use, since we wish
to retain a preference for any dynamic libraries discovered in a
real FOAM_EXT_LIBBIN.
Circumvent these issues by only taking libraries from
FOAM_EXT_LIBBIN if it also points to a location within ThirdParty.
- can now things like ref(), boundaryFieldRef(), primitiveFieldRef()
with an optional argument that avoids triggering any update events
Instead of
Field<Type>& iF = const_cast<Field<Type>&>(fld.primitiveField());
can now write
Field<Type>& iF = fld.primitiveFieldRef(false);
or simply
auto& iF = fld.primitiveFieldRef(false);
- can be used, for example, to visualize all wall cells - for quality
or other purposes - without requiring an intermediate faceSet for
the selection. Request arising from pending merge !213.
- now supports a parcel selection mechanism like vtkCloud,
giving the ability to select a subset of parcels.
For example, a given stride, or removal of parcels with a small
diameter.
Eg,
dataCloud output Time: 3.2
Applying parcel filtering to 994 parcels
- add stride 4
- subtract field U : (less 0.2)
After filtering using 214/994 parcels
- add output precision control for dataCloud