[clarified and WIP] butterfly doesn't work with OpeFOAM v1606

I got the following error testing the outdoor demo file for butterfly:

I followed the advice on https://github.com/mostaphaRoudsari/Butterfly/wiki/Getting-Started-... and changed the container name to "of_plus_1606" in the runmanager.py script file based on the output of "docker ps" in docker terminal:

However, the error is still here, and I can't proceed to the rest components in the workflow...

The demo workflow can generate the "outdoor_airflow" project folder in the C:\Users\USERNAME\butterfly folder

So, I start OpenFOAM using the start_OF.bat file, and I can manually type and run the following OpenFOAM command: blockMesh, snappyHexMesh, checkMesh, manually change some of the parameters in controlDict and fvSolution.

However, I got the following error when running simpleFoam, and the calculation is aborted.

May I ask:

why the blockMesh component is not running even if I changed the container number in the rummanager.py as suggested?

Why the manual running of OpenFoam failed?

Thanks!

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Grasshope on August 9, 2016 at 9:18pm

Hi Mostapha, thanks!

I tried the outdoor demo file on my office computer today, and I got error on the blockMesh component:

Is it because that butterfly cannot find my container ID?

I do have OF v1606 installed, and the OF_plus_1606 container is shown in docker:

and I can run OF through executing OpenFOAM_start.exe:

Dose this mean I didn't get OF installed correctly?

Hope you can kindly advise!

Permalink Reply by Mostapha Sadeghipour Roudsari on August 10, 2016 at 7:16am

Hi Grasshope,

Yes. This is an error that raise by the new check that I added for finding containerId. As you can see there is an ERROR! line in the report but then there is no error reported. Let's try to remove the check and see if that makes any difference. Can you go to "C:\Users\sdezj\AppData\Roaming\McNeel\Rhinoceros\5.0\scripts\butterfly" and replace runmanager.py with the attached file. You need to close both Rhino and Grasshopper and re-open them so Grasshopper re-loads butterfly library.

Let me know if it solves the issue.

Mostapha

Attachments:

runmanager.py, 6 KB

Permalink Reply by Grasshope on August 10, 2016 at 9:04am

Thanks, Mostapha!

I followed ur suggestion by replacing the original runmanager.py file with the one you provided. May I confirm with you that the only difference between them is that in your code, the "return" is comment out as shown below?

After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:

Then the blockMesh component gives the following error: seems I have to manually start OF first..

so, as the error message suggested, I open OF by Start_OF.bat:

Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:

... and the blockMesh finished successfully:

... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:

... up to the simpleFoam component, I got the error again:

The warning message is:

1. Solution exception:
--> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#2 ? in "/lib64/libc.so.6"
#3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
#8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so"
#9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
#10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
#11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
#12 __libc_start_main in "/lib64/libc.so.6"
#13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"

... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.

So, my questions are:

1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?

2. what might be the cause of the unsuccessful run of simpleFoam in the end?

Hope you can kindly advise! Thank you!

- Ji

Attachments:

simpleFOAM_error.txt, 113 KB

Permalink Reply by Grasshope on August 10, 2016 at 9:20am

BTW, the indoor demo file does work! Still, I have to start OF manually first....

Permalink Reply by Mostapha Sadeghipour Roudsari on August 11, 2016 at 6:08am

Hi Grasshope (Ji?),

Thank you for the in-detail report. Everything is working fine on your machine. The error is either because of meshing or the boundary condition which is an OpenFOAM error and doesn't have to do much with butterfly workflow. I'll wait for Theodore input for the error itself.

The reason that you need to run the container manually is to make sure it's installed and running on your system with no issues. We probably can automate this step eventually but for now you need to run OpenFOAM manually once and leave it open in the background. Then you can run as many analysis as you want using butterfly.

I'm very excited to see more users are now running butterfly successfully. A couple of more weeks and we will have the public release! :)

Permalink Reply by Theodoros Galanos on August 9, 2016 at 6:23pm

Hi Grassoppe,

This is a "divide by zero" error (see sigfpe). This happens usually due to boundary conditions or mesh quality. The GAMG solver is failing, I'm guessing that is your pressure.

If this is the same case working earlier I would guess it's a mesh error. If not, please share your folder here and I'll take a look.

Kind regards,

Theodore.

Permalink Reply by Grasshope on August 9, 2016 at 9:20pm

Thanks, Theodore!

Shall I increase the globalRefLevel parameters to improve mesh quality, as you suggested before?

I shall test it later when I get the butterfly workflow working...

Permalink Reply by Theodoros Galanos on August 10, 2016 at 9:48am

Yes that would help.

Although if you can please share your 0 folder with me. This sometimes happens due to boundary/initial conditions. I'd like to make sure our default BCs are still there or correctly implemented.

Thanks!

Kind regards,

Theodore.

Permalink Reply by Theodoros Galanos on August 18, 2016 at 12:20am

Hi Ji,

I went over this issue and I think this is a bug in BF currently.

The issue has to do with the way the initial conditions for turbulence properties are calculated. Smh the correct values are not passed on which makes the simulation diverge. I have already posted on this in github (https://github.com/mostaphaRoudsari/Butterfly/issues/54) it should be fixed soon.

In the meantime I was wondering if you can help me validate this. In the file you attached here your initial conditions were:

Uref = 2m/s

Zref = 10m

z0 = 0.005

Your initial conditions file has the following k and epsilon values:

k = 0.039

epsilon = 0.031

Could you please try manually changing them to the following values and re-running the case? You would have to run it manually as well so that BF won't overwrite your changes.

k = 0.039

epsilon = 0.0003

Thank you so much for testing!

Kind regards,

Theodore.

Permalink Reply by Theodoros Galanos on August 19, 2016 at 3:01am

Hi Ji,

Mostapha has fixed the bug, I believe updating BF would do it.

Give it a try and let us know.

Kind regards,

Theodore.

Permalink Reply by Olivier Dambron on August 22, 2016 at 4:00pm

Hello Theo, Ji, Mostapha,

Thank you for developing BF, this is huge.

As I execute SimpleFoam:

Attachments:

Screen Shot 2016-08-22 at 22.58.59.png, 140 KB

Permalink Reply by Olivier Dambron on August 22, 2016 at 4:19pm

I managed to resolve this issue by changing the "reflevels" of the Wall boundary which were not comprised in the "globalreflevels" of the Wind Tunnel.

Everything ran well, I do collect data but unfortunately am still unable to load the probes to visualise at the end.

please find the screenshots hereby.

Best,
Olivier

Attachments: