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/)
-   -   Compiled library vs. inInclude Files, DSMC solver crashes after run (http://www.cfd-online.com/Forums/openfoam-programming-development/116031-compiled-library-vs-ininclude-files-dsmc-solver-crashes-after-run.html)

GPesch April 11, 2013 10:30

Compiled library vs. inInclude Files, DSMC solver crashes after run
 
Hi Foamers,

I hope this thread is not too long - I try to describe everything as detailed as possible so that it is clear what I am doing!
I am completely new to OpenFOAM, DSMC and C++ Programming. I am writing my master thesis and I need to perform some simulation with the DSMC solver of OpenFOAM.
My predecessor applied some changes to the DSMC library so that a VariableSoftSphere collision model is included. I received the new library source files (the complete src/lagrangian/dsmc folder from OF version 2.0.1) from him and wanted to include them into my personal, newer version of OpenFOAM (2.1.1.).
I dont want to override my original library so I compiled the new library with "wmake -libso" as "lib_mydsmc".

I did this by changing the last line of the "files" file in the make folder reads:

"LIB = $(FOAM_USER_LIBBIN)/libmy_dsmc"

Everything else I left unchanged, because as far as I understood these are the other libraries (options file) and source files (files file) which are needed in order to compile the library, right?

Okay, so in order to have a solver which uses the NEW library and not the old one, I thought I recompile the dsmcFoam solver, but applied some changes first, so that it is linked to the new library (I called my new dsmcFoam solver dsmcReactionFoam, because at the end I want to change it in a way that it can simulate chemical Reactions):

"files":
Code:

dsmcReactionFoam.C

EXE = $(FOAM_USER_APPBIN)/dsmcReactionFoam

"options":
Code:

EXE_INC = \
    -I$(LIB_SRC)/finiteVolume/lnInclude \
    -I$(LIB_SRC)/lagrangian/basic/lnInclude \
    -I$(WM_PROJECT_USER_DIR)/src/lagrangian/dsmc/lnInclude \
    -I$(LIB_SRC)/meshTools/lnInclude

EXE_LIBS = \
    -L$(FOAM_USER_LIBBIN)\
    -lmeshTools \
    -lfiniteVolume \
    -llagrangian \
    -lmy_dsmc

Afterwards I compiled it with wmake, which worked perfectly!
Okay, 2 questions:

1.
Why do I need to tell wmake where to find the header files of my dsmc library source if I link the solver to the very same compiled library anyway? That seems to be redundant? What I mean is in "EXE_INC" I tell wmake that the header files are in
" -I$(WM_PROJECT_USER_DIR)/src/lagrangian/dsmc/lnInclude \"
and then I say he should also link to "my_dsmc" in "EXE_LIBS"... Am I misunderstanding something?

2.
Is the procedure correct so far?

I ask the second question because if I run a case file with dsmcReactionFoam everything works perfectly fine.. BUT, when the simulation is finished the solver crashes with the following error:

Code:

*** glibc detected *** dsmcReactionFoam: double free or corruption (!prev): 0x0000000004870250 ***
======= Backtrace: =========
/lib/libc.so.6(+0x78bb6)[0x7ff2ac56cbb6]
/lib/libc.so.6(cfree+0x73)[0x7ff2ac573483]
dsmcReactionFoam(_ZN4Foam4wordD1Ev+0x39)[0x43ce89]
/lib/libc.so.6(__cxa_finalize+0xa0)[0x7ff2ac52d6e0]
/home/pesch/OpenFOAM/pesch-2.1.1/platforms/linux64GccDPOpt/lib/libmy_dsmc.so(+0xc946)[0x7ff2ad986946]

Frankly speaking, I have no idea what that means :)


Sorry if my questions are a little bit stupid or something, but anyways, I would be so happy if anybody would like to answer.

Best wishes
Georg

wyldckat April 14, 2013 09:31

Greetings Georg and welcome to the forum!

I started reading your post and I had a déjà-vu... but after looking for what I was vaguely remembering, I found this thread: http://www.cfd-online.com/Forums/ope...ion-fault.html
I think it addresses part of the problems your having.

To answer your questions:
  1. I'll try to translate this to a real world issue (but not 100% real...):
    • If I were to tell you that a cookie jar is in the kitchen, would you know which specific cookie jar to look for?
    • Specially if there are tons of different cookie jars in said kitchen? ;)
    This is basically what happens in a lot of OpenFOAM's code (or many other C++ codes): you have a definition of a generic "cookie jar", from which several variants derive from it, such as jars for: soft cookies, hard cookies, butter cookies, etc... (sorry, it's lunch time and I haven't lunched yet :rolleyes:)
    1. Therefore, in the header paths section "EXE_INC" you indicate where to look for header files (usually for the files "*.H") and in "EXE_LIBS" you indicate which libraries to link to.
  2. The procedure seems perfect. But you better check if an entry "libs (" is present in your case's file "system/controlDict", because it might be forcefully loading other libraries that go into conflict with your own ones.
    1. In addition, check that you are running the correct binary:
      Code:

      which dsmcReactionFoam
      And if it's linking to the correct libraries:
      Code:

      ldd dsmcReactionFoam
    2. The other thread should give some more hints on this topic.
