1. 09 Jul, 2019 1 commit
  2. 26 Jun, 2019 1 commit
  3. 13 Jun, 2019 1 commit
  4. 22 May, 2019 1 commit
    • Mark Olesen's avatar
      ENH: dictionary checking methods with predicates on the input values · e3d91a11
      Mark Olesen authored
      - can be used to check the validity of input values.
          dict.getCheck<label>("nIters", greaterOp1<label>(0));
          dict.getCheck<scalar>("relax", scalarMinMax::zero_one());
      - use 'get' prefix for more regular dictionary methods.
        Eg, getOrDefault() as alternative to lookupOrDefault()
      - additional ops for convenient construction of predicates
      ENH: make dictionary writeOptionalEntries integer
      - allow triggering of Fatal if default values are used
      ENH: additional scalarRange static methods: ge0, gt0, zero_one
      - use GREAT instead of VGREAT for internal placeholders
      - additional MinMax static methods: gt, le
  5. 21 May, 2019 1 commit
  6. 05 Apr, 2019 1 commit
    • Mark Olesen's avatar
      ENH: allow space char in fileName is now configurable (#1008) · 28b137f8
      Mark Olesen authored
      - having whitespace in fileName can be somewhat fragile since it means
        that the fileName components do not necessarily correspond to a
        'Foam::word'. But in many cases it will work provided that spaces
        are not present in the final portion of the simulation directory
              // Allow space character in fileName (use with caution)
              allowSpaceInFileName    0;
      - now use doClean=true as default for fileName::validate(). Was false.
        Unlike fileName::clean() this requires no internal string rewrite
        since the characters are being copied.  Also handle any path
        separator transformations (ie, backslash => forward slash) at the
        same time. This makes it resemble the std::filesystem a bit more.
  7. 20 Feb, 2019 1 commit
    • Mark Olesen's avatar
      ENH: extended runTimePostProcessing (#1206) · 9e312617
      Mark Olesen authored
      - Extended runTimePostProcessing to include access to "live"
        simulation objects such a geometry patches and sampled surfaces
        stored on the "functionObjectObjects" registry.
      - Add 'live' runTimePostProcessing of cloud data.
        Extracts position and fields from the cloud via its objectRegistry writer
      - For the "live" simulation objects, there are two new volume filters
        that work directly with the OpenFOAM volume fields:
            * iso-surface
            * cutting planes
        Both use the VTK algorithms directly and support multiple values.
        Eg, can make multiple iso-levels or multiple planes parallel to each
      - When VTK has been compiled with MPI-support, parallel rendering will
        be used.
      - Additional title text properties (shadow, italic etc)
      - Simplified handling of scalar-bar and visibility switches
      - Support multiple text positions. Eg, for adding watermark text.
  8. 15 Feb, 2019 1 commit
  9. 14 Feb, 2019 1 commit
  10. 24 Jan, 2019 1 commit
  11. 20 Dec, 2018 1 commit
  12. 18 Oct, 2018 1 commit
  13. 15 Oct, 2018 1 commit
    • Mark Olesen's avatar
      ENH: make cwd() behaviour user-adjustable (issue #1007) · b7054272
      Mark Olesen authored
      - with the 'cwd' optimization switch it is possible to select the
        preferred behaviour for the cwd() function.
        A value of 0 causes cwd() to return the physical directory,
        which is what getcwd() and `pwd -P` return.
        Until now, this was always the standard behaviour.
        With a value of 1, cwd() instead returns the logical directory,
        which what $PWD contains and `pwd -L` returns.
        If any of the sanity checks fail (eg, PWD points to something other
        than ".", etc), a warning is emitted and the physical cwd() is
        returned instead.
        Apart from the optical difference in the output, this additional
        control helps workaround file systems with whitespace or other
        characters in the directory that normally cause OpenFOAM to balk.
        Using a cleaner symlink elsewhere should skirt this issue.
            cd $HOME
            ln -s "/mounted volume/user/workdir"  workdir
            cd workdir
            # start working with OpenFOAM
  14. 05 Oct, 2018 1 commit
    • Mark Olesen's avatar
      ENH: improve, simplify, rationalize coordinate system handling (issue #863) · c75d5118
      Mark Olesen authored
      Previously the coordinate system functionality was split between
      coordinateSystem and coordinateRotation. The coordinateRotation stored
      the rotation tensor and handled all tensor transformations.
      The functionality has now been revised and consolidated into the
      coordinateSystem classes. The sole purpose of coordinateRotation
      is now just to provide a selectable mechanism of how to define the
      rotation tensor (eg, axis-angle, euler angles, local axes) for user
      input, but after providing the appropriate rotation tensor it has
      no further influence on the transformations.
      The coordinateSystem class now contains an origin and a base rotation
      tensor directly and various transformation methods.
        - The origin represents the "shift" for a local coordinate system.
        - The base rotation tensor represents the "tilt" or orientation
          of the local coordinate system in general (eg, for mapping
          positions), but may require position-dependent tensors when
          transforming vectors and tensors.
      For some coordinate systems (currently the cylindrical coordinate system),
      the rotation tensor required for rotating a vector or tensor is
      The new coordinateSystem and its derivates (cartesian, cylindrical,
      indirect) now provide a uniform() method to define if the rotation
      tensor is position dependent/independent.
      The coordinateSystem transform and invTransform methods are now
      available in two-parameter forms for obtaining position-dependent
      rotation tensors. Eg,
            ... = cs.transform(globalPt, someVector);
      In some cases it can be useful to use query uniform() to avoid
      storage of redundant values.
            if (cs.uniform())
                vector xx = cs.transform(someVector);
                List<vector> xx = cs.transform(manyPoints, someVector);
      Support transform/invTransform for common data types:
         (scalar, vector, sphericalTensor, symmTensor, tensor).
        Breaking Changes
      - These changes to coordinate systems and rotations may represent
        a breaking change for existing user coding.
      - Relocating the rotation tensor into coordinateSystem itself means
        that the coordinate system 'R()' method now returns the rotation
        directly instead of the coordinateRotation. The method name 'R()'
        was chosen for consistency with other low-level entities (eg,
        The following changes will be needed in coding:
            Old:  tensor rot = cs.R().R();
            New:  tensor rot = cs.R();
            Old:  cs.R().transform(...);
            New:  cs.transform(...);
        Accessing the runTime selectable coordinateRotation
        has moved to the rotation() method:
            Old:  Info<< "Rotation input: " << cs.R() << nl;
            New:  Info<< "Rotation input: " << cs.rotation() << nl;
      - Naming consistency changes may also cause code to break.
            Old:  transformVector()
            New:  transformPrincipal()
        The old method name transformTensor() now simply becomes transform().
        New methods
      For operations requiring caching of the coordinate rotations, the
      'R()' method can be used with multiple input points:
             tensorField rots(cs.R(somePoints));
         and later
             Foam::transformList(rots, someVectors);
      The rotation() method can also be used to change the rotation tensor
      via a new coordinateRotation definition (issue #879).
      The new methods transformPoint/invTransformPoint provide
      transformations with an origin offset using Cartesian for both local
      and global points. These can be used to determine the local position
      based on the origin/rotation without interpreting it as a r-theta-z
      value, for example.
        Input format
      - Streamline dictionary input requirements
        * The default type is cartesian.
        * The default rotation type is the commonly used axes rotation
          specification (with e1/e2/3), which is assumed if the 'rotation'
          sub-dictionary does not exist.
          Compact specification:
                  origin  (0 0 0);
                  e2      (0 1 0);
                  e3      (0.5 0 0.866025);
          Full specification (also accepts the longer 'coordinateRotation'
          sub-dictionary name):
                  type    cartesian;
                  origin  (0 0 0);
                      type    axes;
                      e2      (0 1 0);
                      e3      (0.5 0 0.866025);
         This simplifies the input for many cases.
      - Additional rotation specification 'none' (an identity rotation):
                origin  (0 0 0);
                rotation { type none; }
      - Additional rotation specification 'axisAngle', which is similar
        to the -rotate-angle option for transforming points (issue #660).
        For some cases this can be more intuitive.
        For example,
                type    axisAngle;
                axis    (0 1 0);
                angle   30;
                type    axes;
                e2      (0 1 0);
                e3      (0.5 0 0.866025);
      - shorter names (or older longer names) for the coordinate rotation
           euler         EulerRotation
           starcd        STARCDRotation
           axes          axesRotation
        Coding Style
      - use Foam::coordSystem namespace for categories of coordinate systems
        (cartesian, cylindrical, indirect). This reduces potential name
        clashes and makes a clearer declaration. Eg,
            coordSystem::cartesian csys_;
        The older names (eg, cartesianCS, etc) remain available via typedefs.
      - added coordinateRotations namespace for better organization and
        reduce potential name clashes.
  15. 28 Jun, 2018 1 commit
  16. 18 Jun, 2018 1 commit
    • Andrew Heather's avatar
      BUG: Correction to commit 5a127183 · 17a8b1b8
      Andrew Heather authored
      - corrected the mass based correction and updated the misleading function
      - moved the option to the optimisation switches, e.g.:
              experimentalDdtCorr 1;
      - default remains off/no (0)
  17. 15 May, 2018 1 commit
  18. 27 Apr, 2018 1 commit
    • Mark Olesen's avatar
      ENH: make format of ExecutionTime = ... output configurable (issue #788) · b77e4888
      Mark Olesen authored
      - controlled by the the 'printExecutionFormat' InfoSwitch in
            // Style for "ExecutionTime = " output
            // - 0 = seconds (with trailing 's')
            // - 1 = day-hh:mm:ss
         ExecutionTime = 112135.2 s  ClockTime = 113017 s
         ExecutionTime = 1-07:08:55.20  ClockTime = 1-07:23:37
      - Callable via the new Time::printExecutionTime() method,
        which also helps to reduce clutter in the applications.
           Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
               << "  ClockTime = " << runTime.elapsedClockTime() << " s"
               << nl << endl;
      ENH: return elapsedClockTime() and clockTimeIncrement as double
      - previously returned as time_t, which is less portable.
  19. 24 Apr, 2018 1 commit
    • Mark Olesen's avatar
      ENH: new bitSet class and improved PackedList class (closes #751) · 430d0f62
      Mark Olesen authored
      - The bitSet class replaces the old PackedBoolList class.
        The redesign provides better block-wise access and reduced method
        calls. This helps both in cases where the bitSet may be relatively
        sparse, and in cases where advantage of contiguous operations can be
        made. This makes it easier to work with a bitSet as top-level object.
        In addition to the previously available count() method to determine
        if a bitSet is being used, now have simpler queries:
          - all()  - true if all bits in the addressable range are empty
          - any()  - true if any bits are set at all.
          - none() - true if no bits are set.
        These are faster than count() and allow early termination.
        The new test() method tests the value of a single bit position and
        returns a bool without any ambiguity caused by the return type
        (like the get() method), nor the const/non-const access (like
        operator[] has). The name corresponds to what std::bitset uses.
        The new find_first(), find_last(), find_next() methods provide a faster
        means of searching for bits that are set.
        This can be especially useful when using a bitSet to control an
        OLD (with macro):
            forAll(selected, celli)
                if (selected[celli])
                    sumVol += mesh_.cellVolumes()[celli];
        NEW (with const_iterator):
            for (const label celli : selected)
                sumVol += mesh_.cellVolumes()[celli];
            or manually
                label celli = selected.find_first();
                celli != -1;
                celli = selected.find_next()
                sumVol += mesh_.cellVolumes()[celli];
      - When marking up contiguous parts of a bitset, an interval can be
        represented more efficiently as a labelRange of start/size.
        For example,
            if (isA<processorPolyPatch>(pp))
                forAll(pp, i)
            if (isA<processorPolyPatch>(pp))
  20. 16 Apr, 2018 1 commit
    • Mark Olesen's avatar
      ENH: add alternative STL ASCII parsers · 2e38a9b8
      Mark Olesen authored
      - In addition to the traditional Flex-based parser, added a Ragel-based
        parser and a handwritten one.
        Some representative timings for reading 5874387 points (1958129 tris):
            Flex   Ragel   Manual
            5.2s   4.8s    6.7s         total reading time
            3.8s   3.4s    5.3s         without point merging
  21. 08 Jan, 2018 1 commit
    • Mark Olesen's avatar
      ENH: improve robustness of scalarRanges from string (fixes #673) · 1783150b
      Mark Olesen authored
      - now avoid Istream and token mechanism in favour of a simpler string
        parser. This makes the code clearer, smaller, robuster.
      - provide convenience ge/gt/le/lt static constructors for scalarRange
        for using bounds directly with specifying via a string parameter.
      - scalarRange, scalarRanges now follow the unary predicate pattern
        (using an operator() for testing). This allows their reuse in
        other contexts. Eg, for filtering operations:
      - remove unused scalarRanges methods that were specific to handling
        lists of time values. These were superseded by timeSelector methods
        several versions ago.
  22. 17 Dec, 2017 1 commit
  23. 11 Dec, 2017 1 commit
  24. 22 Nov, 2017 1 commit
  25. 03 Nov, 2017 1 commit
  26. 29 Sep, 2017 1 commit
    • Mark Olesen's avatar
      ENH: adjust infoSwitch to report host subscription (related to #531) · 5873cacc
      Mark Olesen authored
      - this compact form shows the subscription per host in the unsorted
        mpi order
            nProcs : 18
            Hosts  :
                (node1 6)
                (node2 8)
                (node3 4)
        This provides a succinct overview of which hosts have been
        subscribed or oversubscribed.
      - The longer list of "slave.pid" ... remains available on the
        InfoSwitch 'writeHosts'
  27. 22 Sep, 2017 2 commits
    • Andrew Heather's avatar
      ENH: Lagrangian - provided backwards compatibility for cases using the · 65a9d494
      Andrew Heather authored
      old "positions" file form
      The change to barycentric-based tracking changed the contents of the
      cloud "positions" file to a new format comprising the barycentric
      co-ordinates and other cell position-based info.  This broke
      backwards compatibility, providing no option to restart old cases
      (v1706 and earlier), and caused difficulties for dependent code, e.g.
      for post-processing utilities that could only infer the contents only
      after reading.
      The barycentric position info is now written to a file called
      "coordinates" with provision to restart old cases for which only the
      "positions" file is available. Related utilities, e.g. for parallel
      running and data conversion have been updated to be able to support both
      file types.
      To write the "positions" file by default, use set the following option
      in the InfoSwitches section of the controlDict:
          writeLagrangianPositions 1;
    • Andrew Heather's avatar
      INT: Integration of Mattijs' collocated parallel IO additions · 85f12ff5
      Andrew Heather authored
      Original commit message:
      Parallel IO: New collated file format
      When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
      mesh(es) has historically been stored in multiple files within separate
      directories for each processor.  Processor directories are named 'processorN',
      where N is the processor number.
      This commit introduces an alternative "collated" file format where the data for
      each decomposed field (and mesh) is collated into a single file, which is
      written and read on the master processor.  The files are stored in a single
      directory named 'processors'.
      The new format produces significantly fewer files - one per field, instead of N
      per field.  For large parallel cases, this avoids the restriction on the number
      of open files imposed by the operating system limits.
      The file writing can be threaded allowing the simulation to continue running
      while the data is being written to file.  NFS (Network File System) is not
      needed when using the the collated format and additionally, there is an option
      to run without NFS with the original uncollated approach, known as
      The controls for the file handling are in the OptimisationSwitches of
          //- Parallel IO file handler
          //  uncollated (default), collated or masterUncollated
          fileHandler uncollated;
          //- collated: thread buffer size for queued file writes.
          //  If set to 0 or not sufficient for the file size threading is not used.
          //  Default: 2e9
          maxThreadFileBufferSize 2e9;
          //- masterUncollated: non-blocking buffer size.
          //  If the file exceeds this buffer size scheduled transfer is used.
          //  Default: 2e9
          maxMasterFileBufferSize 2e9;
      When using the collated file handling, memory is allocated for the data in the
      thread.  maxThreadFileBufferSize sets the maximum size of memory in bytes that
      is allocated.  If the data exceeds this size, the write does not use threading.
      When using the masterUncollated file handling, non-blocking MPI communication
      requires a sufficiently large memory buffer on the master node.
      maxMasterFileBufferSize sets the maximum size in bytes of the buffer.  If the
      data exceeds this size, the system uses scheduled communication.
      The installation defaults for the fileHandler choice, maxThreadFileBufferSize
      and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
      the case controlDict file, like other parameters.  Additionally the fileHandler
      can be set by:
      - the "-fileHandler" command line argument;
      - a FOAM_FILEHANDLER environment variable.
      A foamFormatConvert utility allows users to convert files between the collated
      and uncollated formats, e.g.
          mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
      An example case demonstrating the file handling methods is provided in:
      The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
  28. 14 Jul, 2017 2 commits
  29. 06 Jul, 2017 2 commits
  30. 28 Jun, 2017 1 commit
  31. 19 Apr, 2017 2 commits
  32. 08 Apr, 2017 1 commit
    • Henry Weller's avatar
      externalWallHeatFluxTemperatureFvPatchScalarField: Added "power" heat source option · e72e7c56
      Henry Weller authored
      by combining with and rationalizing functionality from
      externalWallHeatFluxTemperatureFvPatchScalarField now replaces
      turbulentHeatFluxTemperatureFvPatchScalarField which is no longer needed and has
      been removed.
          This boundary condition applies a heat flux condition to temperature
          on an external wall in one of three modes:
            - fixed power: supply Q
            - fixed heat flux: supply q
            - fixed heat transfer coefficient: supply h and Ta
              Q  | Power [W]
              q  | Heat flux [W/m^2]
              h  | Heat transfer coefficient [W/m^2/K]
              Ta | Ambient temperature [K]
          For heat transfer coefficient mode optional thin thermal layer resistances
          can be specified through thicknessLayers and kappaLayers entries.
          The thermal conductivity \c kappa can either be retrieved from various
          possible sources, as detailed in the class temperatureCoupledBase.
          Property     | Description                 | Required | Default value
          mode         | 'power', 'flux' or 'coefficient' | yes |
          Q            | Power [W]                   | for mode 'power'     |
          q            | Heat flux [W/m^2]           | for mode 'flux'     |
          h            | Heat transfer coefficient [W/m^2/K] | for mode 'coefficent' |
          Ta           | Ambient temperature [K]     | for mode 'coefficient' |
          thicknessLayers | Layer thicknesses [m] | no |
          kappaLayers  | Layer thermal conductivities [W/m/K] | no |
          qr           | Name of the radiative field | no | none
          qrRelaxation | Relaxation factor for radiative field | no | 1
          kappaMethod  | Inherited from temperatureCoupledBase | inherited |
          kappa        | Inherited from temperatureCoupledBase | inherited |
          Example of the boundary condition specification:
              type            externalWallHeatFluxTemperature;
              mode            coefficient;
              Ta              uniform 300.0;
              h               uniform 10.0;
              thicknessLayers (0.1 0.2 0.3 0.4);
              kappaLayers     (1 2 3 4);
              kappaMethod     fluidThermo;
              value           $internalField;
  33. 14 Dec, 2016 1 commit
  34. 09 Dec, 2016 1 commit
  35. 14 Nov, 2016 1 commit
  36. 14 Jun, 2016 1 commit