Commit Graph

9 Commits

Author SHA1 Message Date
ac0eea9610 polyCellSet: General cell set selection class
Description
    General cell set selection class for models that apply to sub-sets
    of the mesh.

    Currently supports cell selection from a set of points, a specified cellSet
    or cellZone or all of the cells.  The selection method can either be
    specified explicitly using the \c selectionMode entry or inferred from the
    presence of either a \c cellSet, \c cellZone or \c points entry.  The \c
    selectionMode entry is required to select \c all cells.

Usage
    Examples:
    \verbatim
        // Apply everywhere
        selectionMode   all;

        // Apply within a given cellSet
        selectionMode   cellSet; // Optional
        cellSet         rotor;

        // Apply within a given cellZone
        selectionMode   cellZone; // Optional
        cellSet         rotor;

        // Apply in cells containing a list of points
        selectionMode   points; // Optional
        points
        (
            (2.25 0.5 0)
            (2.75 0.5 0)
        );
    \endverbatim

Also used as the base-class for fvCellSet which additionally provides and
maintains the volume of the cell set.
2022-08-13 16:32:19 +01:00
7fdde885fe fvCellSet: The selectionMode entry is now optional
Description
    General cell set selection class for models that apply to sub-sets
    of the mesh.

    Currently supports cell selection from a set of points, a specified cellSet
    or cellZone or all of the cells.  The selection method can either be
    specified explicitly using the \c selectionMode entry or inferred from the
    presence of either a \c cellSet, \c cellZone or \c points entry.  The \c
    selectionMode entry is required to select \c all cells.

Usage
    Examples:
    \verbatim
        // Apply everywhere
        selectionMode   all;

        // Apply within a given cellSet
        selectionMode   cellSet; // Optional
        cellSet         rotor;

        // Apply within a given cellZone
        selectionMode   cellZone; // Optional
        cellSet         rotor;

        // Apply in cells containing a list of points
        selectionMode   points; // Optional
        points
        (
            (2.25 0.5 0)
            (2.75 0.5 0)
        );
    \endverbatim

All tutorials updated and simplified.
2022-08-12 18:44:52 +01:00
2da5edec29 Function1s::omega: New user convenience class to handle the input of time-varying rotational speed
Description
    User convenience class to handle the input of time-varying rotational speed
    in rad/s if \c omega is specified or rpm if \c rpm is specified.

Usage
    For specifying the rotational speed in rpm of an MRF zone:
    \verbatim
        MRF
        {
            cellZone    rotor;

            origin     (0 0 0);
            axis       (0 0 1);

            rpm        60;
        }
    \endverbatim
    or the equivalent specified in rad/s:
    \verbatim
        MRF
        {
            cellZone    rotor;

            origin     (0 0 0);
            axis       (0 0 1);

            rpm        6.28319;
        }
    \endverbatim
    or for a tabulated ramped rotational speed of a solid body:
    \verbatim
        mover
        {
            type            motionSolver;

            libs            ("libfvMeshMovers.so" "libfvMotionSolvers.so");

            motionSolver    solidBody;

            cellZone        innerCylinder;

            solidBodyMotionFunction  rotatingMotion;

            origin      (0 0 0);
            axis        (0 1 0);

            rpm         table
            (
                (0    0)
                (0.01  6000)
                (0.022  6000)
                (0.03  4000)
                (100   4000)
            );
        }
    \endverbatim

The following classes have been updated to use the new Function1s::omega class:
    solidBodyMotionFunctions::rotatingMotion
    MRFZone
    rotatingPressureInletOutletVelocityFvPatchVectorField
    rotatingTotalPressureFvPatchScalarField
    rotatingWallVelocityFvPatchVectorField

and all tutorials using these models and BCs updated to use rpm where appropriate.
2022-08-12 16:52:04 +01:00
160ee637f9 MRF: Further developed to replace SRF
MRF (multiple reference frames) can now be used to simulate SRF (single
reference frame) cases by defining the MRF zone to include all the cells is the
mesh and applying appropriate boundary conditions.  The huge advantage of this
is that MRF can easily be added to any solver by the addition of forcing terms
in the momentum equation and absolute velocity to relative flux conversions in
the formulation of the pressure equation rather than having to reformulate the
momentum and pressure system based on the relative velocity as in traditional
SRF.  Also most of the OpenFOAM solver applications and all the solver modules
already support MRF.

To enable this generalisation of MRF the transformations necessary on the
velocity boundary conditions in the MRF zone can no longer be handled by the
MRFZone class itself but special adapted fvPatchFields are required.  Although
this adds to the case setup it provides much greater flexibility and now complex
inlet/outlet conditions can be applied within the MRF zone, necessary for some
SRF case and which was not possible in the original MRF implementation.  Now for
walls rotating within the MRF zone the new 'MRFnoSlip' velocity boundary
conditions must be applied, e.g. in the
tutorials/modules/incompressibleFluid/mixerVessel2DMRF/constant/MRFProperties
case:

boundaryField
{
    rotor
    {
        type            MRFnoSlip;
    }

    stator
    {
        type            noSlip;
    }

    front
    {
        type            empty;
    }

    back
    {
        type            empty;
    }
}