Best regards,
Bruno

GPesch April 14, 2013 13:08

Hey Bruno, thank you so much for your very succint and useful answer and for the link to the other thread.
Basically, if I'm understanding you right in the other thread - I have an object overload leading to my error because of the functions {...} part in the controlDict file? Will it make any difference if I comment these lines out - I mean apart from that my error might disappear will I have any restraints in functionality?
Whats the use of these section?
A "libs (" part is btw not present my any controlDict that I checked.

wyldckat April 14, 2013 13:15

Hi Georg,

The "functions" part in "system/controlDict" are only used for post-processing. They should not affect the solver/solution itself... or at least I don't think it should.

Are you able to isolate which function object is triggering the object overload? Because by knowing which one to look for, we should be able to find out what can be done to avoid this problem. Probably the library/function object will have to be cloned as well and hard-code it to link to your own DSMC library :D

Best regards,
Bruno

GPesch April 14, 2013 13:42

Hi Bruno, how to find that out? Trail and error? Comment one out and check again?

wyldckat April 14, 2013 13:59

Quote:

Originally Posted by GPesch (Post 420479)
Hi Bruno, how to find that out? Trail and error? Comment one out and check again?

Yep, exactly. Trial and error... the good old "divide and conquer" strategy :cool:

GPesch April 15, 2013 10:07

Alright, this is how the functions part in my controlDict file looks like:

Code:

functions
{
    dsmcFields1
    {
        type            dsmcFields;
        functionObjectLibs ( "libutilityFunctionObjects.so" );
        enabled        true;
        outputControl  outputTime;
    }

   
    fieldAverage1
    {
        type            fieldAverage;
        functionObjectLibs ( "libfieldFunctionObjects.so" );
        outputControl  outputTime;
        resetOnOutput  off;

        fields
        (
            rhoN
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            rhoM
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            dsmcRhoN
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            momentum
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            linearKE
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            internalE
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            iDof
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            q
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
            fD
            {
                mean        on;
                prime2Mean  off;
                base        time;
            }
        );
    }
   

    forces1
    {
        type            forces;
        enabled        true;
        functionObjectLibs ( "libforces.so" );
        outputControl  outputTime;
        patches        ( obstacle );
        directForceDensity true;
        fDName          fDMean;
        CofR            ( 0 0 0 );
        log            on;
    }
}

I ran 3 testcase in which I always commented out one of them.

1.) If I erase "dsmcFields1" the case is calculated without any errors.

2.) If I erase "fieldsAverage1" I receive the the following error:

Code:

--> FOAM FATAL ERROR:

    request for volScalarField rhoNMean from objectRegistry region0 failed
    available objects of type volScalarField are

9
(
boundaryT
internalE
rhoN
dsmcSigmaTcRMax
iDof
dsmcRhoN
q
linearKE
rhoM
)


    From function objectRegistry::lookupObject<Type>(const word&) const
    in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 131.

So this seems to be very important :)

Finally if I comment out forces1 it crashes with the same error as I posted originally at the beginning but doesn't calculate the forces1.dat file (which is full of (0 0 0) anyway.... )

So I guess the solver crash at the end of the calculation is somehow caused by the function dsmcFields1 ....
Can you give me any hints on what that means?

Thank you so much for your time!

Georg

wyldckat April 17, 2013 16:36

Hi Georg,

I knew one of the functions objects had to be the guilty party :D And fortunately, it's the one that is almost screaming at us saying:
Quote:

I did, it was me who crashed you all, hahaha
OK, so let me explain - we have this entry:
Code:

    dsmcFields1
    {
        type            dsmcFields;
        functionObjectLibs ( "libutilityFunctionObjects.so" );
        enabled        true;
        outputControl  outputTime;
    }

It's telling us that the library "libutilityFunctionObjects.so" has the ability to perform the "dsmcFields" operations. This explicitly means that this library needs at some point to link to the main "dsmc" library. But in your case, you have your own "dsmc" library doing its own thing... problem is, that it's doing with the same exact object names, therefore leading to a very nasty object killing... er, "freeing", because the objects of the same name, have different sizes and are in different places.

The solution: find the source code for this function object library, clone it, rename it and adapt as you've done to the other library and application, and tell it to link to your own "dsmc" library.
Then on the "controlDict" file, reference your version of this library. And don't forget: you can no longer reference the original ones, unless you want to see these crashes again ;)

As for figuring out where is the source code for this library, try this command:
Code:

find $FOAM_SRC -name "files" | xargs grep -sl "utilityFunctionObjects"
Best regards,
Bruno

GPesch April 18, 2013 07:17

Hi Bruno,

thank you very much. That was pretty revealing!
Everything works fine now!:cool:

Best regards
Georg


All times are GMT -4. The time now is 05:01.