[GPesch]

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":

dsmcReactionFoam.C

EXE = $(FOAM_USER_APPBIN)/dsmcReactionFoam

"options":

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:

*** 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]

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 )
   
   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:
      

      which dsmcReactionFoam

      And if it's linking to the correct libraries:
      

      ldd dsmcReactionFoam

   2. The other thread should give some more hints on this topic.

Best regards,
Bruno

[GPesch]

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]

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

Best regards,
Bruno

[GPesch]

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

[wyldckat]

Originally Posted by GPesch

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

[GPesch]

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

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:

--> 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]

Hi Georg,

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

I did, it was me who crashed you all, hahaha

OK, so let me explain - we have this entry:

    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:

find $FOAM_SRC -name "files" | xargs grep -sl "utilityFunctionObjects"

Best regards,
Bruno

[GPesch]

Hi Bruno,

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

Best regards
Georg