[nashiong]

Dear all:
the title should be 'OpenFoam laminarSmoke H2 coflow jet flame parallelization error' more precisely.
the software version is:OpenFoam version: 2.2.2, g++ version: 4.6.3, laminarSmoke 0.15
Sketch of the geometry
https://www.dropbox.com/s/0zbfgkjv8s...omain.png?dl=0
https://www.dropbox.com/s/fi9jnw0x2n6k9qe/mesh.png?dl=0
checkMesh gives the following information.

http://www.dropbox.com/s/8bum9zzbmej...kMesh.log?dl=0

First case: no parallelization, the laminarSmoke default example, more operational details could be referred to following website:
http://www.opensmoke.polimi.it/compo...116-tutorial-1

I follow the exact the same procedures in this tutorial and the detailed information is shown in the following:
fvScheme: https://www.dropbox.com/s/jh62b9t4c2...fvSchemes?dl=0
fvSolution: https://www.dropbox.com/s/ihd6m7cp0z...vSolution?dl=0
then run the case by typing:
laminarSmoke_0.15.dvode > run_series.log>&1
note that in laminarSmoke, different ODE solver could be combined, the reason why the name is laminarSmoke_0.15.dvode is because I use dvode ODE solver to compile the laminarSmoke_dvode.C
Then the code runs successfully and below is all the information recorded in run_series.log
https://www.dropbox.com/s/toldtc8d95...eries.log?dl=0
The computed flame temperature profile is shown as:
https://www.dropbox.com/s/56qg4181x8...flame.png?dl=0
It proves that we could run the case successfully with single core configuration.

Multi-core behavior.
To validate the parallel environment is properly configured on my workstation, I run the interfoam dam break case, as well as reactingFoam counterflame case with 4 cores successfully.
Then I proceed to laminarSmoke parallel computing.
1. use decomposeParDict in the ./system/, the file is attached as:
https://www.dropbox.com/s/hhdsjihstq...seParDict?dl=0
2. run decomposerPar > decomp.log, and the log file is attached as following:
https://www.dropbox.com/s/x74j0c84dc...ecomp.log?dl=0
3. then four folders from processsor0 to processor 3 appears and I check the mesh by paraFoam individually and they are all fine.
4. then type mpirun –np 4 laminarSmoke_0.15.dvode -parallel > run_parall.log 2>&1
5. the error occurs and the detailed error information is shown in the run_parall.log
https://www.dropbox.com/s/usok5vox9r...arall.log?dl=0
6. LaminarSmoke also provide a mpi version which is compiled with the laminarsmoke_dvode.mpi.C file with the same content as laminarSmoke_dvode.C except changing one line content from
# define COFLOW_MPI 0 to
# define COFLOW_MPI 1
I found that COFLOW_MPI name only appears in this C file and not anywhere else thus I suspect this variable is only an index not used.
7. Just in case, if repeat the above process using laminarSmoke_0.15.dvode.mpi, the same error occurs and the content is attached.
https://www.dropbox.com/s/g1lwy09bln...n_mpi.log?dl=0

[Tobi]

Dear nashiong,

I think laminarSmoke is not the same solver as the libOpenSmoke toolbox. Laminar smoke is - as far as I know - for laminar flow fields like a combustion of a candle. I never had a look into that solver because I never need a laminar solver. I only can see a wrong syntax in your command line:

wrong
mpirun -np -4 laminarsmoke.versionNo.mpi -parallel

correct
mpirun -np 4 program -parallel

At all I dont know why it is called lamianrsmoke.versionNo.mpi ? Are you using windows?

[nashiong]

Originally Posted by Tobi

Dear nashiong,

I think laminarSmoke is not the same solver as the libOpenSmoke toolbox. Laminar smoke is - as far as I know - for laminar flow fields like a combustion of a candle. I never had a look into that solver because I never need a laminar solver. I only can see a wrong syntax in your command line:

wrong
mpirun -np -4 laminarsmoke.versionNo.mpi -parallel

correct
mpirun -np 4 program -parallel

At all I dont know why it is called lamianrsmoke.versionNo.mpi ? Are you using windows?

hi Tobi, thanks for your in-time reply. Sorry for this misleading information. LaminarSmoke.versionNo.mpi the versionNo means the stiff-ode solver I am using. so this file is a executable file functioning similarly as icoFoam, pisoFoam ..... I see, originally I think laminarSmoke is a final version of Opensmoke since they remove opensmoke on the website after releasing the laminarSmoke. Then Tobi, do you have any trouble when you try to run OpenSmoke in parallelization?
thanks

[Tobi]

Originally Posted by nashiong

hi Tobi, thanks for your in-time reply. Sorry for this misleading information. LaminarSmoke.versionNo.mpi the versionNo means the stiff-ode solver I am using. so this file is a executable file functioning similarly as icoFoam, pisoFoam ..... I see, originally I think laminarSmoke is a final version of Opensmoke since they remove opensmoke on the website after releasing the laminarSmoke. Then Tobi, do you have any trouble when you try to run OpenSmoke in parallelization?
thanks