similarly for SRF cases, e.g. in the
tutorials/modules/incompressibleFluid/mixerSRF case:

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (0 0 -10);
    }

    outlet
    {
        type            pressureInletOutletVelocity;
        value           $internalField;
    }

    rotor
    {
        type            MRFnoSlip;
    }

    outerWall
    {
        type            noSlip;
    }

    cyclic_half0
    {
        type            cyclic;
    }

    cyclic_half1
    {
        type            cyclic;
    }
}

For SRF case all the cells should be selected in the MRFproperties dictionary
which is achieved by simply setting the optional 'selectionMode' entry to all,
e.g.:

SRF
{
    selectionMode   all;

    origin      (0 0 0);
    axis        (0 0 1);

    rpm         1000;
}

In the above the rotational speed is set in RPM rather than rad/s simply by
setting the 'rpm' entry rather than 'omega'.

The tutorials/modules/incompressibleFluid/rotor2DSRF case is more complex and
demonstrates a transient SRF simulation of a rotor requiring the free-stream
velocity to rotate around the apparently stationary rotor which is achieved
using the new 'MRFFreestreamVelocity' velocity boundary condition.  The
equivalent simulation can be achieved by simply rotating the entire mesh and
keeping the free-stream flow stationary and this is demonstrated in the
tutorials/modules/incompressibleFluid/rotor2DRotating case for comparison.

The special SRFSimpleFoam and SRFPimpleFoam solvers are now redundant and have
been replaced by redirection scripts providing details of the case migration
process.
2022-08-11 18:23:15 +01:00
ceac941f4c createNonConformalCouples: Support patchType overrides
Field settings can now be specified within
createNonConformalCouplesDict. This allows for patchType overrides; for
example to create a jump condition over the coupling.

An alternate syntax has been added to facilitate this. If patch fields
do not need overriding then the old syntax can be used where patches
that are to be coupled are specified as a pair of names; e.g.:

    fields      yes;

    nonConformalCouples
    {
        fan
        {
            patches         (fan0 fan1);
            transform       none;
        }
    }

If patch fields do need overriding, then instead of the "patches" entry,
separate "owner" and "neighbour" sub-dictionaries should be used. These
can both contain a "patchFields" section detailing the boundary
conditions that apply to the newly created patches:

    fields      yes;

    nonConformalCouples
    {
        fan
        {
            owner
            {
                patch       fan0;

                patchFields
                {
                    p
                    {
                        type        fanPressureJump;
                        patchType   nonConformalCyclic;
                        jump        uniform 0;
                        value       uniform 0;
                        jumpTable   polynomial 1((100 0));
                    }
                }
            }

            neighbour
            {
                patch       fan1;

                patchFields
                {
                    $../../owner/patchFields;
                }
            }

            transform       none;
        }
    }

In this example, only the pressure boundary condition is overridden on
the newly created non-conformal cyclic. All other fields will have the
basic constraint type (i.e., nonConformalCyclic) applied.
2022-08-10 16:26:18 +01:00
b1d6e64d02 createNonConformalCouples: Put non-conformal couple settings in a sub dictionary
Settings for the individual non-conformal couples can now be put in a
"nonConformalCouples" sub-dictionary of the
system/createNonConformalCouplesDict. For example:

    fields  no;

    nonConformalCouples // <-- new sub-dictionary
    {
        nonConformalCouple_none
        {
            patches         (nonCouple1 nonCouple2);
            transform       none;
        }

        nonConformalCouple_30deg
        {
            patches         (nonCoupleBehind nonCoupleAhead);
            transform       rotational;
            rotationAxis    (-1 0 0);
            rotationCentre  (0 0 0);
            rotationAngle   30;
        }
    }

This permits settings to be #include-d from files that themselves
contain sub-dictionaries without the utility treating those
sub-dictionaries as if they specify a non-conformal coupling. It also
makes the syntax more comparable to that of createBafflesDict.

The new "nonConformalCouples" sub-dictionary is optional, so this change
is backwards compatible. The new syntax is recommended, however, and all
examples have been changed accordingly.
2022-08-10 16:25:54 +01:00
bfa40570ad bin/tools/RunFunctions: Added getSolver function for use with foamPostProcess 2022-08-10 09:37:10 +01:00
cd829836eb tutorials/modules/incompressibleFluid/mixerSRF: New tutorial to demonstrate an SRF simulation using MRF 2022-08-09 13:25:09 +01:00
ca89189ecd solvers::incompressibleFluid: New solver module for incompressible fluid flow
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations.  Replaces pimpleFoam, pisoFoam and simpleFoam and all
the corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleFluid.

Class
    Foam::solvers::incompressibleFluid

Description
    Solver module for steady or transient turbulent flow of incompressible
    isothermal fluids with optional mesh motion and change.

    Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
    pseudo-transient and steady simulations.

    Optional fvModels and fvConstraints are provided to enhance the simulation
    in many ways including adding various sources, constraining or limiting
    the solution.

    Reference:
    \verbatim
        Greenshields, C. J., & Weller, H. G. (2022).
        Notes on Computational Fluid Dynamics: General Principles.
        CFD Direct Ltd.: Reading, UK.
    \endverbatim

SourceFiles
    incompressibleFluid.C

See also
    Foam::solvers::fluidSolver
    Foam::solvers::isothermalFluid
2022-08-08 22:46:51 +01:00