CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   OpenFOAM debugging (http://www.cfd-online.com/Forums/openfoam-programming-development/115664-openfoam-debugging.html)

fogl April 4, 2013 07:12

OpenFOAM debugging
 
I am testing my own simple chtMultiRegionFoam case. When i run the chtMultiRegionFoam solver I get an error i pasted below. I compiled the Debug OpenFoam version hoping for some more feedback about the possible errors, but the error report remained the same.

Is this the Debug error report i should get with Debug OpenFoam version? Any idea where to look for the error?

Regards, Klemen


Code:

/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.2.0                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 2.2.0
Exec  : chtMultiRegionFoam
Date  : Apr 04 2013
Time  : 12:54:07
Host  : "klemen-VirtualBox"
PID    : 7150
Case  : /home/klemen/OpenFOAM/klemen-2.2.0/run/klemen/dewarCHT2
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create fluid mesh for region nitrogen for time = 0

Create solid mesh for region tube for time = 0

*** Reading fluid mesh thermophysical properties for region nitrogen

    Adding to thermoFluid

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

#0  Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/OSspecific/POSIX/printStack.C:221
#1  Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-2.2.0/src/OSspecific/POSIX/signals/sigFpe.C:117
#2  Uninterpreted:
#3  Foam::heRhoThermo<Foam::rhoThermo, Foam::pureMixture<Foam::sutherlandTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::calculate() at ~/OpenFOAM/OpenFOAM-2.2.0/src/thermophysicalModels/basic/rhoThermo/heRhoThermo.C:82
#4  Foam::heRhoThermo<Foam::rhoThermo, Foam::pureMixture<Foam::sutherlandTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > >::heRhoThermo(Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/thermophysicalModels/basic/rhoThermo/heRhoThermo.C:119
#5  Foam::rhoThermo::addfvMeshConstructorToTable<Foam::heRhoThermo<Foam::rhoThermo, Foam::pureMixture<Foam::sutherlandTransport<Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy> > > > >::New(Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/thermophysicalModels/basic/rhoThermo/rhoThermo.H:83
#6  Foam::autoPtr<Foam::rhoThermo> Foam::basicThermo::New<Foam::rhoThermo>(Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/thermophysicalModels/basic/lnInclude/basicThermoTemplates.C:163
#7  Foam::rhoThermo::New(Foam::fvMesh const&, Foam::word const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/thermophysicalModels/basic/rhoThermo/rhoThermo.C:146
#8 
 at ~/OpenFOAM/OpenFOAM-2.2.0/applications/solvers/heatTransfer/chtMultiRegionFoam/./fluid/createFluidFields.H:31
#9  __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#10 
 in "/home/klemen/OpenFOAM/OpenFOAM-2.2.0/platforms/linuxGccDPDebug/bin/chtMultiRegionFoam"
Floating point exception (core dumped)


fogl April 4, 2013 08:14

Now i noticed one more thing. When i run the OpenFoam 2.2.0 default precompiled version installed at /opt/etc.. and test the "tutorials/heatTransfer/chtMultiRegionFoam/multiRegionHeater" everything seems to work fine - if i open the log file i can see the solver is running. But if i ran the same example with the compiled Debug OpenFoam 2.2.0 version, i get an error listed below. Should install the ThirdParty software to run those examples?

Code:

--------------------------------------------------------------------------
Sorry!  You were supposed to get help about:
    find-available:not-valid
But I couldn't open the help file:
    /home/klemen/OpenFOAM/ThirdParty-2.2.0/platforms/linuxGcc/openmpi-1.6.3/share/openmpi/help-mca-base.txt: No such file or directory.  Sorry!
--------------------------------------------------------------------------
[klemen-VirtualBox:09274] *** Process received signal ***
[klemen-VirtualBox:09274] Signal: Segmentation fault (11)
[klemen-VirtualBox:09274] Signal code: Address not mapped (1)
[klemen-VirtualBox:09274] Failing at address: 0x14
[klemen-VirtualBox:09274] [ 0] [0xdd140c]
[klemen-VirtualBox:09274] [ 1] /usr/lib/libopen-pal.so.0(mca_base_select+0x135) [0xa8c9e5]
[klemen-VirtualBox:09274] [ 2] /usr/lib/libopen-pal.so.0(opal_crs_base_select+0xae) [0xa9fc0e]
[klemen-VirtualBox:09274] [ 3] /usr/lib/libopen-pal.so.0(opal_cr_init+0x415) [0xa7bfd5]
[klemen-VirtualBox:09274] [ 4] /usr/lib/libopen-pal.so.0(opal_init+0x15b) [0xa7b77b]
[klemen-VirtualBox:09274] [ 5] /usr/lib/libopen-rte.so.0(orte_init+0x4d) [0xd476cd]
[klemen-VirtualBox:09274] [ 6] mpirun() [0x804a3c1]
[klemen-VirtualBox:09274] [ 7] mpirun() [0x8049f4f]
[klemen-VirtualBox:09274] [ 8] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x3d54d3]
[klemen-VirtualBox:09274] [ 9] mpirun() [0x8049ea1]
[klemen-VirtualBox:09274] *** End of error message ***


wyldckat April 6, 2013 08:00

Greetings Klemen,

Let me answer to one post at a time :):
Best regards,
Bruno

fogl April 16, 2013 05:46

