Skip to content
Snippets Groups Projects
  1. Dec 09, 2019
  2. Dec 06, 2019
  3. Sep 09, 2019
  4. Dec 10, 2019
    • Andrew Heather's avatar
      Merge branch 'feature-expressions' into 'develop' · 1b17784a
      Andrew Heather authored
      Feature expressions
      
      ### Summary
      
      This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
      - expression-based boundary conditions (also known as _groovy_ boundary conditions)
      - expression-based setFields (also known as _funky_ set fields)
      
      The idea of what we currently term *expressions* was pioneered by
      (Bernhard Gschaider) and is now firmly established in `swak4Foam`.
      Among other things, expressions attempt to bridge the gap between
      using standard, predefined boundary conditions and writing dedicated,
      special-purpose ones. Although part of this gap is now covered within
      OpenFOAM by using dynamically compiled user coding (eg, coded boundary
      conditions), there remains substantial areas where it can be
      significantly more convenient to have a series of predefined functions
      and expression sytax with some access to base OpenFOAM field
      functionality that enables rapid deployment of boundary conditions, or
      custom-defined `setFields` without writing code.
      A significant portion of `swak4Foam` expressions has been adapted for
      direct integration into OpenFOAM. During the integration and rewrite,
      we have tried to pare things down to a smaller subset with the aim of
      covering 90% or more of the common cases. The remaining cases are left
      to be reassessed for extending the *expressions* functionality in the
      future, but they also may be better served with other approaches (eg,
      with coded conditions) that were not available when `swak4Foam` was
      originally conceived.
      
      To the greatest extent possible, the integrated *expressions* have
      been designed to avoid name clashes with `swak` so it should remain
      possible to use the most recent versions of `swak` without problem.
      
      
      ### Risks
      
      - New functionality, so low chance of regression.
      - The scope of the functionality will be revised in the future
      
      ### Naming (for `swak4Foam` users)
      
      The following are the *expressions* correspondences to `swak`:
      
      - The `exprFixedValue` and `exprGradient` boundary conditions are
        roughly equivalent to the _groovy_ boundary conditions.
      
      - The utilities `setExprFields` and `setExprBoundaryFields` are
        roughly equivalent to the _funky_ utilities of similar name.
      
      The naming of the boundary conditions and utilities not only reflects
      the slightly different input requirements, but simultaneously seeks to
      avoid any potential name-clash with `swak4Foam` in a mixed
      environment.
      
      The names for the boundary condition dictionary entries tend be
      shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
      to serve as a small reminder that the *expressions* syntax is slightly
      different than the *groovy* equivalents. It also allows the user to
      fashion dictionary entries that are sufficient for **both** boundary
      condition variants and quickly toggle between them simply by changing
      the boundary condition `type`.
      
      See merge request !300
      1b17784a
    • Mark OLESEN's avatar
    • Mark OLESEN's avatar
      ENH: setExprFields and setExprBoundaryFields · 2923daab
      Mark OLESEN authored
      - these are the expressions equivalent of funkySetFields and
        funkySetBoundaryFields
      2923daab
    • Mark OLESEN's avatar
      ENH: boundary conditions with expressions · 749f4b5d
      Mark OLESEN authored
      749f4b5d
    • Mark OLESEN's avatar
      20589430
    • Mark OLESEN's avatar
      82a1e325
    • Mark OLESEN's avatar
      ENH: base fvMesh driver for expressions · 019fe7de
      Mark OLESEN authored
      019fe7de
    • Mark OLESEN's avatar
      ENH: more flexible naming for ensightPartCells, ensightPartFaces · 7e275838
      Mark OLESEN authored
      - make ensightParts parallel-aware when handling zones and patches
      
      STYLE: use of serial/parallel more evident in write templates
      7e275838
    • Mark OLESEN's avatar
      STYLE: avoid potential deadlock when resizing from zero-sized list · 98b79fad
      Mark OLESEN authored
      - not yet triggered by any code, but avoid anyhow
      98b79fad
  5. Dec 09, 2019
  6. Dec 03, 2019
  7. Dec 09, 2019
  8. Dec 06, 2019
    • Mark OLESEN's avatar
      ENH: improve exprResult handling · 17869747
      Mark OLESEN authored
      - some support for "uniform" bool fields. Calculating an averaged
        value for a boolField does not work very well, but we simply define
        that the field average is 'true' when more than 1/2 of its values
        are true. Not exactly true, but allows templated definitions to work
        smoothly.
      
      - additional output method writeValue().
        This outputs the single (uniform) value or the first value of the
        field.
      17869747
    • Mark OLESEN's avatar
      ENH: add ITstream append and seek methods. · 9fd696e1
      Mark OLESEN authored
      - ITstream append() would previously have used the append from the
        underlying tokenList, which leaves the tokenIndex untouched and
        renders the freshly appended tokens effectively invisible if
        interspersed with primitiveEntry::read() that itself uses tokenIndex
        when building the list.
      
        The new append() method makes this hidden ITstream bi-directionality
        easier to manage. For efficiency, we only append lists
        (not individual tokens) and support a 'lazy' resizing that allows
        the final resizing to occur later when all tokens have been appended.
      
      - The new ITstream seek() method provides a conveniently means to move
        to the end of the list or reposition to the middle.
        Using rewind() and using seek(0) are identical.
      
      ENH: added OTstream to output directly to a list of tokens
      
      ---
      
      BUG: List::newElem resized incorrectly
      
      - had a simple doubling of the List size without checking that this
        would indeed be sufficient for the requested index.
      
        Bug was not triggered since primitiveEntry was the only class using
        this call, and it added the tokens sequentially.
      9fd696e1
  9. Dec 07, 2019
  10. Dec 09, 2019
    • mattijs's avatar
      ENH: snappyHexMesh: proximity check · b7c54bc0
      mattijs authored
      This adds automatic deletion of cells inside small gaps. This is
      generally used to avoid having excessive numbers of cells in irrelevant
      areas of a geometry. It is nearly the opposite of automatic gap refinement
       - that refines cells to resolve the gap; this functionality removes cells
      to not mesh the gap.
      
      The proximity handling will remove those cells which are inside 'thin' gaps
      where 'thin' is defined as a distance of 2*'blockLevel'
      It will
      - detect surfaces which have the new 'blockLevel' specification
      - convert this to a minimum gap distance
      - detect cells which are inside this gap
      - remove these cells and add exposed faces to the nearest 'real' patch
      b7c54bc0
  11. Dec 06, 2019
  12. Dec 03, 2019
  13. Dec 06, 2019
  14. Dec 02, 2019
  15. Nov 27, 2019
  16. Nov 26, 2019