Skip to content
Snippets Groups Projects
  1. Dec 15, 2016
  2. Oct 07, 2016
  3. Sep 19, 2016
  4. May 08, 2016
  5. Apr 30, 2016
    • Henry Weller's avatar
      GeometricField: Renamed internalField() -> primitiveField() and... · 3c053c2f
      Henry Weller authored
      GeometricField: Renamed internalField() -> primitiveField() and dimensionedInternalField() -> internalField()
      
      These new names are more consistent and logical because:
      
      primitiveField():
      primitiveFieldRef():
          Provides low-level access to the Field<Type> (primitive field)
          without dimension or mesh-consistency checking.  This should only be
          used in the low-level functions where dimensional consistency is
          ensured by careful programming and computational efficiency is
          paramount.
      
      internalField():
      internalFieldRef():
          Provides access to the DimensionedField<Type, GeoMesh> of values on
          the internal mesh-type for which the GeometricField is defined and
          supports dimension and checking and mesh-consistency checking.
      3c053c2f
  6. Apr 28, 2016
    • Henry Weller's avatar
      GeometricField::GeometricBoundaryField -> GeometricField::Boundary · ea5401c7
      Henry Weller authored
      When the GeometricBoundaryField template class was originally written it
      was a separate class in the Foam namespace rather than a sub-class of
      GeometricField as it is now.  Without loss of clarity and simplifying
      code which access the boundary field of GeometricFields it is better
      that GeometricBoundaryField be renamed Boundary for consistency with the
      new naming convention for the type of the dimensioned internal field:
      Internal, see commit 4a57b9be
      
      This is a very simple text substitution change which can be applied to
      any code which compiles with the OpenFOAM-dev libraries.
      ea5401c7
  7. Apr 25, 2016
    • Henry Weller's avatar
      Completed boundaryField() -> boundaryFieldRef() · 22f4ad32
      Henry Weller authored
      Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1938
      
      Because C++ does not support overloading based on the return-type there
      is a problem defining both const and non-const member functions which
      are resolved based on the const-ness of the object for which they are
      called rather than the intent of the programmer declared via the
      const-ness of the returned type.  The issue for the "boundaryField()"
      member function is that the non-const version increments the
      event-counter and checks the state of the stored old-time fields in case
      the returned value is altered whereas the const version has no
      side-effects and simply returns the reference.  If the the non-const
      function is called within the patch-loop the event-counter may overflow.
      To resolve this it in necessary to avoid calling the non-const form of
      "boundaryField()" if the results is not altered and cache the reference
      outside the patch-loop when mutation of the patch fields is needed.
      
      The most straight forward way of resolving this problem is to name the
      const and non-const forms of the member functions differently e.g. the
      non-const form could be named:
      
          mutableBoundaryField()
          mutBoundaryField()
          nonConstBoundaryField()
          boundaryFieldRef()
      
      Given that in C++ a reference is non-const unless specified as const:
      "T&" vs "const T&" the logical convention would be
      
          boundaryFieldRef()
          boundaryFieldConstRef()
      
      and given that the const form which is more commonly used is it could
      simply be named "boundaryField()" then the logical convention is
      
          GeometricBoundaryField& boundaryFieldRef();
      
          inline const GeometricBoundaryField& boundaryField() const;
      
      This is also consistent with the new "tmp" class for which non-const
      access to the stored object is obtained using the ".ref()" member function.
      
      This new convention for non-const access to the components of
      GeometricField will be applied to "dimensionedInternalField()" and "internalField()" in the
      future, i.e. "dimensionedInternalFieldRef()" and "internalFieldRef()".
      22f4ad32
  8. Feb 29, 2016
  9. Feb 18, 2016
  10. Feb 13, 2016
    • Henry Weller's avatar
      Solvers: Added support for extrapolated pressure boundary conditions · fc2ce737
      Henry Weller authored
      The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
      function which applies the velocity boundary values for patches for which the
      velocity cannot be modified by assignment and pressure extrapolation is
      not specified via the new
      "fixedFluxExtrapolatedPressureFvPatchScalarField".
      
      The new function "constrainPressure" sets the pressure gradient
      appropriately for "fixedFluxPressureFvPatchScalarField" and
      "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
      ensure the evaluated flux corresponds to the known velocity values at
      the boundary.
      
      The "fixedFluxPressureFvPatchScalarField" boundary condition operates
      exactly as before, ensuring the correct flux at fixed-flux boundaries by
      compensating for the body forces (gravity in particular) with the
      pressure gradient.
      
      The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
      condition may be used for cases with or without body-forces to set the
      pressure gradient to compensate not only for the body-force but also the
      extrapolated "HbyA" which provides a second-order boundary condition for
      pressure.  This is useful for a range a problems including impinging
      flow, extrapolated inlet conditions with body-forces or for highly
      viscous flows, pressure-induced separation etc.  To test this boundary
      condition at walls in the motorBike tutorial case set
      
          lowerWall
          {
              type            fixedFluxExtrapolatedPressure;
          }
      
          motorBikeGroup
          {
              type            fixedFluxExtrapolatedPressure;
          }
      
      Currently the new extrapolated pressure boundary condition is supported
      for all incompressible and sub-sonic compressible solvers except those
      providing implicit and tensorial porosity support.  The approach will be
      extended to cover these solvers and options in the future.
      
      Note: the extrapolated pressure boundary condition is experimental and
      requires further testing to assess the range of applicability,
      stability, accuracy etc.
      
      Henry G. Weller
      CFD Direct Ltd.
      fc2ce737
  11. Dec 03, 2015
  12. Dec 02, 2015
    • Henry Weller's avatar
      fvOptions: Reorganized and updated to simplify use in sub-models and maintenance · 736621b9
      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
      demand-driven.
      
      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.
      736621b9
  13. Dec 01, 2015
  14. Sep 11, 2015
  15. Jul 21, 2015
  16. Jul 20, 2015
  17. Jul 19, 2015
  18. Jul 15, 2015
  19. Jun 28, 2015
  20. Jun 26, 2015
  21. May 29, 2015
    • Henry's avatar
      MRF: Separate MRF from fvOptions · c3ee2348
      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.
      c3ee2348
  22. Apr 29, 2015
    • Henry's avatar
      MULES: nLimiterIter and smoothLimiter are now user-input via the corresponding fvSolution sub-dict · f7e4d0a1
      Henry authored
      nLimiterIter: Number of iterations during limiter construction
          3 (default) is sufficient for 3D simulations with a Courant number 0.5 or so
          For larger Courant numbers larger values may be needed but this is
          only relevant for IMULES and CMULES
      
      smoothLimiter: Coefficient to smooth the limiter to avoid "diamond"
          staggering patters seen in regions of low particle phase-fraction in
          fluidised-bed simulations.
      
          The default is 0 as it is not needed for all simulations.
          A value of 0.1 is appropriate for fluidised-bed simulations.
          The useful range is 0 -> 0.5.
          Values larger than 0.5 may cause excessive smearing of the solution.
      f7e4d0a1
  23. Mar 19, 2015
  24. Mar 17, 2015
    • Henry's avatar
      Solvers based on p_rgh: Added support for optional hRef · e588d618
      Henry authored
      Allows the specification of a reference height, for example the height
      of the free-surface in a VoF simulation, which reduces the range of p_rgh.
      
      hRef is a uniformDimensionedScalarField specified via the constant/hRef
      file, equivalent to the way in which g is specified, so that it can be
      looked-up from the database.  For example see the constant/hRef file in
      the DTCHull LTSInterFoam and interDyMFoam cases.
      e588d618
  25. Feb 11, 2015
  26. Feb 10, 2015
  27. Feb 09, 2015
  28. Jan 21, 2015
    • Henry's avatar
    • Henry's avatar
      Updated the whole of OpenFOAM to use the new templated TurbulenceModels library · 2aec2496
      Henry authored
      The old separate incompressible and compressible libraries have been removed.
      
      Most of the commonly used RANS and LES models have been upgraded to the
      new framework but there are a few missing which will be added over the
      next few days, in particular the realizable k-epsilon model.  Some of
      the less common incompressible RANS models have been introduced into the
      new library instantiated for incompressible flow only.  If they prove to
      be generally useful they can be templated for compressible and
      multiphase application.
      
      The Spalart-Allmaras DDES and IDDES models have been thoroughly
      debugged, removing serious errors concerning the use of S rather than
      Omega.
      
      The compressible instances of the models have been augmented by a simple
      backward-compatible eddyDiffusivity model for thermal transport based on
      alphat and alphaEff.  This will be replaced with a separate run-time
      selectable thermal transport model framework in a few weeks.
      
      For simplicity and ease of maintenance and further development the
      turbulent transport and wall modeling is based on nut/nuEff rather than
      mut/muEff for compressible models so that all forms of turbulence models
      can use the same wall-functions and other BCs.
      
      All turbulence model selection made in the constant/turbulenceProperties
      dictionary with RAS and LES as sub-dictionaries rather than in separate
      files which added huge complexity for multiphase.
      
      All tutorials have been updated so study the changes and update your own
      cases by comparison with similar cases provided.
      
      Sorry for the inconvenience in the break in backward-compatibility but
      this update to the turbulence modeling is an essential step in the
      future of OpenFOAM to allow more models to be added and maintained for a
      wider range of cases and physics.  Over the next weeks and months more
      turbulence models will be added of single and multiphase flow, more
      additional sub-models and further development and testing of existing
      models.  I hope this brings benefits to all OpenFOAM users.
      
      Henry G. Weller
      2aec2496
  29. Apr 29, 2014
  30. Mar 17, 2014
  31. Nov 26, 2013
  32. Oct 30, 2013
  33. Oct 27, 2013