1. 21 Dec, 2018 1 commit
    • Mark Olesen's avatar
      ENH: use Zero when zero-initializing types · e23bd3bb
      Mark Olesen authored
      - makes the intent clearer and avoids the need for additional
        constructor casting. Eg,
            labelList(10, Zero)    vs.  labelList(10, 0)
            scalarField(10, Zero)  vs.  scalarField(10, scalar(0))
            vectorField(10, Zero)  vs.  vectorField(10, vector::zero)
  2. 27 Nov, 2018 1 commit
  3. 30 Aug, 2018 1 commit
  4. 16 May, 2018 1 commit
  5. 03 Apr, 2018 1 commit
    • Mark Olesen's avatar
      STYLE: more consistent use of dimensioned Zero · 5632ef2d
      Mark Olesen authored
      - when constructing dimensioned fields that are to be zero-initialized,
        it is preferrable to use a form such as
            dimensionedScalar(dims, Zero)
            dimensionedVector(dims, Zero)
        rather than
            dimensionedScalar("0", dims, 0)
            dimensionedVector("zero", dims, vector::zero)
        This reduces clutter and also avoids any suggestion that the name of
        the dimensioned quantity has any influence on the field's name.
        An even shorter version is possible. Eg,
        but reduces the clarity of meaning.
      - NB: UniformDimensionedField is an exception to these style changes
        since it does use the name of the dimensioned type (instead of the
  6. 13 Dec, 2017 1 commit
  7. 01 Jun, 2017 1 commit
    • sergio's avatar
      Modification on rhoPimpleFoam pEq's for handling rho thermo and incompressible... · 1a701d9e
      sergio authored
      Modification on rhoPimpleFoam pEq's for handling rho thermo and incompressible EoS. Adding rho limiters if p is limited.
      This is important when LTS stepping or large Co number is used.
      Updating rhoBuoyantPimpleFoam to handle closed domain for rho thermo and incompressible Eos.
      Consolidating chtMultiRegionSimpleFoam and chtMultiRegionFoam pEqs to use the same formulation as rhoBuoyantPimpleFoam and
  8. 02 Dec, 2015 1 commit
    • Henry Weller's avatar
      fvOptions: Reorganized and updated to simplify use in sub-models and maintenance · 9a536b02
      Henry Weller authored
      fvOptions are transferred to the database on construction using
      fv::options::New which returns a reference.  The same function can be
      use for construction and lookup so that fvOptions are now entirely
      The abstract base-classes for fvOptions now reside in the finiteVolume
      library simplifying compilation and linkage.  The concrete
      implementations of fvOptions are still in the single monolithic
      fvOptions library but in the future this will be separated into smaller
      libraries based on application area which may be linked at run-time in
      the same manner as functionObjects.
  9. 01 Dec, 2015 1 commit
  10. 30 Nov, 2015 1 commit
  11. 15 Jul, 2015 1 commit
  12. 29 May, 2015 1 commit
    • Henry's avatar
      MRF: Separate MRF from fvOptions · 2b9a2adf
      Henry authored
      fvOptions does not have the appropriate structure to support MRF as it
      is based on option selection by user-specified fields whereas MRF MUST
      be applied to all velocity fields in the particular solver.  A
      consequence of the particular design choices in fvOptions made it
      difficult to support MRF for multiphase and it is easier to support
      frame-related and field related options separately.
      Currently the MRF functionality provided supports only rotations but
      the structure will be generalized to support other frame motions
      including linear acceleration, SRF rotation and 6DoF which will be
      run-time selectable.
  13. 10 Dec, 2014 1 commit