- add a '-SPDP' option

- remove the '-archOption' for forcing a '-m32' build on 64-bit
  architecture, which is now considered too obscure.
  Must edit files manually if this option is really required.

- now only needed when specify compiling -m32 on a 64-bit system.

  Internally use the __SIZEOF_LONG__ compiler macro (gcc, icc, llvm)
  to define when long is actually an int32_t.

- relocated BuildIssues.txt -> doc/BuildIssues.md

- enable by default on Windows, disable by default on non-Windows.

Sergio Ferraris authored 5 years ago and Andrew Heather committed 5 years ago

Integration of VOF MULES new interfaces. Update of VOF solvers and all instances
of MULES in the code.
Integration of reactingTwoPhaseEuler and reactingMultiphaseEuler solvers and sub-models
Updating reactingEuler tutorials accordingly (most of them tested)

New eRefConst thermo used in tutorials. Some modifications at thermo specie level
affecting mostly eThermo. hThermo mostly unaffected

New chtMultiRegionTwoPhaseEulerFoam solver for quenching and tutorial.

Phases sub-models for reactingTwoPhaseEuler and reactingMultiphaseEuler were moved
to src/phaseSystemModels/reactingEulerFoam in order to be used by BC for
chtMultiRegionTwoPhaseEulerFoam.

Update of interCondensatingEvaporatingFoam solver.

- in case an individual geometry element has render issues in parallel

- additional debug information

- can be used for outputing sampled surfaces in x3d format for direct
  import in other rendering tools.

- this corresponds more closely to the expected behaviour of a
  patch-average value being independent of the local face
  discretization

- for codedFunctionObject and CodedSource the main code snippets
  were not included in the SHA1 calculation, which meant that many
  changes would not be noticed and no new library would be compiled.

  As a workaround, a dummy 'code' entry could be used solely for the
  purposes of generating a SHA1, but this is easily forgotten.

  We now allow tracking of the dynamicCodeContext for the coded
  objects and append to the SHA1 hasher with specific entries.
  This should solve the previous misbehaviour.

  We additionally add information about the ordering of the code
  sections. Suppose we have a coded function object (all code
  segments are optional) with the following:

      codeExecute "";
      codeWrite   #{ Info<< "Called\n"; #};

  which we subsequently change to this:

      codeExecute #{ Info<< "Called\n"; #};
      codeWrite   "";

  If the code strings are simply concatenated together, the SHA1 hashes
  will be identical....

- fix typo in makefiles/info that affected wmake -show-compile-c

- additional safeguard in src/OpenFOAM/Make/options against self-linking.
  This is not normally required unless PROJECT_LIBS has been added into
  the link stage.

- with the changes added in #1256 and corresponding updates to
  ThirdParty we can stop exporting these variables:

  WM_CC WM_CFLAGS WM_CXX WM_CXXFLAGS WM_LDFLAGS

solaris:
  - rename WM_ARCH from SunOS to solaris64 for consistency with wmake/rules
  - drop non-64 solaris from wmake/rules
  - remove automatic selection of FJMPI. This should be done in the bashrc
    or prefs.sh file instead.
  - remove old (likely inaccurate) exported flags, rely on wmake -show-xyz
    or user config instead

darwin:
  - remove '-Ddarwin' from the exported WM_CFLAGS, WM_CXXFLAGS.
    Not used elsewhere (ThirdParty)

- still had old WM_PROJECT_VERSION settings instead of FOAM_API
  for FOAM_SITE_APPBIN and FOAM_SITE_LIBBIN locations.

- 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
  itself.

    InfoSwitches
    {
        // 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.

- While a rectilinear mesh can be created with blockMesh, not every mesh
  created with blockMesh will satisfy the requirements for being a
  rectilinear mesh.

  This alternative to blockMesh uses a single block that is aligned
  with the xy-z directions and specifications of the control points,
  mesh divisions and expansion ratios. For example,

    x
    {
        points  ( -13.28 -0.10 6.0 19.19 );
        nCells  (  10  12 10 );
        ratios  ( 0.2   1  5 );
    }

    y { ... }
    z { ... }

  With only one block, the boundary patch definition is simple and the
  canonical face number is used directly. For example,

    inlet
    {
        type    patch;
        faces   ( 0 );
    }
    outlet
    {
        type    patch;
        faces   ( 1 );
    }

    sides
    {
        type    patch;
        faces   ( 2 3 );
    }

    ...

- After a mesh is defined, it is trivial to retrieve mesh-related
  information such as cell-volume, cell-centres for any i-j-k location
  without an actual polyMesh.

STYLE: remove -noFunctionObjects from blockMesh

- no time loop, so function objects cannot be triggered anyhow.

- seems to have slipped into an earlier commit

- 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
  other.

- 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.

mattijs authored 6 years ago and Mark OLESEN committed 6 years ago

- add vsmall pTraits for scalars
- report the solve scalar in buildArch information

- can be used to check the validity of input values.

Example:

    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

- 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

- was WM_PROJECT_API in the environment and FOAM_API in dictionaries.

  Make these both consistently FOAM_API.
  This is a non-breaking change, since the value of WM_PROJECT_API
  (added in 1812) and/or FOAM_API is purely informative.
  For the current correct values, always use

    * foamEtcFile -show-api
    * wmakeBuildInfo -show-api

- If using a non-clang compiler suite (gcc, intel, etc) the additional
  lbraries required for mesa with llvm pipelines may not be found.

  Provide a mesa_llvm configuration with in the 'vtk' config file.
  Can use the usual types of settings

     * mesa_llvm=llvm-4.0.1
     * mesa_llvm=none
     * mesa_llvm=system

- uses the value of foamVersion::api, which should be reliable.