CompressibleInterDyMFoam tutorial case fail to pass the test.

[NablaCFD]

Corresponding to OF-dev on CentOS worked well, but blueCFD-core-2016-1 fail to pass about at 16.4s.

As following:

/---------------------------------------------------------------------------^M
| ========= | |^M
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |^M
| \ / O peration | Version: 4.x |^M
| \ / A nd | Web: www.OpenFOAM.org |^M
| / M anipulation | |^M
---------------------------------------------------------------------------/^M
/ Windows 32 and 64 bit porting by blueCAPE: http://www.bluecape.com.pt _^M
| Based on Windows porting (2.0.x v4) by Symscape: http://www.symscape.com |^M
_---------------------------------------------------------------------------/^M
Build : 4.x-66490b6541d3^M
Exec : X:/OpenFOAM-4.x/platforms/mingw_w64GccDPInt32Opt/bin/compressibleInterDyMFoam.exe^M
Date : Sep 16 2016^M
Time : 22:46:54^M
PID : 21616^M
Case : X:/ofuser-of4/run/multiphase/compressibleInterDyMFoam/ras/sloshingTank2D^M
nProcs : 1^M
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).^M
fileModificationChecking : Monitoring run-time modified files using timeStampMaster^M
allowSystemOperations : Allowing user-supplied system call operations^M
^M
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //^M
Create time^M
^M
Create mesh for time = 0^M
^M
Selecting dynamicFvMesh solidBodyMotionFvMesh^M
Selecting solid-body motion function SDA^M
Applying solid body motion to entire mesh^M
^M
PIMPLE: Operating solver in PISO mode^M
^M
Reading field p_rgh^M
^M
Reading field U^M
^M
Reading/calculating face flux field phi^M
^M
Constructing twoPhaseMixtureTherm

...............

Courant Number mean: 0.10372 max: 0.291564^M
deltaT = 0.00833333^M
Time = 16.4083^M
^M
Execution time for mesh.update() = 0.003 s^M
PIMPLE: iteration 1^M
MULES: Solving for alpha.water^M
Liquid phase volume fraction = 0.339145 Min(alpha.water) = -1.13128e-013 Min(alpha.air) = -2.66454e-015^M
MULES: Solving for alpha.water^M
Liquid phase volume fraction = 0.339145 Min(alpha.water) = -1.09602e-013 Min(alpha.air) = -2.44249e-015^M
MULES: Solving for alpha.water^M
Liquid phase volume fraction = 0.339145 Min(alpha.water) = -1.06187e-013 Min(alpha.air) = -1.9984e-015^M
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0^M
smoothSolver: Solving for T, Initial residual = 0.0198545, Final residual = 8.37598e+121, No Iterations 1000^M
^M
^M
--> FOAM FATAL ERROR: ^M
Maximum number of iterations exceeded^M
^M
From function Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar) const) const [with Thermo = Foam::hConstThermoFoam::perfectFluid<Foam::specie >; Type = Foam::sensibleInternalEnergy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermoFoam::hConstThermo<Foam::perfectFluid<Foam::specie >, Foam::sensibleInternalEnergy>]^M
in file X:/OpenFOAM-4.x/src/thermophysicalModels/specie/thermo/thermo/thermoI.H at line 66.^M
^M
FOAM aborting^M
^M
We're sorry, but the application crashed and safe stack tracing isn't available in this current implementation of blueCFD-Core patches for OpenFOAM.^M
^M
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.^M
~

[wyldckat]

I've made a sync from OpenFOAM-4.x to blueCFD-Core-4.x a few hours ago. This error still occurs.

There are 2-3 possible reasons why it diverges and crashes on Windows but not on Linux:

1. If there is any random number being used, it's natural that there is a point in time where the results start to be different. Nonetheless, I don't expect this solver to rely on that.
2. If there are threshold-based calculations (a>b), it's fairly easy to have a borderline calculation that breaks the flow.
3. There might have been a problem with the library linking for the multiphase transport library that is used by this solver.

I'm comparing the results side-by-side to try and diagnose the origin of the problem.

[wyldckat]

I've done a quick comparison of the results on Linux versus Windows, for the same OpenFOAM 4.x commit, as mentioned in the previous comment.

