blueCFD / Core

Coordination repository for the blueCFD-Core: Issue tracking, Wiki, project webpage and miscellaneous scripts
http://bluecfd.github.io/Core
51 stars 10 forks source link

The solvers with fvOptions all run crash #20

Closed NablaCFD closed 8 years ago

NablaCFD commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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