- Dec 09, 2019
-
-
-
File writing is off by default; to activate, add to the patch interaction model coeff dictionary writeToFile yes;
-
- Dec 06, 2019
-
-
- Sep 09, 2019
-
-
- Dec 10, 2019
-
-
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
-
Mark OLESEN authored
-
Mark OLESEN authored
- these are the expressions equivalent of funkySetFields and funkySetBoundaryFields
-
Mark OLESEN authored
-
Mark OLESEN authored
-
Mark OLESEN authored
-
Mark OLESEN authored
-
Mark OLESEN authored
- make ensightParts parallel-aware when handling zones and patches STYLE: use of serial/parallel more evident in write templates
-
Mark OLESEN authored
- not yet triggered by any code, but avoid anyhow
-
- Dec 09, 2019
-
-
Mark OLESEN authored
- replace stringOps::toScalar with a more generic stringOps::evaluate method that handles scalars, vectors etc. - improve #eval to handle various mathematical operations. Previously only handled scalars. Now produce vectors, tensors etc for the entries. These tokens are streamed directly into the entry.
-
Mark OLESEN authored
-
Mark OLESEN authored
-
- Dec 03, 2019
-
-
Mark OLESEN authored
- include some specialization for zip/unzip fields
-
- Dec 09, 2019
-
-
Mark OLESEN authored
-
- Dec 06, 2019
-
-
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.
-
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.
-
- Dec 07, 2019
-
-
Mark OLESEN authored
- add functor versions of floor/ceil/round for scalar
-
Mark OLESEN authored
-
- Dec 09, 2019
-
-
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
-
- Dec 06, 2019
-
-
Mark OLESEN authored
-
Mark OLESEN authored
-
- Dec 03, 2019
-
-
Mark OLESEN authored
-
- Dec 06, 2019
-
-
Andrew Heather authored
-
Mark OLESEN authored
-
Mark OLESEN authored
Set the m4 -I include accordingly to have the folllowing: - the directory of the parser. - include/ in the top-level source tree of the current target (eg, src/finiteVolume/include-m4/ when compiling libfiniteVolume) - include/ from OpenFOAM Additional -dry-run option for makeParser, wrap-lemon for expanding m4 only. Extend m4 wrapping support to include bison as well.
-
Mark OLESEN authored
-
Mark OLESEN authored
- include the trailing newline for the "// comment" form, but also add in leading space removal. This ensure that we do not introduce odd indentation, while also eliminating lines that are solely C++ comments.
-
Mark OLESEN authored
-
Mark OLESEN authored
- output the "uniform", "nonuniform" Field entry tags as words instead of raw character strings, which can help for direct tokenization or when sending/receiving via Pstreams.
-
Mark OLESEN authored
-
Andrew Heather authored
-
- Dec 02, 2019
-
-
Mark OLESEN authored
-
Mark OLESEN authored
- The case files may contain #... comment lines - The geometry file may contain an optional "extents" entry - Properly handle element id specifications (off|assign|ignore|given). - Partially handle node id specifications (off|assign|ignore|given). Treat "given" like "ignore", since results in the lightest amount of coding and in many cases the "given" node ids are in fact 1-based contiguous values and thus no different than "ignore" for our purposes.
-
- Nov 27, 2019
-
-
mattijs authored
-
- Nov 26, 2019
-
-
Mark OLESEN authored
- previously only had 'opt<..>()' for options, but 'get<..>()' provides more similarity with dictionary methods. The 'opt<..>()' method is retained.
-