This can be used identically to a standard Function1. In addition, it
also permits specification of the dimensions. This allows the dimensions
to be checked. It also permits unit conversions. For example:
<name>
{
type table;
// Dimensions
xDimensions [CAD]; // Optional. Argument dimensions/units.
// Here, this specifies coordinates are in
// crank angle degrees (available if using
// engine time).
dimensions [mm]; // Optional. Value dimensions/units.
// Here, values are in mm.
// Tablulated data
values
(
(0 0)
(60 12) // <-- i.e., 12 mm at 60 degrees
(180 20)
(240 8)
(360 0)
);
outOfBounds repeat;
}
This replaces TimeFunction1, as it allows per-function control over
whether the function is considered to be one of real-time or user-time.
All thermophysicalFunctions, NSRDS, API and the fast uniform and non-uniform
tables have now been converted into the corresponding Function1<scalar> and
Function2<scalar> so that they can be used in other contexts, e.g. diffusion
coefficients for multi-component diffusion and in conjunction with other
Function1 and Function2s. This also enables 'coded' Function1 and Function2 to
be used for thermo-physical properties.
Now all run-time selectable functions are within a single general framework
improving usability and simplifying maintenance.
TableBase, TableFile and Table now combined into a single simpler Table class
which handle both the reading of embedded and file data using the generalised
TableReader. The new EmbeddedTableReader handles the embedded data reading
providing the functionality of the original Table class within the same
structure that can read the data from separate files.
The input format defaults to 'embedded' unless the 'file' entry is present and
the Table class is added to the run-time selection table under the name 'table'
and 'tableFile' which provides complete backward comparability. However it is
advisable to migrate cases to use the new 'table' entry and all tutorial cases
have been updated.
A typical Function1 entry can be read in one of three ways; with the
parameters in the current dictionary, in a separate sub-dict, or with
the entry itself as the dictionary; e.g.,
// Current-dictionary form
<entryName> sine;
amplitude 0.1;
frequency 10;
level 0.2;
// Coeff-dictionary form
<entryName> sine;
<entryName>Coeffs
{
amplitude 0.1;
frequency 10;
level 0.2;
}
// Entry-as-dictionary form
<entryName>
{
type sine;
amplitude 0.1;
frequency 10;
level 0.2;
}
The latter two sub-dictionary forms are needed when there are multiple
Function1 entries of the same type in a dictionary. Enclosing the
parameters in a separate sub-dictionary prevents the keywords (in this
case "amplitude", "frequency" and "level") from being duplicated.
Table and constant Function1 entries are different in that they have
special formats which allow the data to be appended directly to the
entry name; e.g;
<entryName> table ((0 (1 0 0)) (1 (2 0 0)));
<entryName> constant (1 0 0);
// (constant can even have the "constant" keyword omitted)
<entryName> (1 0 0);
Table also has two optional additional controls; "outOfBounds" and
"interpolationScheme". In order for these to be written out in such a
way that the entries are not duplicated, table needs to be written out
(and therefore also read in) as one of the sub-dictionary forms. To that
effect, Table has been extended to additionally permit reading in the
three forms described previously, and to write in the coeff-dictionary
form.
// Current-dictionary form
<entryName> table;
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
// Coeff-dictionary form
<entryName> sine;
<entryName>Coeffs
{
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
}
// Entry-as-dictionary form
<entryName>
{
type table;
values ((0 (1 0 0)) (1 (2 0 0)));
outOfBounds repeat;
interpolationScheme linear;
}
For completeness and consistency, constant has also been modified so
that it can read in these forms. However, constant has no additional
control entries, which means writing a coeff-dictionary is unecessary,
so the output has not been changed.
Function1 has been generalised in order to provide functionality
previously provided by some near-duplicate pieces of code.
The interpolationTable and tableReader classes have been removed and
their usage cases replaced by Function1. The interfaces to Function1,
Table and TableFile has been improved for the purpose of using it
internally; i.e., without user input.
Some boundary conditions, fvOptions and function objects which
previously used interpolationTable or other low-level interpolation
classes directly have been changed to use Function1 instead. These
changes may not be backwards compatible. See header documentation for
details.
In addition, the timeVaryingUniformFixedValue boundary condition has
been removed as its functionality is duplicated entirely by
uniformFixedValuePointPatchField.
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.
e.g.
ramp
{
type quadratic;
start 200;
duration 1.6;
}
but the old format is supported for backward compatibility:
ramp linear;
rampCoeffs
{
start 200;
duration 1.6;
}
Function1 is an abstract base-class of run-time selectable unary
functions which may be composed of other Function1's allowing the user
to specify complex functions of a single scalar variable, e.g. time.
The implementations need not be a simple or continuous functions;
interpolated tables and polynomials are also supported. In fact form of
mapping between a single scalar input and a single primitive type output
is supportable.
The primary application of Function1 is in time-varying boundary
conditions, it also used for other functions of time, e.g. injected mass
is spray simulations but is not limited to functions of time.
