1. 16 Aug, 2016 1 commit
  2. 12 Aug, 2016 1 commit
  3. 05 Aug, 2016 1 commit
  4. 04 Aug, 2016 1 commit
  5. 01 Aug, 2016 1 commit
  6. 23 Jul, 2016 1 commit
  7. 22 Jul, 2016 2 commits
  8. 12 Jul, 2016 1 commit
  9. 24 Jun, 2016 1 commit
  10. 17 Jun, 2016 1 commit
  11. 16 Jun, 2016 1 commit
  12. 07 Jun, 2016 1 commit
  13. 04 Jun, 2016 3 commits
  14. 31 May, 2016 1 commit
  15. 30 May, 2016 1 commit
  16. 21 May, 2016 1 commit
    • Henry Weller's avatar
      Standardized the selection of required and optional fields in BCs, fvOptions, functionObjects etc. · e22c65dd
      Henry Weller authored
      In most boundary conditions, fvOptions etc. required and optional fields
      to be looked-up from the objectRegistry are selected by setting the
      keyword corresponding to the standard field name in the BC etc. to the
      appropriate name in the objectRegistry.  Usually a default is provided
      with sets the field name to the keyword name, e.g. in the
      totalPressureFvPatchScalarField the velocity is selected by setting the
      keyword 'U' to the appropriate name which defaults to 'U':
      
              Property     | Description             | Required    | Default value
              U            | velocity field name     | no          | U
              phi          | flux field name         | no          | phi
              .
              .
              .
      
      However, in some BCs and functionObjects and many fvOptions another
      convention is used in which the field name keyword is appended by 'Name'
      e.g.
      
              Property     | Description             | Required    | Default value
              pName        | pressure field name     | no          | p
              UName        | velocity field name     | no          | U
      
      This difference in convention is unnecessary and confusing, hinders code
      and dictionary reuse and complicates code maintenance.  In this commit
      the appended 'Name' is removed from the field selection keywords
      standardizing OpenFOAM on the first convention above.
      e22c65dd
  17. 18 May, 2016 1 commit
  18. 12 May, 2016 1 commit
  19. 02 May, 2016 1 commit
  20. 30 Apr, 2016 2 commits
    • Henry Weller's avatar
      GeometricField: Renamed internalField() -> primitiveField() and... · fe43b805
      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.
      fe43b805
    • Henry Weller's avatar
      GeometricField::internalField() -> GeometricField::internalFieldRef() · e1e99674
      Henry Weller authored
      Non-const access to the internal field now obtained from a specifically
      named access function consistent with the new names for non-canst access
      to the boundary field boundaryFieldRef() and dimensioned internal field
      dimensionedInternalFieldRef().
      
      See also commit a4e2afa4
      e1e99674
  21. 28 Apr, 2016 1 commit
    • Henry Weller's avatar
      GeometricField::GeometricBoundaryField -> GeometricField::Boundary · 75ea7618
      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 a25a449c
      
      This is a very simple text substitution change which can be applied to
      any code which compiles with the OpenFOAM-dev libraries.
      75ea7618
  22. 27 Apr, 2016 1 commit
    • Henry Weller's avatar
      GeometricField: Rationalized and simplified access to the dimensioned internal field · a25a449c
      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.
      a25a449c
  23. 25 Apr, 2016 2 commits
  24. 24 Apr, 2016 1 commit
  25. 23 Apr, 2016 1 commit
  26. 17 Apr, 2016 2 commits
  27. 16 Apr, 2016 1 commit
  28. 03 Apr, 2016 1 commit
    • Henry Weller's avatar
      UList: Rationalize assignment (shallow-copy vs deep-copy) · ac71f865
      Henry Weller authored
          //- Disallow default shallow-copy assignment
          //
          //  Assignment of UList<T> may need to be either shallow (copy pointer)
          //  or deep (copy elements) depending on context or the particular type
          //  of list derived from UList and it is confusing and prone to error
          //  for the default assignment to be either.  The solution is to
          //  disallow default assignment and provide separate 'shallowCopy' and
          //  'deepCopy' member functions.
          void operator=(const UList<T>&) = delete;
      
          //- Copy the pointer held by the given UList.
          inline void shallowCopy(const UList<T>&);
      
          //- Copy elements of the given UList.
          void deepCopy(const UList<T>&);
      ac71f865
  29. 02 Apr, 2016 1 commit
    • Henry Weller's avatar
      Pstream: optimisation of data exchange · 56668b24
      Henry Weller authored
      Contributed by Mattijs Janssens.
      
      1. Any non-blocking data exchange needs to know in advance the sizes to
         receive so it can size the buffer.  For "halo" exchanges this is not
         a problem since the sizes are known in advance but or all other data
         exchanges these sizes need to be exchanged in advance.
      
         This was previously done by having all processors send the sizes of data to
         send to the master and send it back such that all processors
         - had the same information
         - all could work out who was sending what to where and hence what needed to
           be received.
      
         This is now changed such that we only send the size to the
         destination processor (instead of to all as previously). This means
         that
         - the list of sizes to send is now of size nProcs v.s. nProcs*nProcs before
         - we cut out the route to the master and back by using a native MPI
           call
      
         It causes a small change to the API of exchange and PstreamBuffers -
         they now return the sizes of the local buffers only (a labelList) and
         not the sizes of the buffers on all processors (labelListList)
      
      2. Reversing the order of the way in which the sending is done when
         scattering information from the master processor to the other
         processors. This is done in a tree like fashion. Each processor has a
         set of processors to receive from/ send to. When receiving it will
         first receive from the processors with the least amount of
         sub-processors (i.e. the ones which return first). When sending it
         needs to do the opposite: start sending to the processor with the
         most amount of sub-tree since this is the critical path.
      56668b24
  30. 22 Mar, 2016 2 commits
  31. 15 Mar, 2016 1 commit
  32. 14 Mar, 2016 1 commit
  33. 29 Feb, 2016 1 commit