A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
OpenFOAM Configuration
The main OpenFOAM settings are located in the parent etc/ directory. The bash and csh shells are supported and to configure OpenFOAM source etc/bashrc or etc/cshrc respectively which source the following files in the config.sh or config.csh respectively:
settings: core settingsaliases: aliases for interactive shellsunset: sourced to clear as many OpenFOAM environment settings as possiblempi: MPI communications library settingsensight: application settings for EnSightparaview: application settings for ParaViewscotch: application settings for compiling against scotchmetis: application settings for compiling against metis 5
The config.*/example directories contains various example configuration files for the corresponding shell:
compiler: an example of fine tuning ThirdParty compiler settingsopenmpi: an example of fine tuning openmpi settings for OpenFOAMparaview: an example of chaining to the standard config/paraview with a different ParaView_VERSIONprefs: an example of supplying alternative site-defined settings