Hi,

I had some email traffic with Alberto Cuoci and it seems that they are releasing the solver but I dont know when. I thought this will happen 2 years ago but as you know science is sometimes tricky (:

Well I had never a problem using this tool with parallel mode. Everything is working fine.

[nashiong]

Originally Posted by Tobi

Hi,

I had some email traffic with Alberto Cuoci and it seems that they are releasing the solver but I dont know when. I thought this will happen 2 years ago but as you know science is sometimes tricky (:

Well I had never a problem using this tool with parallel mode. Everything is working fine.

Thanks Tobi, I guess I need to dig into the code to figure out the problem then.

[wyldckat]

Greetings to all!

@nashiong: I've gotten the PM you sent me and I've taken a few quick reads on this thread, and unfortunately there isn't enough information... at least not without me having to download and try things myself.

From the lengthy error message you posted, the following indicates a segmentation fault:

Foam::sigSegv::sigHandler(int)

This usually is related to a bad memory access, because it tried to access a point in memory that doesn't exist or is not accessible to this application, which lead to the program to crash.

If you can provide more specific details, so that I don't have to try running this solver myself, it should be possible to diagnose what the problem is. And by more details, I'm referring to the fact that we are not able to see what exact steps you've taken, which case you're using and so on
For more ideas on what referring to, please read this thread: http://www.cfd-online.com/Forums/ope...-get-help.html

Best regards,
Bruno

[nashiong]

Originally Posted by wyldckat

Greetings to all!

@nashiong: I've gotten the PM you sent me and I've taken a few quick reads on this thread, and unfortunately there isn't enough information... at least not without me having to download and try things myself.

From the lengthy error message you posted, the following indicates a segmentation fault:

Foam::sigSegv::sigHandler(int)

This usually is related to a bad memory access, because it tried to access a point in memory that doesn't exist or is not accessible to this application, which lead to the program to crash.

If you can provide more specific details, so that I don't have to try running this solver myself, it should be possible to diagnose what the problem is. And by more details, I'm referring to the fact that we are not able to see what exact steps you've taken, which case you're using and so on
For more ideas on what referring to, please read this thread: http://www.cfd-online.com/Forums/ope...-get-help.html

Best regards,
Bruno

@wyldckat, thanks for your kind guidance and I update the post accordingly. Please let me know if you need any further information. If you want to have a try on this code a little bit, you can find all the detailed information in following website:
http://www.opensmoke.polimi.it/
Thanks for your attention and help.

[zatralias]

Hello to all,
I am trying to run laminarSmoke with OpenFOAM version 2.1.1 and I am having the same problem as nashiong.
I believe a first problem is encountered when executing createFields.H and specifically in the lines:

        label inletFuelPatch = mesh.boundaryMesh().findPatchID("inletfuel"); 
        label inletOxidizerPatch = mesh.boundaryMesh().findPatchID("inletair"); 
        
        Info << "Fuel stream (mass fractions): " << endl;
        for (label i=0; i<Y.size(); i++)
        {
            omegaFuel[i+1] = Y[i].boundaryField()[inletFuelPatch][0];
            if (omegaFuel[i+1]>1e-16) Info << Y[i].name() << " " << omegaFuel[i+1] << endl;
        }

        Info << "Oxidizer stream (mass fractions): " << endl;
        for (label i=0; i<Y.size(); i++)
        {
            omegaOxidizer[i+1] = Y[i].boundaryField()[inletOxidizerPatch][0];
            if (omegaOxidizer[i+1]>1e-16) Info << Y[i].name() << " " << omegaOxidizer[i+1] << endl;
        }

Setting Y[i].boundaryField()[inletOxidizerPatch][0] and Y[i].boundaryField()[inletOxidizerPatch][0] to a fixed value e.g. 1e-16, helps the execution proceed, but then the algorithm is wrong and the solution crashes.
I hope this helps
Thanks

[wyldckat]

Greetings to all!

If zatralias' finding is correct, then it's very possible that this solver is not ready for usage in parallel.
My advice is to try and contact the original authors for getting a clearer understanding on whether these solvers are already prepared or not for running in parallel.

Possibly also read the documents, manuals and papers they provide, because there might be detailed information regarding whether it's possible to use or not in parallel.

Beyond this, I'll try to have a better look into this next weekend.

Best regards,
Bruno

[nashiong]

@wyldckat, thanks for your kindly suggestions. I've tried the points you mentioned but as far as now, this code is poorly supported in terms of documentation. I guess I have to understand all the structure of the code before figuring out why. Thanks for your guidance

[yashar.afarin]

Hello,

I am receiving the same error "Foam::sigSegv::singHandler(int)" by running the code in parallel. I have sent several emails to them but so far I have not received any response from them. It is strange that in the paper that was published about this code (Combustion and Flame 160, issue 5, 870-886), it is mentioned about the parallel performance of the code but the code is not able to run in parallel.

I am wondering, have you had any success to run this code in parallel?

Regards,