The solvers with fvOptions all run crash

[NablaCFD]

In tutorials directory using following command find the examples of the solvers with fvOptions.
I have tried to several cases, they all fail to run and crashed. Maybe the port of fvOptions into Win platform brought a new bug.

$ find . -name fvOptions
./compressible/rhoPimpleFoam/ras/angledDuct/constant/fvOptions
./compressible/rhoPimpleFoam/ras/angledDuctLTS/constant/fvOptions
./compressible/rhoPimpleFoam/ras/mixerVessel2D/constant/fvOptions
./compressible/rhoPorousSimpleFoam/angledDuctExplicit/constant/fvOptions
./compressible/rhoPorousSimpleFoam/angledDuctImplicit/constant/fvOptions
./compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff/constant/fvOptions
./heatTransfer/chtMultiRegionSimpleFoam/heatExchanger/constant/air/fvOptions
./heatTransfer/chtMultiRegionSimpleFoam/heatExchanger/constant/porous/fvOptions
./incompressible/pimpleFoam/channel395/constant/fvOptions
./incompressible/pisoFoam/laminar/porousBlockage/constant/fvOptions
./incompressible/simpleFoam/rotorDisk/system/fvOptions
./incompressible/simpleFoam/turbineSiting/constant/fvOptions
./lagrangian/coalChemistryFoam/simplifiedSiwek/constant/fvOptions
./lagrangian/reactingParcelFoam/filter/constant/fvOptions
./multiphase/interFoam/ras/angledDuct/constant/fvOptions
./multiphase/reactingTwoPhaseEulerFoam/laminar/injection/constant/fvOptions
./multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection/constant/fvOptions
./multiphase/twoPhaseEulerFoam/laminar/injection/constant/fvOptions

For example:
~/blueCFD/ofuser-of4/run/multiphase/twoPhaseEulerFoam/laminar/injection
$ twoPhaseEulerFoam.exe
/---------------------------------------------------------------------------
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 4.x |
| \ / A nd | Web: www.OpenFOAM.org |
| / M anipulation | |
---------------------------------------------------------------------------/
/ Windows 32 and 64 bit porting by blueCAPE: http://www.bluecape.com.pt _
| Based on Windows porting (2.0.x v4) by Symscape: http://www.symscape.com |
_---------------------------------------------------------------------------/
Build : 4.x-66490b6541d3
Exec : X:/OpenFOAM-4.x/platforms/mingw_w64GccDPInt32Opt/bin/twoPhaseEulerFoam.exe
Date : Sep 15 2016
Time : 10:42:10
PID : 13612
Case : X:/ofuser-of4/run/multiphase/twoPhaseEulerFoam/laminar/injection
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

PIMPLE: no residual control data found. Calculations will employ 3 corrector loops

Reading g

Reading hRef
Creating twoPhaseSystem

Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectGas;
specie specie;
energy sensibleInternalEnergy;
}

Calculating face flux field phi.air
Selecting diameterModel for phase air: isothermal
Selecting turbulence model type laminar
Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectFluid;
specie specie;
energy sensibleInternalEnergy;
}

Calculating face flux field phi.water
Selecting diameterModel for phase water: constant
Selecting turbulence model type laminar
Selecting default blending method: linear
Selecting aspectRatioModel for (air in water): constant
Selecting aspectRatioModel for (water in air): constant
Selecting dragModel for (air and water): segregated
Selecting swarmCorrection for (air and water): none
Selecting dragModel for (air in water): SchillerNaumann
Selecting swarmCorrection for (air in water): none
Selecting dragModel for (water in air): SchillerNaumann
Selecting swarmCorrection for (water in air): none
Selecting virtualMassModel for (air in water): constantCoefficient
Selecting virtualMassModel for (water in air): constantCoefficient
Selecting heatTransferModel for (air in water): RanzMarshall
Selecting heatTransferModel for (water in air): RanzMarshall
Calculating field g.h

Reading field p_rgh

Creating field dpdt

Creating field kinetic energy K

No MRF models present

Creating finite volume options from "constant/fvOptions"

Selecting finite volume options model type scalarSemiImplicitSource
We're sorry, but the application crashed and safe stack tracing isn't available in this current implementation of blueCFD-Core patches for OpenFOAM.

[wyldckat]

That error does not occur with the default installation of blueCFD-Core 2016-1, at least not in the machines I've tested it.

I suspect that the problem occurs in your case because of what you've reported in issue #19, namely that you used git pull to get the latest changes from the blueCFD-Core-4.x branch and then ran Allwmake.

As I've already written in issue #19, I haven't managed to find the time needed to document the steps needed for (re)building OpenFOAM on Windows with blueCFD-Core 2016-1, therefore it's only natural that things are not working as expected.

It will take me some considerable time until I'm able to write the detailed instructions.

In the meantime, you can try rebuilding the fvOptions library by running the following commands:

src
cd fvOptions
wclean all
wmake libso

Once it's finished building the fvOptions library, try again running the tutorial case(s).

If that doesn't work, it's best to do a clean re-build, by running:

foam
wcleanPlatform -current
wcleanLnIncludeAll
./Allwmake -j -k > log.make 2>&1

[wyldckat]

Note: I've written a quick wiki page which consolidates most of this information: https://github.com/blueCFD/Core/wiki/Quick-notes-on-how-to-update-build

[wyldckat]

I've finished a clean re-build and the tutorial case was simulated without any problems.

@NablaCFD: Please test let us know if any of the solutions above solved the problem in your build.

[NablaCFD]

