Commit Graph

16 Commits

Author SHA1 Message Date
30c877a7ab multiphaseEulerFoam: Use phaseSystem::propertiesName 2022-01-13 10:12:20 +00:00
3f1bb7ee13 multiphaseEulerFoam: Minor fixes to population balance function objects
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
2022-01-11 14:07:01 +00:00
32b656f8a7 multiphaseEulerFoam, turbulentDispersionModel: Corrected face-force for multiphase case
This is a completion of commit 64da7a2c. The fix has now also been
applied to the face-momentum equation.
2022-01-11 13:55:46 +00:00
794255284f multiphaseEulerFoam: revised sizeDistribution functionObject
Following the addition of the new moments functionObject, all related
functionality was removed from sizeDistribution.

In its revised version, sizeDistribution allows for different kinds of
weighted region averaging in case of field-dependent representative
particle properties.

A packaged function has also been added to allow for command line solver
post-processing.

For example, the following function object specification returns the
volume-based number density function:

    numberDensity
    {
        type                sizeDistribution;
        libs                ("libmultiphaseEulerFoamFunctionObjects.so");
        writeControl        writeTime;
        populationBalance   bubbles;
        functionType        numberDensity;
        coordinateType      volume;
        setFormat           raw;
    }

The same can be achieved using a packaged function:

    #includeFunc sizeDistribution
    (
        populationBalance=bubbles,
        functionType=numberDensity,
        coordinateType=volume,
        funcName=numberDensity
    )

Or on the command line:

    multiphaseEulerFoam -postProcess -func "
    sizeDistribution
    (
        populationBalance=bubbles,
        functionType=numberDensity,
        coordinateType=volume,
        funcName=numberDensity
    )"

Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
2022-01-07 09:48:30 +00:00
36c565b9bf multiphaseEulerFoam: new functionObject "moments"
This function calculates integral (integer moments) or mean properties
(mean, variance, standard deviation) of a size distribution computed with
multiphaseEulerFoam. It has to be run with multiphaseEulerFoam, either
at run-time or with -postProcess. It will not work with the postProcess
utility.

The following function object specification for example returns the first
moment of the volume-based number density function which is equivalent to
the phase fraction of the particulate phase:

    moments
    {
        type                moments;
        libs                ("libmultiphaseEulerFoamFunctionObjects.so");
        executeControl      timeStep;
        writeControl        writeTime;
        populationBalance   bubbles;
        momentType          integerMoment;
        coordinateType      volume;
        order               1;
    }

The same can be achieved using a packaged function:

    #includeFunc moments
    (
        populationBalance=bubbles,
        momentType=integerMoment,
        coordinateType=volume,
        order=1,
        funcName=moments
    )

Or on the command line:

    multiphaseEulerFoam -postProcess -func "
        moments
        (
            populationBalance=bubbles,
            momentType=integerMoment,
            coordinateType=volume,
            order=1,
            funcName=moments
        )"

Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
2022-01-07 09:48:30 +00:00
25a6d068f0 sampledSets, streamlines: Various improvements
Sampled sets and streamlines now write all their fields to the same
file. This prevents excessive duplication of the geometry and makes
post-processing tasks more convenient.

"axis" entries are now optional in sampled sets and streamlines. When
omitted, a default entry will be used, which is chosen appropriately for
the coordinate set and the write format. Some combinations are not
supported. For example, a scalar ("x", "y", "z" or "distance") axis
cannot be used to write in the vtk format, as vtk requires 3D locations
with which to associate data. Similarly, a point ("xyz") axis cannot be
used with the gnuplot format, as gnuplot needs a single scalar to
associate with the x-axis.

Streamlines can now write out fields of any type, not just scalars and
vectors, and there is no longer a strict requirement for velocity to be
one of the fields.

Streamlines now output to postProcessing/<functionName>/time/<file> in
the same way as other functions. The additional "sets" subdirectory has
been removed.

The raw set writer now aligns columns correctly.

The handling of segments in coordSet and sampledSet has been
fixed/completed. Segments mean that a coordinate set can represent a
number of contiguous lines, disconnected points, or some combination
thereof. This works in parallel; segments remain contiguous across
processor boundaries. Set writers now only need one write method, as the
previous "writeTracks" functionality is now handled by streamlines
providing the writer with the appropriate segment structure.

Coordinate sets and set writers now have a convenient programmatic
interface. To write a graph of A and B against some coordinate X, in
gnuplot format, we can call the following:

    setWriter::New("gnuplot")->write
    (
        directoryName,
        graphName,
        coordSet(true, "X", X), // <-- "true" indicates a contiguous
        "A",                    //     line, "false" would mean
        A,                      //     disconnected points
        "B",
        B
    );

This write function is variadic. It supports any number of
field-name-field pairs, and they can be of any primitive type.

Support for Jplot and Xmgrace formats has been removed. Raw, CSV,
Gnuplot, VTK and Ensight formats are all still available.

The old "graph" functionality has been removed from the code, with the
exception of the randomProcesses library and associated applications
(noise, DNSFoam and boxTurb). The intention is that these should also
eventually be converted to use the setWriters. For now, so that it is
clear that the "graph" functionality is not to be used elsewhere, it has
been moved into a subdirectory of the randomProcesses library.
2021-12-07 11:18:27 +00:00
c01118589f functionObjects: Added fields() function to provide list of required fields to postProcess
With this change each functionObject provides the list of fields required so
that the postProcess utility can pre-load them before executing the list of
functionObjects.  This provides a more convenient interface than using the
-field or -fields command-line options to postProcess which are now redundant.
2021-10-21 09:23:34 +01:00
65ef2cf331 physicalProperties: Standardised incompressible and compressible solver fluid properties
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers.  This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.

