During the test run, molarDensity in /dumux/material/fluidstates/compositional.hh is called and gives back undefined values (checked with valgrind). In some cases this has been reported to cause a crash.
I could not recreate the problem on master, the test only seems to crash on the useComplexRelations branch. However, even on master there are uninitialized values, but here in the density function (Valgrind::CheckDefined(density_[phaseIdx]);).
It has something to do with the different calculation of molarDensity, you are right, but I have not spotted a mistake so far. Maybe the test is not very sensitive to strange values? For example, if I implement an if-statement in molarDensity on master that returns 1e56 instead of cases that would return 1e14, the test crashes. Vice versa on feature/useComplexRelations: the test runs successfully with lower values in molarDensity. The higher numbers are caused by the different calculation, but are they are more wrong than the high numbers on master?
Actually, it passes with debug-opts for g++5.5.0 and g++ 7.3.0, only optim.opts seems to have a problem with 7.3.0 did anyone check 5.3.1 with debug.opts?
.@scholz: The test only has a problem with optim.opts for me as well (5.3.1)
By this time I do not think that the uninitialised values cause the crash. Anyway, here is the output for testing molarDensity:
==2210== Memcheck, a memory error detector==2210== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==2210== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info==2210== Command: ./test_pengrobinson==2210== ==2210== Uninitialised byte(s) found during client check request==2210== at 0x40F8FB: bool Valgrind::CheckDefined<double>(double const&) (valgrind.hh:75)==2210== by 0x40FF13: Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> >::molarDensity(int) const (compositional.hh:201)==2210== by 0x40E303: void Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> >::assign<Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> > >(Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> > const&) (compositional.hh:308)==2210== by 0x40CAA4: main (test_pengrobinson.cc:211)==2210== Address 0x1ffefff528 is on thread 1's stack==2210== in frame #3, created by main (test_pengrobinson.cc:124)==2210== ==2210== Conditional jump or move depends on uninitialised value(s)==2210== at 0x40FF30: Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> >::molarDensity(int) const (compositional.hh:202)==2210== by 0x40E303: void Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> >::assign<Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> > >(Dumux::CompositionalFluidState<double, Dumux::FluidSystems::Spe5<double> > const&) (compositional.hh:308)==2210== by 0x40CAA4: main (test_pengrobinson.cc:211)==2210==
Then the test runs. Then:
==2259== ==2259== HEAP SUMMARY:==2259== in use at exit: 8 bytes in 1 blocks==2259== total heap usage: 28 allocs, 27 frees, 598,328 bytes allocated==2259== ==2259== LEAK SUMMARY:==2259== definitely lost: 0 bytes in 0 blocks==2259== indirectly lost: 0 bytes in 0 blocks==2259== possibly lost: 0 bytes in 0 blocks==2259== still reachable: 8 bytes in 1 blocks==2259== suppressed: 0 bytes in 0 blocks==2259== Rerun with --leak-check=full to see details of leaked memory==2259== ==2259== For counts of detected and suppressed errors, rerun with: -v==2259== Use --track-origins=yes to see where uninitialised values come from==2259== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)
MolarDensity in the beginning is called by the function assign before setMolarDensity for the phases has been called even once (expect for the oPhase, this one is initialised). Above the assign function the comment reads:
* \note If the other fluid state object is inconsistent with the * thermodynamic equilibrium, the result of this method is * undefined.``
To the crash:
The test crashes because of strange values. I have no idea where they come from and they do not cause a problem when they are not too high. I now think I know why they are lower on master compared to useComplexRelations:
spe5.hh calculates the density as averageMolarMass/molarVolume and sets it in the fluidstate. On master, the molarDensity is not calculated by spe5 but (later!) by the fluidstate compositional.hh as: density/averageMolarMass. And here I think we have a bug (is it a bug or a feature?) because sometimes the following happens:
averageMolarMass and molarVolume are both very small values (e-54). This gives a reasonable density. When the molarDensity is calculated later, the averageMolarMass is a different value (not so low) than it was when the density was calculated by the fluidsystem. So in between it must have changed. This is probably inconsistent but it saves the test because molarDensity is not e50 but e14 (or something).
On useComplexRelations spe5.hh calculates both density (averageMolarMass/molarVolume) and molarDensity (1/molarVolume) directly after each other and sets both in the fluidstate. Strange values lead to reasonable density but this time (consistently) very high molarDensity and the test crashes.