Commit Graph

10 Commits

Author SHA1 Message Date
bf042b39a7 Merge branch 'master' of github.com-OpenFOAM:OpenFOAM/OpenFOAM-dev 2021-12-08 13:39:12 +00:00
7dfb7146ea tutorials::blockMeshDict: Removed redundant mergePatchPairs and edges entries 2021-12-08 13:02:40 +00:00
053eed714d functionObjects: layerAverage: Replacment for postChannel
This function generates plots of fields averaged over the layers in the
mesh. It is a generalised replacement for the postChannel utility, which
has been removed. An example of this function's usage is as follows:

    layerAverage1
    {
        type            layerAverage;
        libs            ("libfieldFunctionObjects.so");

        writeControl    writeTime;

        setFormat       raw;

        // Patches and/or zones from which layers extrude
        patches         (bottom);
        zones           (quarterPlane threeQuartersPlane);

        // Spatial component against which to plot
        component       y;

        // Is the geometry symmetric around the centre layer?
        symmetric       true;

        // Fields to average and plot
        fields          (pMean pPrime2Mean UMean UPrime2Mean k);
    }
2021-12-08 12:48:54 +00:00
1a6b662b41 surfaceInterpolate: Made consistent with other function objects
The surfaceInterpolate function object is now a field expression. This
means it works in the same way as mag, grad, etc... It also now has a
packaged configuration and has been included into the postProcessing
test case.

It can be used in the following ways. On the command line:

   postProcess -func "surfaceInterpolate(rho, result=rhof)"

   rhoPimpleFoam -postProcess -func "surfaceInterpolate(thermo:rho, result=rhof)"

In the controlDict:

   functions
   {
       #includeFunc surfaceInterpolate(rho, result=rhof)
   }

By running:

   foamGet surfaceInterpolate

Then editing the resulting system/surfaceInterpolate file and then
running postProcess or adding an #includeFunc entry without arguments.
2021-10-08 09:10:27 +01:00
9765f87202 test/postProcessing/channel: Updated for changes in topoSet syntax 2021-08-12 10:58:51 +01:00
97e5fc3781 test: Renamed thermophysicalProperties files to physicalProperties 2021-08-12 10:53:52 +01:00
0a3a6312e5 test/postProcessing/channel/system/controlDict: Updated turbulenceFields functionObject call
muEff -> nuEff
2021-08-09 21:41:02 +01:00
15a27fee87 topoSet: the sourceInfo sub-dictionary of the topoSetDict actions is now optional
and only needed if there is a name clash between entries in the source
specification and the set specification, e.g. "name":

    {
        name    rotorCells;
        type    cellSet;
        action  new;
        source  zoneToCell;
        sourceInfo
        {
            name    cylinder;
        }
    }
2021-07-27 14:07:37 +01:00
e9733e50ba functionObjects: Renamed streamLine and streamLines to streamlines 2021-07-14 10:35:02 +01: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