This wall function is now stable even if the near-wall cell centre distance is
less than the roughness height although it is unlikely to be very accurate if
used in this way.
The sudden change limit stabilisation has been re-implemented to avoid the
near-wall viscosity being lower limited to half the laminar viscosity which has
no physical meaning.
and copy assignment operator for classes with a copy constructor
This is often described as the rule of 3 (or rule of 5 in C++11 if move
constructors and assignment operators are also defined) and makes good sense in
ensuring consistency. For classes in which the default bitwise copy constructor
or assignment operator are appropriate these are now specified explicitly using
the "= default" keyword if the other is explicitly defined fulfilling the rule
of 3 without the need to define the body of the function.
Perpendicular vectors should be generated using the global
"perpendicular" function, which guarantees a non-zero result without a
random number generator and without looping.
All wall functions now operate collaboratively, obtaining the Cmu, kappa and E
coefficients and yPlusLam from the nutWallFunction base class. Now these
optional inputs need only be specified in the nut boundary condition with the k,
epsilon, omega, v2 and f wall functions obtaining these values from there. This
is much simpler to specify and avoids inconsistencies in the operation of the
wall functions for the different turbulence fields.
The code has also been rationalised and simplified avoiding unnecessary code
and duplication.
Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
Replaced all uses of complex Xfer class with C++11 "move" constructors and
assignment operators. Removed the now redundant Xfer class.
This substantial changes improves consistency between OpenFOAM and the C++11 STL
containers and algorithms, reduces memory allocation and copy overhead when
returning containers from functions and simplifies maintenance of the core
libraries significantly.
Using the new field mapper framework it is now possible to create specialised
mappers rather than creating a fatter and fatter interface in the base mapper.
This approach is far more extensible, comprehensible and maintainable.
The volumeFractionSource represents the effect of a reduction in the
volume of the domain due to the presence of a stationary phase, most
likely a solid porous media. It only represents the dynamic effects
associated with the reduction in volume; it does not does not model
loss, drag or heat transfer. Separate models (e.g., the existing
porosity models) will be necessary to represent these effects. An
example usage, in system/fvOptions, is as follows:
volumeFraction
{
type volumeFractionSource;
phase solid;
phi phi;
rho rho;
U U;
fields (rho U e);
}
The volume fraction will be read from constant/alpha.<phase>, and must
be generated in advance using setFields or a function object. Note that
the names of the flux, density (if compressible) and velocity must all
be specified. Every field for which a transport equation is solved
should also be specified in the "fields" entry.
The solidEquilibriumEnergySource adds the thermal inertia and diffusive
characteristics of a stationary solid phase to the energy equation of
the fluid, assuming that the two phases are in thermal equilibrium. An
example usage is as follows:
solidEqulibriumEnergy
{
type solidEqulibriumEnergySource;
phase solid;
field e;
}
This will read the volume fraction in the same way as the
volumeFractionSource option. In addition, thermal properties of the
solid will be constructed from settings in
system/thermophysicalProperties.<phase>.
Two tutorials have been added, demonstrating use of these options in
both incompressible and compressible simulations. These are
incompressible/pimpleFoam/laminar/blockedChannel and
compressible/rhoPimpleFoam/laminar/blockedChannel.
Flux fields (surfaceScalarFields) are flipped as before but this process is no
longer applied to surfaceVectorFields (Uf etc.) for which it is not appropriate.
decomposePar is now consistent with reconstructPar with respect to
surfaceVectorFields.
Patch contributed by Mattijs Janssens.
This clarifies the purpose which is to indicate that the object should be read
or written on this particular processor rather than it is or is not valid.
Setting the moving flag as a result of a reconstruction of the mesh at a
new time was causing lagrangian reconstruction to fail, as the necessary
moving mesh data had not been cached.