CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

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

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 11, 2013, 10:30
Default Compiled library vs. inInclude Files, DSMC solver crashes after run
  #1
New Member
 
Join Date: Apr 2013
Posts: 24
Rep Power: 3
GPesch is on a distinguished road
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
GPesch is offline   Reply With Quote

Old   April 14, 2013, 09:31
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,090
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
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: Weird segmentation fault!
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:
      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
wyldckat is offline   Reply With Quote

Old   April 14, 2013, 13:08
Default
  #3
New Member
 
Join Date: Apr 2013
Posts: 24
Rep Power: 3
GPesch is on a distinguished road
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.
GPesch is offline   Reply With Quote

Old   April 14, 2013, 13:15
Default
  #4
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,090
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
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
wyldckat is offline   Reply With Quote

Old   April 14, 2013, 13:42
Default
  #5
New Member
 
Join Date: Apr 2013
Posts: 24
Rep Power: 3
GPesch is on a distinguished road
Hi Bruno, how to find that out? Trail and error? Comment one out and check again?
GPesch is offline   Reply With Quote

Old   April 14, 2013, 13:59
Default
  #6
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,090
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
Quote:
Originally Posted by GPesch View Post
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
wyldckat is offline   Reply With Quote

Old   April 15, 2013, 10:07
Default
  #7
New Member
 
Join Date: Apr 2013
Posts: 24
Rep Power: 3
GPesch is on a distinguished road
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
GPesch is offline   Reply With Quote

Old   April 17, 2013, 16:36
Default
  #8
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 7,090
Blog Entries: 32
Rep Power: 70
wyldckat is a jewel in the roughwyldckat is a jewel in the roughwyldckat is a jewel in the rough
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:
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
wyldckat is offline   Reply With Quote

Old   April 18, 2013, 07:17
Thumbs up
  #9
New Member
 
Join Date: Apr 2013
Posts: 24
Rep Power: 3
GPesch is on a distinguished road
Hi Bruno,

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

Best regards
Georg
GPesch is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Edit/stop run in progress without solver manager N.R. CFX 6 October 24, 2007 12:43
Help, can't stop solver run...Windows OS ben akih CFX 2 November 13, 2006 10:05
Solver crashes only while writing a bak file hagupta CFX 1 April 11, 2006 18:10
Solver error in Parallel run 255 M CFX 0 February 28, 2006 03:38
CFX 5.5 Roued CFX 1 October 2, 2001 16:49


All times are GMT -4. The time now is 08:50.