1. 06 Dec, 2016 1 commit
  2. 04 Dec, 2016 1 commit
  3. 31 Oct, 2016 1 commit
  4. 03 May, 2016 2 commits
  5. 25 Apr, 2016 1 commit
    • 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
  6. 06 Apr, 2016 1 commit
  7. 26 Feb, 2016 1 commit
    • Henry Weller's avatar
      OpenFOAM: Updated all libraries, solvers and utilities to use the new const-safe tmp · cd852be3
      Henry Weller authored
      The deprecated non-const tmp functionality is now on the compiler switch
      NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC
      in the Make/options file.  However, it is recommended to upgrade all
      code to the new safer tmp by using the '.ref()' member function rather
      than the non-const '()' dereference operator when non-const access to
      the temporary object is required.
      
      Please report any problems on Mantis.
      
      Henry G. Weller
      CFD Direct.
      cd852be3
  8. 17 Jan, 2016 1 commit
  9. 25 Sep, 2015 2 commits
  10. 26 Aug, 2015 1 commit
  11. 26 Jun, 2015 1 commit
  12. 25 Jun, 2015 3 commits
  13. 12 Jun, 2015 2 commits
    • Henry Weller's avatar
      reactingTwoPhaseEulerFoam: New twoPhaseEulerFoam supporting mass-transfer and reactions · eb53f9bd
      Henry Weller authored
      Multi-species, mass-transfer and reaction support and multi-phase
      structure provided by William Bainbridge.
      
      Integration of the latest p-U and face-p_U algorithms with William's
      multi-phase structure is not quite complete due to design
      incompatibilities which needs further development.  However the
      integration of the functionality is complete.
      
      The results of the tutorials are not exactly the same for the
      twoPhaseEulerFoam and reactingTwoPhaseEulerFoam solvers but are very
      similar.  Further analysis in needed to ensure these differences are
      physical or to resolve them; in the meantime the twoPhaseEulerFoam
      solver will be maintained.
      eb53f9bd
    • Henry Weller's avatar
      twoPhaseEulerFoam: Minor reorganization · 360604b1
      Henry Weller authored
      360604b1
  14. 07 Jun, 2015 1 commit
  15. 29 May, 2015 1 commit
  16. 09 May, 2015 1 commit
  17. 08 May, 2015 1 commit
  18. 28 Apr, 2015 1 commit
  19. 27 Apr, 2015 1 commit
    • Henry's avatar
      twoPhaseEulerFoam: Added experimental face-based momentum equation formulation · fc6b44ee
      Henry authored
      This formulation provides C-grid like pressure-flux staggering on an
      unstructured mesh which is hugely beneficial for Euler-Euler multiphase
      equations as it allows for all forces to be treated in a consistent
      manner on the cell-faces which provides better balance, stability and
      accuracy.  However, to achieve face-force consistency the momentum
      transport terms must be interpolated to the faces reducing accuracy of
      this part of the system but this is offset by the increase in accuracy
      of the force-balance.
      
      Currently it is not clear if this face-based momentum equation
      formulation is preferable for all Euler-Euler simulations so I have
      included it on a switch to allow evaluation and comparison with the
      previous cell-based formulation.  To try the new algorithm simply switch
      it on, e.g.:
      
      PIMPLE
      {
          nOuterCorrectors 3;
          nCorrectors      1;
          nNonOrthogonalCorrectors 0;
          faceMomentum     yes;
      }
      
      It is proving particularly good for bubbly flows, eliminating the
      staggering patterns often seen in the air velocity field with the
      previous algorithm, removing other spurious numerical artifacts in the
      velocity fields and improving stability and allowing larger time-steps
      For particle-gas flows the advantage is noticeable but not nearly as
      pronounced as in the bubbly flow cases.
      
      Please test the new algorithm on your cases and provide feedback.
      
      Henry G. Weller
      CFD Direct
      fc6b44ee