Commit Graph

7 Commits

Author SHA1 Message Date
2bb760e912 etc/caseDicts/postProcessing/control/stopAtTimeStep: Configuration file for functionObjects::stopAtTimeStep
Example:

functions
{
    #includeFunc stopAtTimeStep(minDeltaT=1e-8)
    .
    .
    .
}
2023-04-13 13:28:27 +01:00
7c684b925d functionObjects: New adjustTimeStepToChemistry and adjustTimeStepToCombustion functions
These functions adjusts the time step to match a reaction process. The
adjustTimeStepToChemistry fucntion adjusts based on the chemistry
model's stored chemical time step, and adjustTimeStepToCombustion
adjusts to match bulk reaction time scales. The latter requires
specification of a Courant-like number, to control approximately how
much of the reaction is permitted to be completed in a single
time-step.

These functions allow the solver to temporally resolve chemical changes,
in order to better couple the reactions with the transport, or in order
improve the time-accuracy of post-processing.

Example usage by dictionary specification:

    adjustTimeStepToChemistry1
    {
        type            adjustTimeStepToChemistry;
        libs            ("libchemistryModel.so");
    }

    adjustTimeStepToCombustion1
    {
        type            adjustTimeStepToCombustion;
        libs            ("libchemistryModel.so");
        maxCo           0.1;
    }

Example usage via the included packaged function:

    #includeFunc adjustTimeStepToChemistry

    #includeFunc adjustTimeStepToCombustion(maxCo=0.1)
2023-01-31 15:06:45 +00:00
5d0d9a4fa3 postProcess: Improve usability of packaged function objects
Packaged function objects can now be deployed equally effectively by
(a) using a locally edited copy of the configuration file, or by
(b) passing parameters as arguments to the global configuration file.

For example, to post-process the pressure field "p" at a single location
"(1 2 3)", the user could first copy the "probes" packaged function
object file to their system directory by calling "foamGet probes". They
could then edit the file to contain the following entries:

    points ((1 2 3));
    field  p;

The function object can then be executed by the postProcess application:

    postProcess -func probes

Or it can be called at run-time, by including from within the functions
section of the system/controlDict file:

    #includeFunc probes

Alternatively, the field and points parameters could be passed as
arguments either to the postProcess application by calling:

    postProcess -func "probes(points=((1 2 3)), p)"

Or by using the #includeFunc directive:

    #includeFunc probes(points=((1 2 3)), p)

In both cases, mandatory parameters that must be either edited or
provided as arguments are denoted in the configuration files with
angle-brackets, e.g.:

    points  (<points>);

Many of the packaged function objects have been split up to make them
more specific to a particular use-case. For example, the "surfaces"
function has been split up into separate functions for each surface
type; "cutPlaneSurface", "isoSurface", and "patchSurface". This
splitting means that the packaged functions now only contain one set of
relevant parameters so, unlike previously, they now work effectively
with their parameters passed as arguments. To ensure correct usage, all
case-dependent parameters are considered mandatory.

For example, the "streamlines" packaged function object has been split
into specific versions; "streamlinesSphere", "streamlinesLine",
"streamlinesPatch" and "streamlinesPoints". The name ending denotes the
seeding method. So, the following command creates ten streamlines with
starting points randomly seeded within a sphere with a specified centre
and radius:

    postProcess -func "streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)"

The equivalent #includeFunc approach would be:

    #includeFunc streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)

When passing parameters as arguments, error messages report accurately
which mandatory parameters are missing and provide instructions to
correct the format of the input. For example, if "postProcess -func
graphUniform" is called, then the code prints the following error message:

    --> FOAM FATAL IO ERROR:

    Essential value for keyword 'start' not set
    Essential value for keyword 'end' not set
    Essential value for keyword 'nPoints' not set
    Essential value for keyword 'fields' not set

    In function entry:
        graphUniform

    In command:
        postProcess -func graphUniform

    The function entry should be:
        graphUniform(start = <point>, end = <point>, nPoints = <number>, fields = (<fieldNames>))

    file: controlDict/functions/graphUniform from line 15 to line 25.

As always, a full list of all packaged function objects can be obtained
by running "postProcess -list", and a description of each function can
be obtained by calling "foamInfo <functionName>". An example case has
been added at "test/postProcessing/channel" which executes almost all
packaged function objects using both postProcess and #includeFunc. This
serves both as an example of syntax and as a unit test for maintenance.
2021-07-14 10:32:49 +01:00
8c44964f60 timeStep function object: added description and categorised consistently 2021-07-07 12:02:24 +01:00
5bfd3b2488 functionObjects::stopAtClockTime: New functionObject to stop the run when the specified clock time is exceeded
Description
    Stops the run when the specified clock time in second has been reached
    and optionally write results before stopping.

    The following actions are supported:
    - noWriteNow
    - writeNow
    - nextWrite (default)

    Examples of function object specification:
    \verbatim
    stop
    {
        type        stopAtClockTime;
        libs        ("libutilityFunctionObjects.so");
        stopTime    10;
        action      writeNow;
    }
    \endverbatim
    will stop the run at the next write after the file "stop" is created in the
    case directory.

Usage
    \table
        Property | Description              | Required | Default value
        type     | type name: stopAtClockTime | yes    |
        stopTime | Maximum elapsed time [s] | yes      |
        action   | Action executed          | no       | nextWrite
    \endtable
2020-07-17 11:13:46 +01:00
af8488a191 etc/caseDicts/postProcessing: Moved files to more logical locations 2020-07-16 17:47:25 +01:00
7379f4525f functionObjects::stopAt: New abstract base class for run stop conditions
By default the case stops following the next write but stopping immediately with
or without writing are also options.

The stopAtFile functionObject derived from stopAt stops the run when a file
predefined file is created in the case directory:

Description
    Stops the run when the specified file is created in the case directory.

    The default name of the trigger file is \c $FOAM_CASE/<name> where \c
    <name> is the name of the functionObject entry and the default action is \c
    nextWrite.

    Currently the following action types are supported:
    - noWriteNow
    - writeNow
    - nextWrite

    Examples of function object specification:
    \verbatim
    stop
    {
        type stopAtFile;
        libs ("libutilityFunctionObjects.so");
    }
    \endverbatim
    will stop the run at the next write after the file "stop" is created in the
    case directory.

    \verbatim
    stop
    {
        type stopAtFile;
        libs ("libutilityFunctionObjects.so");
        file "$FOAM_CASE/stop";
        action writeNow;
    }
    \endverbatim
    will write the fields and stop the run when the file "stop" is created in
    the case directory.

Usage
    \table
        Property | Description            | Required | Default value
        type     | type name: stopAtFile  | yes      |
        file     | Trigger file path name | no       | $FOAM_CASE/<name>
        action   | Action executed        | no       | nextWrite
    \endtable
2020-07-16 17:44:51 +01:00