1. 19 Nov, 2019 1 commit
    • Mark Olesen's avatar
      ENH: add conditionals to #eval (string to scalar) · 9e6683f7
      Mark Olesen authored
      Example,
      
           ($radius > 10) ? sin(degToRad(45)) : cos(degToRad(30))
      
      - protect division and modulo against zero-divide.
      
      - add scanner/parser debugging switches in the namespace,
        selectable as "stringToScalar". For example,
      
          debug parser:  foamDictionary -debug-switch stringToScalar=2
          debug scanner: foamDictionary -debug-switch stringToScalar=4
          debug both:    foamDictionary -debug-switch stringToScalar=6
      9e6683f7
  2. 11 Nov, 2019 1 commit
  3. 03 Nov, 2019 1 commit
  4. 01 Oct, 2019 1 commit
  5. 28 Aug, 2019 1 commit
  6. 01 Oct, 2019 1 commit
  7. 13 Aug, 2019 2 commits
  8. 06 Aug, 2019 1 commit
  9. 24 Jul, 2019 1 commit
  10. 14 Jul, 2019 1 commit
  11. 08 Jul, 2019 1 commit
  12. 13 Jun, 2019 1 commit
  13. 31 May, 2019 1 commit
  14. 10 Apr, 2019 1 commit
  15. 03 Apr, 2019 1 commit
  16. 11 Mar, 2019 1 commit
  17. 28 Jan, 2019 1 commit
    • Mark Olesen's avatar
      ENH: enable MPI library variants (#1153) · 473e000b
      Mark Olesen authored
      - in addition to managing different vendors and versions, it may also
        be necessary or desirable to have a particular variant
        (eg, profiling, release, etc).
      
        Devise a new meaningful name for the variant and create a
        corresponding wmake rule.
      
        Eg, SYSTEMOPENMPI-profiling with a corresponding
            "wmake/rules/linux64Gcc/mplibSYSTEMOPENMPI-profiling" file
        that has suitable content for your system.
      
      CONFIG: intel-mpi use intel64/ paths only for config and wmake rules (#1153)
      
      - previously adjusted the config files, but missed the changes
        required for the wmake rules too.
      
        Now simply migrate to using  "intel64/{include,bin,lib}"
        instead of the older naming  "{include,bin,lib}64"
      
        These changes work since at least intel-mpi 2015 (5.x), but possibly
        earlier as well
      473e000b
  18. 23 Jan, 2019 1 commit
  19. 06 Feb, 2019 1 commit
  20. 13 Dec, 2018 1 commit
  21. 02 Dec, 2018 1 commit
    • Mark Olesen's avatar
      ENH: update handling of versioning and make control (issue #1010) · 6c68c34e
      Mark Olesen authored
      - Use the OPENFOAM define (eg, 1806, 1812), which normally corresponds
        to a major release, to define an API level. This remains consistent
        within a release cycle and means that it is possible to manage
        several sub-versions and continue to have a consistent lookup.
      
        The current API value is updated automatically during the build
        and cached as meta data for later use, even when the wmake/ directory
        is missing or OpenFOAM has not yet be initialized.
      
        The version information reported on program start or with -help
        usage adjusted to reflect this. The build tag from git now also
        carries the date as being more meaningful to trace than a hash
        value.
      
      - Update etc/bashrc and etc/cshrc to obtain the project directory
        directly instead of via its prefix directory. The value obtained
        corresponds to an absolute path, from which the prefix directory
        can be obtained.
      
        The combination of these changes removes the reliance on any
        particular directory naming convention.
        For example,
      
           With an 1812 version (API level):
      
           WM_PROJECT_VERSION=myVersion
      
           installed as /some/path/somewhere/openfoam-mySandbox
      
        This makes the -prefix, -foamInstall, -projectVersion, -version
        values of foamEtcFiles, and similar entries for foamConfigurePaths
        superfluous.
      
        WM_PROJECT_INST_DIR is no longer required or used
      
      ENH: improve handling and discovery of ThirdParty
      
      - improve the flexibility and reusability of ThirdParty packs to cover
        various standard use cases:
      
          1. Unpacking initial release tar files with two parallel directories
             - OpenFOAM-v1812/
             - ThirdParty-v1812/
      
          2. With an adjusted OpenFOAM directory name, for whatever reason
             - OpenFOAM-v1812-myCustom/
             - openfoam-1812-other-info/
      
          3. Operating with/without ThirdParty directory
      
        To handle these use cases, the following discovery is used.
      
        Note PROJECT = the OpenFOAM directory `$WM_PROJECT_DIR`
             PREFIX = the parent directory
             VERSION = `$WM_PROJECT_VERSION`
             API = `$WM_PROJECT_API`, as per `foamEtcFiles -show-api`
      
         0. PROJECT/ThirdParty
            - for single-directory installations
      
         1. PREFIX/ThirdParty-VERSION
            - this corresponds to the traditional approach
      
         2. PREFIX/ThirdParty-vAPI
            - allows for an updated value of VERSION (eg, v1812-myCustom)
              without requiring a renamed ThirdParty. The API value
              would still be '1812' and the original ThirdParty-v1812/
              would be found.
      
         3. PREFIX/ThirdParty-API
            - this is the same as the previous example, but using an unadorned
              API value. This also makes sense if the chosen version name also
              uses the unadorned API value in its naming
              (eg, 1812-patch190131, 1812.19W03)
      
         4. PREFIX/ThirdParty-common
            - permits maximum reuse for various versions, but only for
              experienced user who are aware of potential version
              incompatibilities
      
         Directory existence is checked as is the presence of an Allwmake file
         or a platforms/ directory. This reduces the potential of false positive
         matches and limits the selection to directories that are either
         with sources (has the Allwmake file), or pre-compiled binaries (has
         the platforms/ directory).
      
         If none of the explored directories are found to be suitable,
         it reverts to using a PROJECT/ThirdParty dummy location since
         this is within the project source tree and can be trusted to
         have no negative side-effects.
      
      ENH: add csh support to foamConfigurePaths
      
      - this removes the previously experienced inconsistence in config file
        contents.
      
      REMOVED: foamExec
      
      - was previously used when switching versions and before the
        bashrc/cshrc discovery logic was added. It is now obsolete.
      6c68c34e