When comparing the log files (I had to filter the exponent setting, more details below on how I did it after the line break), the results start being substantially different in the log file at the time step 0.068254, namely when the following values start to be different:

min(p_rgh) 980837   #Linux
min(p_rgh) 980839   #Windows

There is another important detail here, is that I used different GCC versions:

• On Linux, namely CentOS 6.7, I used GCC 4.8.5
• On Windows, used GCC 5.4.0

This may have also affected the results.

Problem is that the results in the next time step 0.0746032 are now considerably different:

min(p_rgh) 928368  # On Linux
min(p_rgh) 928558  # On Windows

In order to be able to properly diagnose where the actual problem is coming from, it's considerably difficult with this case. We'll need to create a simpler test case, although first we should check the non-dynamic mesh cases for the solver compressibleInterFoam, to see if those cases also have this problem. If they do, then it'll be easier to start diagnosing the problem, by using a simpler test cases in which it's possible to do a full dump of the results, to see where it starts changing results.

---

For comparing the log files, I filtered the 3 digit to 2 digit exponent with the following commands:

cp log.compressibleInterDyMFoam log.compressibleInterDyMFoam.2
sed -i -e 's=e\-0\([0-9][0-9]\)=e-\1=' log.compressibleInterDyMFoam.2

Then I used Meld to compare the files:

meld log.compressibleInterDyMFoam ../win/log.compressibleInterDyMFoam.2

[NablaCFD]

I may confirm this problem does not come from the difference of GCC versions.

I run on Linux, namely CentOS 7.2.1511 with OF-dev 47811eae (Sep. 14) compiled by GCC-5.4.0, at the same time I also have updated the latest blueCFD-Core-2 using "git pull" command today, and rebuid the whole codes using the GCC-5.4.0 shipped by your package. The same exact crash still took place on Win10 but not in Linux.

[NablaCFD]

Furthermore, using this case I revised system/controlDict/application from compressibleInterDyMFoam to compressibleInterFoam and added the item "div(phi, p) Gauss linear" into system/fvScheme, then tested the case using ./Allrun command, It works well and no crash happens. So this bug should possibly stem from the Dynamic Mesh Library introduced.

[wyldckat]

Thanks for testing with GCC 5.4.0 on CentOS 7.2, although please keep in mind that the results given by OpenFOAM-dev may be slightly different from the ones on OpenFOAM-4.x.

As for the latest comment, which exact tutorial case did you use? I ask this because the sloshingTank2D case does not do anything unless it is moving.

In addition, did you compare the results and the log files from Windows versus Linux?

[NablaCFD]

I understand what you said on the slight difference of OpenFOAM-dev and OpenFOAm-4.x. And I will recompile the OpenFOAM-4.x on CentOS 7.2 using GCC-5.4.0 tomorrow.

The case used test above mentioned is the sloshingTank2d case. In addition, I will make a new case test compressibleInterDyMFoam and share it with you once I have enough time to finish it, maybe it will be done in the day after tomorrow.

No, now I do not compare the results from Linux versus Win. I think the port maybe should own the function of dump errors where are come from is the key.

[NablaCFD]

I have built the OF-4.x be7fba6c on CentOS-7.2.1511 using GCC-5.4.0. and compared the log files from Win 10 versus Linux.

I found the difference of Finial residual of Temperature had exist on third timestep (Time = 0.000435749)
on linux
smoothSolver: Solving for T, Initial residual = 0.375874, Final residual = 5.66956e-11, No Iterations 2
on win
smoothSolver: Solving for T, Initial residual = 0.375874, Final residual = 5.66955e-11, No Iterations 2

[wyldckat]

I didn't comment on that difference, because those small differences in the floating point mathematical operations can always occur depending on how they are calculated on each machine and with a particular compiler/build. These issues are usually more associated to when divisions and products are done and the last few digits may be a bit different; it may get worse with random number generation, calculating the logarithm, exponential calculations, cosines and other complex operations.

In other words, even if the residuals are slightly difference, the results are still directly comparable.

My concern is regarding the time step from which the field values become considerably different. For example, look for the min(p_rgh) values that the solver output provides. This will give a clear indication that results become effectively different.

Either way, the results achieved in the tutorials that use interFoam and compressibleInterFoam are currently the more critical ones, since these have fewer degrees of complexity.