1. 05 Aug, 2020 1 commit
  2. 31 Oct, 2019 1 commit
  3. 07 Jun, 2019 1 commit
    • Sergio Ferraris's avatar
      INT: Org integration of VOF, Euler phase solvers and models. · 8170f2ad
      Sergio Ferraris authored
      Integration of VOF MULES new interfaces. Update of VOF solvers and all instances
      of MULES in the code.
      Integration of reactingTwoPhaseEuler and reactingMultiphaseEuler solvers and sub-models
      Updating reactingEuler tutorials accordingly (most of them tested)
      
      New eRefConst thermo used in tutorials. Some modifications at thermo specie level
      affecting mostly eThermo. hThermo mostly unaffected
      
      New chtMultiRegionTwoPhaseEulerFoam solver for quenching and tutorial.
      
      Phases sub-models for reactingTwoPhaseEuler and reactingMultiphaseEuler were moved
      to src/phaseSystemModels/reactingEulerFoam in order to be used by BC for
      chtMultiRegionTwoPhaseEulerFoam.
      
      Update of interCondensatingEvaporatingFoam solver.
      8170f2ad
  4. 06 Feb, 2019 1 commit
  5. 07 Jan, 2019 1 commit
  6. 09 Jan, 2019 1 commit
  7. 12 Oct, 2018 1 commit
    • Mark Olesen's avatar
      ENH: avoid readScalar, readLabel etc from dictionary (#762, #1033) · 8eddcc07
      Mark Olesen authored
      - use the dictionary 'get' methods instead of readScalar for
        additional checking
      
           Unchecked:  readScalar(dict.lookup("key"));
           Checked:    dict.get<scalar>("key");
      
      - In templated classes that also inherit from a dictionary, an additional
        'template' keyword will be required. Eg,
      
           this->coeffsDict().template get<scalar>("key");
      
        For this common use case, the predefined getXXX shortcuts may be
        useful. Eg,
      
           this->coeffsDict().getScalar("key");
      8eddcc07
  8. 16 Mar, 2018 1 commit
    • Mark Olesen's avatar
      STYLE: more consistent use of dimensioned Zero · 2f86cdc7
      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,
      
            dimensionedScalar(dims)
      
        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
        regIOobject).
      2f86cdc7
  9. 23 Nov, 2017 1 commit
    • Will Bainbridge's avatar
      ENH: combustionModels: Changed the construction order · 22aae281
      Will Bainbridge authored
      The combustion and chemistry models no longer select and own the
      thermodynamic model; they hold a reference instead. The construction of
      the combustion and chemistry models has been changed to require a
      reference to the thermodyanmics, rather than the mesh and a phase name.
      
      At the solver-level the thermo, turbulence and combustion models are now
      selected in sequence. The cyclic dependency between the three models has
      been resolved, and the raw-pointer based post-construction step for the
      combustion model has been removed.
      
      The old solver-level construction sequence (typically in createFields.H)
      was as follows:
      
          autoPtr<combustionModels::psiCombustionModel> combustion
          (
              combustionModels::psiCombustionModel::New(mesh)
          );
      
          psiReactionThermo& thermo = combustion->thermo();
      
          // Create rho, U, phi, etc...
      
          autoPtr<compressible::turbulenceModel> turbulence
          (
              compressible::turbulenceModel::New(rho, U, phi, thermo)
          );
      
          combustion->setTurbulence(*turbulence);
      
      The new sequence is:
      
          autoPtr<psiReactionThermo> thermo(psiReactionThermo::New(mesh));
      
          // Create rho, U, phi, etc...
      
          autoPtr<compressible::turbulenceModel> turbulence
          (
              compressible::turbulenceModel::New(rho, U, phi, *thermo)
          );
      
          autoPtr<combustionModels::psiCombustionModel> combustion
          (
              combustionModels::psiCombustionModel::New(*thermo, *turbulence)
          );
      
      ENH: combustionModel, chemistryModel: Simplified model selection
      
      The combustion and chemistry model selection has been simplified so
      that the user does not have to specify the form of the thermodynamics.
      
      Examples of new combustion and chemistry entries are as follows:
      
          In constant/combustionProperties:
      
              combustionModel PaSR;
      
              combustionModel FSD;
      
          In constant/chemistryProperties:
      
              chemistryType
              {
                  solver          ode;
                  method          TDAC;
              }
      
      All the angle bracket parts of the model names (e.g.,
      <psiThermoCombustion,gasHThermoPhysics>) have been removed as well as
      the chemistryThermo entry.
      
      The changes are mostly backward compatible. Only support for the
      angle bracket form of chemistry solver names has been removed. Warnings
      will print if some of the old entries are used, as the parts relating to
      thermodynamics are now ignored.
      
      ENH: combustionModel, chemistryModel: Simplified model selection
      
      Updated all tutorials to the new format
      
      STYLE: combustionModel: Namespace changes
      
      Wrapped combustion model make macros in the Foam namespace and removed
      combustion model namespace from the base classes. This fixes a namespace
      specialisation bug in gcc 4.8. It is also somewhat less verbose in the
      solvers.
      
      This resolves bug report https://bugs.openfoam.org/view.php?id=2787
      
      ENH: combustionModels: Default to the "none" model
      
      When the constant/combustionProperties dictionary is missing, the solver
      will now default to the "none" model. This is consistent with how
      radiation models are selected.
      22aae281
  10. 01 Dec, 2017 1 commit
  11. 04 Jul, 2017 1 commit
  12. 22 Jun, 2017 1 commit
  13. 24 May, 2017 1 commit
  14. 27 Apr, 2017 1 commit
  15. 28 Apr, 2016 1 commit
    • 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
  16. 27 Apr, 2016 1 commit
    • Henry Weller's avatar
      GeometricField: Rationalized and simplified access to the dimensioned internal field · 4a57b9be
      Henry Weller authored
      Given that the type of the dimensioned internal field is encapsulated in
      the GeometricField class the name need not include "Field"; the type
      name is "Internal" so
      
      volScalarField::DimensionedInternalField -> volScalarField::Internal
      
      In addition to the ".dimensionedInternalField()" access function the
      simpler "()" de-reference operator is also provided to greatly simplify
      FV equation source term expressions which need not evaluate boundary
      conditions.  To demonstrate this kEpsilon.C has been updated to use
      dimensioned internal field expressions in the k and epsilon equation
      source terms.
      4a57b9be
  17. 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
  18. 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
  19. 20 Feb, 2016 1 commit
    • Henry Weller's avatar
      Boundary conditions: Added extrapolatedCalculatedFvPatchField · 99a10ece
      Henry Weller authored
      To be used instead of zeroGradientFvPatchField for temporary fields for
      which zero-gradient extrapolation is use to evaluate the boundary field
      but avoiding fields derived from temporary field using field algebra
      inheriting the zeroGradient boundary condition by the reuse of the
      temporary field storage.
      
      zeroGradientFvPatchField should not be used as the default patch field
      for any temporary fields and should be avoided for non-temporary fields
      except where it is clearly appropriate;
      extrapolatedCalculatedFvPatchField and calculatedFvPatchField are
      generally more suitable defaults depending on the manner in which the
      boundary values are specified or evaluated.
      
      The entire OpenFOAM-dev code-base has been updated following the above
      recommendations.
      
      Henry G. Weller
      CFD Direct
      99a10ece
  20. 10 Nov, 2015 1 commit
  21. 05 Nov, 2015 1 commit
  22. 01 Nov, 2015 1 commit
  23. 11 Sep, 2015 1 commit
  24. 29 Apr, 2015 2 commits
  25. 12 Feb, 2015 1 commit
  26. 30 Oct, 2013 1 commit
  27. 25 Oct, 2013 1 commit
  28. 04 Oct, 2013 1 commit