1. 25 Jun, 2019 1 commit
  2. 20 Dec, 2018 1 commit
  3. 14 Dec, 2018 1 commit
  4. 13 Dec, 2018 1 commit
  5. 11 Dec, 2018 1 commit
  6. 02 Dec, 2018 2 commits
    • Mark OLESEN's avatar
      ENH: configurable output temperature for externalCoupled mixed T BC (#1072) · 44bc9cab
      Mark OLESEN authored
      - Uses the user-specified value for outputTemperature:
      
        {
            type  externalCoupledTemperature;
            outputTemperture  fluid;  // or wall;
        }
      
        Otherwises uses 'wall' as a default (for compatibility) and emits a
        warning.
      
        The T.out header now reflects the type of output. Eg,
      
           # Values: area Tfluid qDot htc
      44bc9cab
    • Mark OLESEN's avatar
      TUT: use defaultPatch for naming instead of explicit Default_Boundary_Region · a04f472f
      Mark OLESEN authored
      - tutorials based on squareBend used Default_Boundary_Region explicitly
        defined since they predated the defaultPatch renaming (2008).
        The name 'Default_Boundary_Region' was for convenience as the default
        name when converting to PROSTAR or CCM formation, but can now be
        changed to something more generic.
      
      - define wall boundary conditions for squareBend using a general regex
        to allow future splitting of wall types by name.
      a04f472f
  7. 24 Nov, 2018 1 commit
  8. 05 Oct, 2018 1 commit
    • Mark OLESEN's avatar
      ENH: improve, simplify, rationalize coordinate system handling (issue #863) · c75d5118
      Mark OLESEN authored
      Previously the coordinate system functionality was split between
      coordinateSystem and coordinateRotation. The coordinateRotation stored
      the rotation tensor and handled all tensor transformations.
      
      The functionality has now been revised and consolidated into the
      coordinateSystem classes. The sole purpose of coordinateRotation
      is now just to provide a selectable mechanism of how to define the
      rotation tensor (eg, axis-angle, euler angles, local axes) for user
      input, but after providing the appropriate rotation tensor it has
      no further influence on the transformations.
      
      --
      
      The coordinateSystem class now contains an origin and a base rotation
      tensor directly and various transformation methods.
      
        - The origin represents the "shift" for a local coordinate system.
      
        - The base rotation tensor represents the "tilt" or orientation
          of the local coordinate system in general (eg, for mapping
          positions), but may require position-dependent tensors when
          transforming vectors and tensors.
      
      For some coordinate systems (currently the cylindrical coordinate system),
      the rotation tensor required for rotating a vector or tensor is
      position-dependent.
      
      The new coordinateSystem and its derivates (cartesian, cylindrical,
      indirect) now provide a uniform() method to define if the rotation
      tensor is position dependent/independent.
      
      The coordinateSystem transform and invTransform methods are now
      available in two-parameter forms for obtaining position-dependent
      rotation tensors. Eg,
      
            ... = cs.transform(globalPt, someVector);
      
      In some cases it can be useful to use query uniform() to avoid
      storage of redundant values.
      
            if (cs.uniform())
            {
                vector xx = cs.transform(someVector);
            }
            else
            {
                List<vector> xx = cs.transform(manyPoints, someVector);
            }
      
      Support transform/invTransform for common data types:
         (scalar, vector, sphericalTensor, symmTensor, tensor).
      
      ====================
        Breaking Changes
      ====================
      
      - These changes to coordinate systems and rotations may represent
        a breaking change for existing user coding.
      
      - Relocating the rotation tensor into coordinateSystem itself means
        that the coordinate system 'R()' method now returns the rotation
        directly instead of the coordinateRotation. The method name 'R()'
        was chosen for consistency with other low-level entities (eg,
        quaternion).
      
        The following changes will be needed in coding:
      
            Old:  tensor rot = cs.R().R();
            New:  tensor rot = cs.R();
      
            Old:  cs.R().transform(...);
            New:  cs.transform(...);
      
        Accessing the runTime selectable coordinateRotation
        has moved to the rotation() method:
      
            Old:  Info<< "Rotation input: " << cs.R() << nl;
            New:  Info<< "Rotation input: " << cs.rotation() << nl;
      
      - Naming consistency changes may also cause code to break.
      
            Old:  transformVector()
            New:  transformPrincipal()
      
        The old method name transformTensor() now simply becomes transform().
      
      ====================
        New methods
      ====================
      
      For operations requiring caching of the coordinate rotations, the
      'R()' method can be used with multiple input points:
      
             tensorField rots(cs.R(somePoints));
      
         and later
      
             Foam::transformList(rots, someVectors);
      
      The rotation() method can also be used to change the rotation tensor
      via a new coordinateRotation definition (issue #879).
      
      The new methods transformPoint/invTransformPoint provide
      transformations with an origin offset using Cartesian for both local
      and global points. These can be used to determine the local position
      based on the origin/rotation without interpreting it as a r-theta-z
      value, for example.
      
      ================
        Input format
      ================
      
      - Streamline dictionary input requirements
      
        * The default type is cartesian.
        * The default rotation type is the commonly used axes rotation
          specification (with e1/e2/3), which is assumed if the 'rotation'
          sub-dictionary does not exist.
      
          Example,
      
          Compact specification:
      
              coordinateSystem
              {
                  origin  (0 0 0);
                  e2      (0 1 0);
                  e3      (0.5 0 0.866025);
              }
      
          Full specification (also accepts the longer 'coordinateRotation'
          sub-dictionary name):
      
              coordinateSystem
              {
                  type    cartesian;
                  origin  (0 0 0);
      
                  rotation
                  {
                      type    axes;
                      e2      (0 1 0);
                      e3      (0.5 0 0.866025);
                  }
              }
      
         This simplifies the input for many cases.
      
      - Additional rotation specification 'none' (an identity rotation):
      
            coordinateSystem
            {
                origin  (0 0 0);
                rotation { type none; }
            }
      
      - Additional rotation specification 'axisAngle', which is similar
        to the -rotate-angle option for transforming points (issue #660).
        For some cases this can be more intuitive.
      
        For example,
      
            rotation
            {
                type    axisAngle;
                axis    (0 1 0);
                angle   30;
            }
        vs.
            rotation
            {
                type    axes;
                e2      (0 1 0);
                e3      (0.5 0 0.866025);
            }
      
      - shorter names (or older longer names) for the coordinate rotation
        specification.
      
           euler         EulerRotation
           starcd        STARCDRotation
           axes          axesRotation
      
      ================
        Coding Style
      ================
      - use Foam::coordSystem namespace for categories of coordinate systems
        (cartesian, cylindrical, indirect). This reduces potential name
        clashes and makes a clearer declaration. Eg,
      
            coordSystem::cartesian csys_;
      
        The older names (eg, cartesianCS, etc) remain available via typedefs.
      
      - added coordinateRotations namespace for better organization and
        reduce potential name clashes.
      c75d5118
  9. 18 Jul, 2018 1 commit
  10. 11 Jul, 2018 1 commit
  11. 28 Jun, 2018 2 commits
  12. 22 Jun, 2018 1 commit
  13. 21 Jun, 2018 1 commit
  14. 01 Jun, 2018 1 commit
  15. 16 May, 2018 3 commits
    • Chris Greenshields's avatar
      TUT: aerofoilNACA0012 tutorial for rhoSimpleFoam and rhoPimpleFoam · 6fb9c777
      Chris Greenshields authored and Andrew Heather's avatar Andrew Heather committed
      The tutorial demonstrates generation of a C-grid mesh using blockMesh
      The geometry is provided by a surface mesh (OBJ file) of the NACA0012 aerofoil
      The case is setup with a freestream flow speed of Ma=0.72
      
      Thanks to Kai Bastos at Duke University for the geometry and helpful input.
      6fb9c777
    • Henry Weller's avatar
      ENH: rhePimpleFoam: Merged dynamic mesh functionality of rhoPimpleDyMFoam into rhoPimpleFoam · 9191e62e
      Henry Weller authored and Andrew Heather's avatar Andrew Heather committed
      and replaced rhoPimpleDyMFoam with a script which reports this change.
      
      The rhoPimpleDyMFoam tutorials have been moved into the rhoPimpleFoam directory.
      
      This change is the first of a set of developments to merge dynamic mesh
      functionality into the standard solvers to improve consistency, usability,
      flexibility and maintainability of these solvers.
      
      Henry G. Weller
      CFD Direct Ltd.
      
      rhoReactingFoam: Updated for changes to rhoPimpleFoam files
      9191e62e
    • Henry Weller's avatar
      ENH: pimpleDyMFoam: Improved efficiency and consistency when running on a static mesh · 87a5659e
      Henry Weller authored and Andrew Heather's avatar Andrew Heather committed
      Now pimpleDyMFoam is exactly equivalent to pimpleFoam when running on a
      staticFvMesh.  Also when the constant/dynamicMeshDict is not present a
      staticFvMesh is automatically constructed so that the pimpleDyMFoam solver can
      run any pimpleFoam case without change.
      
      pimpleDyMFoam: Store Uf as an autoPtr for better error handling
      
      pimpleFoam: Set initial deltaT from the Courant number
      
      for improved stability on start-up and compatibility with pimpleDyMFoam
      
      ENH: pimpleFoam: Merged dynamic mesh functionality of pimpleDyMFoam into pimpleFoam
      
      and replaced pimpleDyMFoam with a script which reports this change.
      
      The pimpleDyMFoam tutorials have been moved into the pimpleFoam directory.
      
      This change is the first of a set of developments to merge dynamic mesh
      functionality into the standard solvers to improve consistency, usability,
      flexibility and maintainability of these solvers.
      
      Henry G. Weller
      CFD Direct Ltd.
      
      tutorials/incompressible/pimpleFoam: Updated pimpleDyMFoam tutorials to run pimpleFoam
      
      Renamed tutorials/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D_pimpleDyMFoam
      
      -> tutorials/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D_pimpleFoam
      87a5659e
  16. 22 Feb, 2018 1 commit
  17. 18 Jan, 2018 1 commit
  18. 19 Dec, 2017 2 commits
  19. 30 Nov, 2017 1 commit
    • Mark OLESEN's avatar
      ENH: region-wise decomposition specification for decomposeParDict · 0f3932b3
      Mark OLESEN authored
        Within decomposeParDict, it is now possible to specify a different
        decomposition method, methods coefficients or number of subdomains
        for each region individually.
      
        The top-level numberOfSubdomains remains mandatory, since this
        specifies the number of domains for the entire simulation.
        The individual regions may use the same number or fewer domains.
      
        Any optional method coefficients can be specified in a general
        "coeffs" entry or a method-specific one, eg "metisCoeffs".
      
        For multiLevel, only the method-specific "multiLevelCoeffs" dictionary
        is used, and is also mandatory.
      
      ----
      
      ENH: shortcut specification for multiLevel.
      
        In addition to the longer dictionary form, it is also possible to
        use a shorter notation for multiLevel decomposition when the same
        decomposition method applies to each level.
      0f3932b3
  20. 28 Oct, 2017 1 commit
    • sergio's avatar
      ENH: Arrhenius viscocity model and energyTransport function-object · c8df785f
      sergio authored and Mark OLESEN's avatar Mark OLESEN committed
      - Arrhenius viscocity model for incompressible viscocity.
      
      - energyTransport FO for incompressible single and multiple phase
        flows and viscousDissipation fvOption source.
      
      - Tutorial to show the use of energyTransport:
           multiphase/multiphaseInterFoam/laminar/mixerVessel2D
      
      - Tutorial to show viscousDissipation:
           compressible/rhoPimpleFoam/RAS/TJunction
      c8df785f
  21. 20 Oct, 2017 1 commit
  22. 03 Aug, 2017 1 commit
    • Mark OLESEN's avatar
      TUT: use general 'scale' instead of 'convertToMeters' in blockMeshDict · ab84869c
      Mark OLESEN authored
      - although this has been supported for many years, the tutorials
        continued to use "convertToMeters" entry, which is specific to blockMesh.
        The "scale" is more consistent with other dictionaries.
      
      ENH:
      - ignore "scale 0;" (treat as no scaling) for blockMeshDict,
        consistent with use elsewhere.
      ab84869c
  23. 06 Jul, 2017 1 commit
  24. 27 Jun, 2017 1 commit
  25. 21 Jun, 2017 1 commit
  26. 13 Jun, 2017 1 commit
    • Mark OLESEN's avatar
      TUT: consistent writeCompression option · 0daeff36
      Mark OLESEN authored
      - Use on/off vs longer compressed/uncompressed.
        For consistency, replaced yes/no with on/off.
      
      - Avoid the combination of binary/compressed,
        which is disallowed and provokes a warning anyhow
      0daeff36
  27. 30 May, 2017 1 commit
  28. 18 May, 2017 1 commit
  29. 13 Apr, 2017 1 commit
    • Henry Weller's avatar
      fvOptions: The "<type>Coeffs" sub-dictionary is now optional · e3c67dc1
      Henry Weller authored
      For example the actuationDiskSource fvOption may now be specified
      
      disk1
      {
          type            actuationDiskSource;
      
          fields      (U);
      
          selectionMode   cellSet;
          cellSet         actuationDisk1;
          diskDir         (1 0 0);    // Orientation of the disk
          Cp              0.386;
          Ct              0.58;
          diskArea        40;
          upstreamPoint   (581849 4785810 1065);
      }
      
      rather than
      
      disk1
      {
          type            actuationDiskSource;
          active          on;
      
          actuationDiskSourceCoeffs
          {
              fields      (U);
      
              selectionMode   cellSet;
              cellSet         actuationDisk1;
              diskDir         (1 0 0);    // Orientation of the disk
              Cp              0.386;
              Ct              0.58;
              diskArea        40;
              upstreamPoint   (581849 4785810 1065);
          }
      }
      
      but this form is supported for backward compatibility.
      e3c67dc1
  30. 17 Mar, 2017 1 commit
    • Chris Greenshields's avatar
      pitzDaily tutorials: updated blockMeshDict files to use multi-grading · 03998692
      Chris Greenshields authored
      The pitzDaily case uses a lot of mesh grading close to walls and the shear layer.
      Prior to v2.4, blockMesh only permitted grading in one direction within a single block,
      so the pitzDaily mesh comprised of 13 blocks to accommodate the complex grading pattern.
      
      blockMesh has multi-grading that allows users to divide a block in a given direction and
      apply different grading within each division.  The mesh generated with blockMesh using
      13 blocks has been replaced with a mesh of 5 blocks that use multi-grading.  The new
      blockMeshDict configuration produces a mesh very similar to the original 13-block mesh.
      03998692
  31. 28 Feb, 2017 1 commit
    • Henry Weller's avatar
      rhoPimpleFoam: Added support for transonic flow of liquids and real gases · 99c992d6
      Henry Weller authored
      Both stardard SIMPLE and the SIMPLEC (using the 'consistent' option in
      fvSolution) are now supported for both subsonic and transonic flow of all
      fluid types.
      
      rhoPimpleFoam now instantiates the lower-level fluidThermo which instantiates
      either a psiThermo or rhoThermo according to the 'type' specification in
      thermophysicalProperties, see also commit 655fc787
      99c992d6
  32. 17 Feb, 2017 1 commit
    • Henry Weller's avatar
      thermophysicalModels: Changed specie thermodynamics from mole to mass basis · abc50e21
      Henry Weller authored
      The fundamental properties provided by the specie class hierarchy were
      mole-based, i.e. provide the properties per mole whereas the fundamental
      properties provided by the liquidProperties and solidProperties classes are
      mass-based, i.e. per unit mass.  This inconsistency made it impossible to
      instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
      transport solvers on liquidProperties.  In order to combine VoF with film and/or
      Lagrangian models it is essential that the physical propertied of the three
      representations of the liquid are consistent which means that it is necessary to
      instantiate the thermodynamics packages on liquidProperties.  This requires
      either liquidProperties to be rewritten mole-based or the specie classes to be
      rewritten mass-based.  Given that most of OpenFOAM solvers operate
      mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
      is more consistent and efficient if the low-level thermodynamics is also
      mass-based.
      
      This commit includes all of the changes necessary for all of the thermodynamics
      in OpenFOAM to operate mass-based and supports the instantiation of
      thermodynamics packages on liquidProperties.
      
      Note that most users, developers and contributors to OpenFOAM will not notice
      any difference in the operation of the code except that the confusing
      
          nMoles     1;
      
      entries in the thermophysicalProperties files are no longer needed or used and
      have been removed in this commet.  The only substantial change to the internals
      is that species thermodynamics are now "mixed" with mass rather than mole
      fractions.  This is more convenient except for defining reaction equilibrium
      thermodynamics for which the molar rather than mass composition is usually know.
      The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
      equilibriumFlameT utilities in which the species thermodynamics are
      pre-multiplied by their molecular mass to effectively convert them to mole-basis
      to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
      equilibriumCO
      
          // Reactants (mole-based)
          thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
      
          // Oxidant (mole-based)
          thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
          thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
      
          // Intermediates (mole-based)
          thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
      
          // Products (mole-based)
          thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
          thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
          thermo CO(thermoData.subDict("CO")); CO *= CO.W();
      
          // Product dissociation reactions
      
          thermo CO2BreakUp
          (
              CO2 == CO + 0.5*O2
          );
      
          thermo H2OBreakUp
          (
              H2O == H2 + 0.5*O2
          );
      
      Please report any problems with this substantial but necessary rewrite of the
      thermodynamic at https://bugs.openfoam.org
      
      Henry G. Weller
      CFD Direct Ltd.
      abc50e21
  33. 16 Dec, 2016 1 commit
  34. 14 Dec, 2016 1 commit
  35. 13 Dec, 2016 1 commit