Thank you for the reply. I tested the debug version once again, and now i get some more feedback - i issume the nomber at the end of error message represents the code line number? I checked that line, but this did not help me much. Any idea what could be the problem with my simulation. The simulation runs for some time and then stops, reporting the errors below. I am testing a simple chtMultiRegionFoam example. I uploaded my configuration: http://www.speedyshare.com/SS28g/CHTtest.tar.gz



--- DEBUG MODE ----
#0 Foam::error::printStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/OSspecific/POSIX/printStack.C:221
#1 Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-2.2.0/src/OSspecific/POSIX/signals/sigFpe.C:117
#2 Uninterpreted:
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverScale.C:56
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverSolve.C:297
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverSolve.C:99
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/finiteVolume/fvMatrices/fvScalarMatrix/fvScalarMatrix.C:164
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-2.2.0/src/finiteVolume/lnInclude/fvMatrixSolve.C:81
#8
at ~/OpenFOAM/OpenFOAM-2.2.0/applications/solvers/heatTransfer/chtMultiRegionFoam/./fluid/pEqn.H:61
#9 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#10
in "/home/klemen/OpenFOAM/OpenFOAM-2.2.0/platforms/linuxGccDPDebug/bin/chtMultiRegionFoam"
Floating point exception (core dumped)

--- same, but NO DEBUG ---
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2 Uninterpreted:
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) in "/opt/openfoam220/platforms/linuxGccDPOpt/lib/libfiniteVolume.so"
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/openfoam220/platforms/linuxGccDPOpt/bin/chtMultiRegionFoam"
#8
in "/opt/openfoam220/platforms/linuxGccDPOpt/bin/chtMultiRegionFoam"
#9 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#10
in "/opt/openfoam220/platforms/linuxGccDPOpt/bin/chtMultiRegionFoam"
Floating point exception (core dumped)

wyldckat April 17, 2013 16:27

Hi Klemen,

Quote:

i issume the nomber at the end of error message represents the code line number? I checked that line, but this did not help me much.
Well, the idea is that it tells you where to look at during runtime.
Sometimes looking at where it crashed gives the information you need to know, but other times you have to go up into the previous function calls and look at how the variables are right before it crashes/crashed.

I thought that in those links I posted, I had mentioned gdbOF... apparently I didn't, so here it is: http://openfoamwiki.net/index.php/Contrib_gdbOF - this can help you to use GDB to ascertain what the variables had at the time of the crash.
Eclipse is another one that might help: http://openfoamwiki.net/index.php/Ho...M_with_Eclipse


But other times, the solution is to step back and look at the formulation of your changes to the source code and case. So, a little explanation of what you're trying to do would make it easier to help you...
In addition, the error messages you gave in the first post are rather different from these latest ones you've posted about...

Best regards,
Bruno

fogl April 18, 2013 07:02

Thank you Bruno,
I am not making any changes to the source code (yet). I am just testing a simple case of cold nitrogen flow through a round tube.

The error message I pasted above was different, i think that the solver did not even start. Then i did some changes to BC and now the solver start and than stops after some time. I thought that debugging the case will lead me to to the source of error - isn't this the way it should be done? BTW, I plotted the solution using paraFoam, but i could not find the cause of problem.

Regards,
Klemen

wyldckat April 18, 2013 16:58

Hi Klemen,

Debugging gets us closer to the reason of why it crashes, because OpenFOAM currently doesn't have a smart system that simply says: "your field XYZ has a non admissible value".

OK, remember what I wrote about having to look further back into the past code? On line #8 of the stack list you have this:
Quote:

~/OpenFOAM/OpenFOAM-2.2.0/applications/solvers/heatTransfer/chtMultiRegionFoam/./fluid/pEqn.H:61
It doesn't show in the normal release (Opt) build.
If you look at this file, you'll see that it's pointing to the very last line of this snippet of source code:
Code:

            fvScalarMatrix p_rghEqn
            (
                p_rghDDtEqn
              - fvm::laplacian(rhorAUf, p_rgh)
            );

            p_rghEqn.solve
            (
                mesh.solver
                (
                    p_rgh.select
                    (
                        (
                          oCorr == nOuterCorr-1
                        && corr == nCorr-1
                        && nonOrth == nNonOrthCorr
                        )
                    )
                )
            );

This seems a bit confusing and it's the first time I see/notice an equation being solved in this particular way.

So, what happens is something like this:
  1. The first block of code defines the equation that will have to be solved.
  2. The second block solves the equation, but only depending on a certain mesh or field selection, I'm not sure.
  3. Problem is that it crashes deep inside the "GAMGSolver", which is an advanced/complex matrix solver...
  4. The ultimate reason (line #1) for the crash is the good old "sigFpe": http://en.wikipedia.org/wiki/Floatin...uracy_problems - i.e., it's probably due to a division by zero or infinite.
Looking a bit more up the source code, we see this:
Code:

        fvScalarMatrix p_rghDDtEqn
        (
            fvc::ddt(rho) + psi*correction(fvm::ddt(p_rgh))
          + fvc::div(phiHbyA)
        );

This equation is used in the one from the other block of code. The fields that might be the guilty ones - from both equations - are: "rho", "psi", "p_rgh", "phiHbyA" and "rhorAUf". Therefore, one of these guys are to blame... therefore, these fields need to be checked for values that might be problematic.
My bet is on the "p_rgh" field... you probably have values that either not allowed... look into other tutorial cases, to figure out what you might be doing wrong ;)


Best regards,
Bruno


All times are GMT -4. The time now is 11:16.