I have finished the test.
The problem was solved through running
foam
wcleanPlatform -current
wcleanLnIncludeAll
./Allwmake -j -k > log.make 2>&1

some cases work well. But there was one exception, in the following case
~/blueCFD/ofuser-of4/run/multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection
after it run some time, the crash still appears. (on Linux OS, it work well and I have a little worried this inconsistent)
"
Time = 1

PIMPLE: iteration 1
MULES: Solving for alpha.steam
MULES: Solving for alpha.steam
MULES: Solving for alpha.steam
alpha.steam volume fraction = 0 Min(alpha1) = 0 Max(alpha1) = 0
Constructing face momentum equations
smoothSolver: Solving for e.steam, Initial residual = 0.9999938979, Final residual = 2.375193249e-016, No Iterations 1
smoothSolver: Solving for e.water, Initial residual = 0.001241604024, Final residual = 2.822537422e-007, No Iterations 1
steam min/max T 360.0000148 - 1111.686215
water min/max T 360 - 360.0023385
iDmdt.steamAndWater: min = 0, mean = 0, max = 0, integral = 0
Tf.steamAndWater: min = 360.0000148, mean = 360.0743441, max = 497.2060712
dmdt.steamAndWater: min = 0, mean = 0, max = 0, integral = 0
steam min/max T 360.0000148 - 1111.686215
water min/max T 360 - 360.0023385
DICPCG: Solving for p_rgh, Initial residual = 0.9996354274, Final residual = 6.377066769e-009, No Iterations 87
PIMPLE: iteration 2
MULES: Solving for alpha.steam
MULES: Solving for alpha.steam
MULES: Solving for alpha.steam
alpha.steam volume fraction = 0.0006746390915 Min(alpha1) = 0 Max(alpha1) = 0.4907045202
Constructing face momentum equations
smoothSolver: Solving for e.steam, Initial residual = 0.9999998734, Final residual = 4.751473581e-012, No Iterations 2
smoothSolver: Solving for e.water, Initial residual = 0.9999970224, Final residual = 1.373136036e-007, No Iterations 6
steam min/max T -902377.4834 - 577004.192
water min/max T 359.897967 - 1752.050365
iDmdt.steamAndWater: min = -16239164.64, mean = -10031.35279, max = 414240.8808, integral = -150.4702915
Tf.steamAndWater: min = -3022845.597, mean = 50538.1716, max = 57162332.37
dmdt.steamAndWater: min = -16239164.64, mean = -10031.35279, max = 414240.8808, integral = -150.4702915
steam min/max T -902377.4834 - 577004.192
water min/max T 359.897967 - 1752.050365
DICPCG: Solving for p_rgh, Initial residual = nan, Final residual = nan, No Iterations 1001
We're sorry, but the application crashed and safe stack tracing isn't available in this current implementation of blueCFD-Core patches for OpenFOAM.
"

in addition, when only re-build fvOptions the original problem still stands there.

I also note that you have written a quick notes how to update build. Thank you very much.

But another question emerges into my mind, whether this kind re-build of the whole codes need be executed at each update or revise of a snippet of code. Was this problem caused by appending version info? and how to solve it. Furthermore, how can we keep reusable of dll(Dynamic Link Libraries) of OF library just as normal window's dll (I am not sure whether the dlls of OF are just like the normal ones
. Thank you for your efforts in this direction.
Best,
Qiang

[wyldckat]

Many thanks for the feedback!

But there was one exception, in the following case ~/blueCFD/ofuser-of4/run/multiphase/reactingTwoPhaseEulerFoam/laminar/steamInjection after it run some time, the crash still appears.

Please open a new bug report here, so that this issue can be handled separately. Unfortunately I haven't managed yet to have a complete list of which tutorial cases run properly or not, so this crash was not expected. Although I tested just now on CentOS 6.7 with OpenFOAM 4.x 7dfa780c481b and the same exact crash happened for me as well. The problem might actually be that I need to sync up again blueCFD-Core-4.x with OpenFOAM 4.x.

---

But another question emerges into my mind, whether this kind re-build of the whole codes need be executed at each update or revise of a snippet of code. Was this problem caused by appending version info? and how to solve it.

Using incremental updates is something that was only recently fully sorted out in OpenFOAM itself, something which I helped fix, as you can see here: http://bugs.openfoam.org/view.php?id=2091

Either way, fixing issues #21, #2 and #3 will help with this.

---

Furthermore, how can we keep reusable of dll(Dynamic Link Libraries) of OF library just as normal window's dll (I am not sure whether the dlls of OF are just like the normal ones

It depends on the situation. If there as only a small change made in the source code for a specific library, we would only need to build that specific library. But there are other changes, for example in template classes, that all affected binaries have to be re-built as well. This is true on Linux as well.

The problem you experience in this case was related to there being too many changes being done at once, which may have resulted in not all affected libraries/applications being updated properly.

[NablaCFD]

This bug should be recently introduced by the Office Release of OF-dev, not exclusively belong to your port. So it shoud be reported to the OpenFOAM bug system. thus I will not open a new bug report here.

I have tested on (1) centos-5.5 with OF-dev 3420fe (2) centos-7.2.1511 with OF-dev 46d69e1 and (3) centos-7.2.1511 with OF-dev 47811eae (latest update in OF-dev on Sep 14). Only (1) passed the test, Others failed to pass the test, just like as reported above.

Thank you very much for your informationtive reply.

Qiang

[wyldckat]

Many thanks for testing this further! Then I'll close this bug report, since the solution is already documented in the wiki.