* physicalProperties
  Single abstract base-class for all fluid and solid physical property classes.

  Physical properties for a single fluid or solid within a region are now read
  from the 'constant/<region>/physicalProperties' dictionary.

  Physical properties for a phase fluid or solid within a region are now read
  from the 'constant/<region>/physicalProperties.<phase>' dictionary.

  This replaces the previous inconsistent naming convention of
  'transportProperties' for incompressible solvers and
  'thermophysicalProperties' for compressible solvers.

  Backward-compatibility is provided by the solvers reading
  'thermophysicalProperties' or 'transportProperties' if the
  'physicalProperties' dictionary does not exist.

* phaseProperties
  All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
  interfacial models and coefficients from the
  'constant/<region>/phaseProperties' dictionary.

  Backward-compatibility is provided by the solvers reading
  'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
  dictionary does not exist.  For incompressible VoF solvers the
  'transportProperties' is automatically upgraded to 'phaseProperties' and the
  two 'physicalProperties.<phase>' dictionary for the phase properties.

* viscosity
  Abstract base-class (interface) for all fluids.

  Having a single interface for the viscosity of all types of fluids facilitated
  a substantial simplification of the 'momentumTransport' library, avoiding the
  need for a layer of templating and providing total consistency between
  incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
  momentum transport models.  This allows the generalised Newtonian viscosity
  models to be used in the same form within laminar as well as RAS and LES
  momentum transport closures in any solver.  Strain-rate dependent viscosity
  modelling is particularly useful with low-Reynolds number turbulence closures
  for non-Newtonian fluids where the effect of bulk shear near the walls on the
  viscosity is a dominant effect.  Within this framework it would also be
  possible to implement generalised Newtonian models dependent on turbulent as
  well as mean strain-rate if suitable model formulations are available.

* visosityModel
  Run-time selectable Newtonian viscosity model for incompressible fluids
  providing the 'viscosity' interface for 'momentumTransport' models.

  Currently a 'constant' Newtonian viscosity model is provided but the structure
  supports more complex functions of time, space and fields registered to the
  region database.

  Strain-rate dependent non-Newtonian viscosity models have been removed from
  this level and handled in a more general way within the 'momentumTransport'
  library, see section 'viscosity' above.

  The 'constant' viscosity model is selected in the 'physicalProperties'
  dictionary by

      viscosityModel  constant;

  which is equivalent to the previous entry in the 'transportProperties'
  dictionary

      transportModel  Newtonian;

  but backward-compatibility is provided for both the keyword and model
  type.

* thermophysicalModels
  To avoid propagating the unnecessary constructors from 'dictionary' into the
  new 'physicalProperties' abstract base-class this entire structure has been
  removed from the 'thermophysicalModels' library.  The only use for this
  constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
  dictionary from the baffle region directory which is far simpler and more
  consistent and significantly reduces the amount of constructor code in the
  'thermophysicalModels' library.

* compressibleInterFoam
  The creation of the 'viscosity' interface for the 'momentumTransport' models
  allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
  replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
  'viscosity' interface, avoiding the myriad of unused thermodynamic functions
  required by 'rhoThermo' to be defined for the mixture.

  Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.

This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.

Henry G. Weller
CFD Direct Ltd.
2021-07-30 17:19:54 +01:00
f4a65fbada sampling: Renamed and moved classes from fileFormats
The writer class has been renamed setWriter in order to clarify its
usage. The coordSet and setWriter classes have been moved into the
sampling library, as this fits their usage.
2021-06-18 13:57:11 +01:00
ee777e4083 Standardise on British spelling: -ize -> -ise
OpenFOAM is predominantly written in Britain with British spelling conventions
so -ise is preferred to -ize.
2021-06-01 19:11:58 +01:00
8a5ee8aac1 MomentumTransportModels: Library builds of multiphase models
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.

This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".

This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.

Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.

There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
2021-03-30 13:27:20 +01:00
3ca14ebe58 functionObjects: Fixes to restart and run-time modification behaviour
All function objects now re-read as a result of run-time modifications
to the system/controlDict.

Function objects that write log files (via the logFiles class) will now
generate a new postProcessing/<funcName>/<time> directory as a result of
either restart or run-time modification. Log files will therefore never
be overwritten by restart or run-time modification, except for when a
case is restarted at the same time as a previous execution (e.g.,
repeated runs at the start time).
2021-01-26 08:12:21 +00:00
def4772281 Documentation: Centred the Class Declaration comment
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
2020-08-28 13:28:58 +01:00
f4facbc664 multiphaseEulerFoam: Updated documentation
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
2020-07-30 12:27:35 +01:00
49c9766c44 multiphaseEulerFoam: Updated name of functionObjects library 2020-07-15 20:53:05 +01:00
b832453b72 multiphaseEulerFoam: replacement for reactingMultiphaseEulerFoam
The new multiphaseEulerFoam is based on reactingMultiphaseEulerFoam with some
improvements and rationalisation to assist maintenance and further development.

The phase system solution has been enhanced to handle two phases more
effectively and all two-phase specific models updated for compatibility so that
multiphaseEulerFoam can also replace reactingTwoPhaseEulerFoam.
When running multiphaseEulerFoam with only two-phases the default behaviour is
to solve for both phase-fractions but optionally a reference phase can be
specified so that only the other phase-fraction is solved, providing better
compatibility with the behaviour of reactingTwoPhaseEulerFoam.

All reactingMultiphaseEulerFoam and reactingTwoPhaseEulerFoam tutorials have
been updated for multiphaseEulerFoam.
2020-07-15 18:13:40 +01:00