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

Grasshope · August 2, 2016, 2:14am

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!

TheodorosGalanos · August 2, 2016, 11:57am

Hi Grasshoppe,

The new OF version is using a new Docker technology that Mostapha believes will make installation/setting up OF + BF interaction much easier. Unfortunately, it does not at the time work. I believe this is the n1 item on the list and it will be fixed until the public release coming shortly. Hang in there!

Check: https://github.com/mostaphaRoudsari/Butterfly/issues/43

In the meantime, please let us know of the values you had to change manually in controlDict and fvSolution. Was that due to wrong values set from BF or was it because they weren’t updated through BF?

Kind regards,

Theodore.

Grasshope · August 2, 2016, 9:02pm

Hi Theodoros, Thank you very much for the clarification!

Yes, the installation of the latest OpenFOAMv1606 is much smoother.

Allow me to explain my procedures to run the demo file:

Since the current demo file of Butterfly doesn’t work with OpenFOAM v1606, I used the case file generated from the Create Case file component.

then I start OpenFOAM:

run blockMesh:

run snappyHexMesh:

run checkMesh, and there is one check failed

I didn’t manage to run updateFvSchemes, or this is not the correct command for this step as it didn’t work obviously …

Nevertheless, I continued to modify the following files:

and lastly, run simpleFoam which was not successful:

I have to admit that I’m only trying to follow the steps and get the demo simulation running correctly, and I haven’t started to understand what each step is doing and the parameters associated. I think I must have missed important steps or specified wrong command in this process, and hope you can kindly advise.

Thank you!

TheodorosGalanos · August 5, 2016, 7:05am

Hi Grasshoppe,

I am terribly sorry for the late response. Let’s take this one by one.

The first two steps seem to be ok. Did you supply a grading to your initial blockMesh through the BF components? It seems that the X and Z direction are graded, with the grading in the X direction not being symmetrical (which is ok if X is the wind direction). If you didn’t we would need to check our default settings but if memory serves they should be set at no grading.

As a side note here, a suggestion is to keep your refinement levels, either global or the ones set per boundary, to equal (optimal case) or not very different values. The (2,10) you supplied could potentially create sudden cell size changes which is not optimal, even though probably the 10 isn’t going to be used. Settings like (2,3) or (2,4) would be ok. If you want to go higher, raise both numbers.

The update fvSchemes functionality is an added option of BF itself and not a command within OF. Essentially what it does is apply proper schemes to your model according to the mesh quality you have achieved. This is why OF won’t recognize it. When we get BF going with the new version this will be done automatically for you.

Finally, the error you are seeing is again eliminated through the use of BF which takes care of the clean up and folder set up for you prior to running the case. For now, to do it manually, what you need to do is this:

1.Delete the /constant/polyMesh folder

2.Cut the polyMesh folder from the /2 folder and paste it to your /constant/polyMesh folder.

3.Delete the /1 and 2/ folders

4.Rename the /0.org folder to /0 (if that was not the case already)

4a.Run the case in serial mode with the simpleFoam command.

or

4b.Run the case in parallel with:

    decomposePar<br/>        mpirun -np x simpleFoam -parallel

Where the x is the number of processors set in your decomposeParDict found in the /system folder, usually set at 4. You can change that number of processors by simply changing that number in the beginning of the dictionary. To avoid other problems here with different number of processors change to scotch method in the same dictionary.

P.S.: Another easier but dirty (to my sensibilities) way is to simply paste the 0 folder inside the 2 folder. Provided boundaries and boundary conditions are set ok this should run. This would work for the serial way.

I hope this helps! When BF is up and running soon most of this will be hidden in the background. But the brute force method you are taking now is also quite educational.

Let me know if you have any other questions or issues! Thanks for testing!

Kind regards,

Theodore.

Grasshope · August 6, 2016, 1:17am

Thank you very much, Theodore, for the detailed advice!

I followed your suggestions from step 1 to 3.

As to step 4b, i got the following error when running decomposePar:

So, I run the simulation not in parallel: simpleFoam, and the the it converges after 1769 iterations:

Several new folders were created in the case folder:

I opened the case file in PareView, which gives the following error message:

Nevertheless, the results can still be visualized, but I’m not sure if the visualization is correct:

… and additional error messages keep coming out:

Hope you can kindly advise if the results are correct and what to do with the error message during visualization in ParaView.

Thank you very much!

TheodorosGalanos · August 6, 2016, 2:32am

Hi Grasshoppe,

Well done! That’s a CFD simulation alright!

Results look ok, I mean it’s hard to judge since this one is a simple case and not a real model of an area where we have some expected results.

In the visualization, points is an interesting option. It’s a matter of aesthetics I guess, I go with surfaces Also what you can try is selecting Filters -> Slice (you can also find it in the icons above the pipeline viewer), in the Slice options below the pipeline press Z normal and on the Z coordinate press some height relevant to the buildings (e.g. 1.75m a typical human scale). That would show you the flow around the buildings on that height. Experiment with selecting other normals and values. Keep playing with the filters there’s some cool things in there. Also you can check out the mailing list and extensive paraview documentation.

Concerning the errors I apologize because I just downloaded your case.

It appears that the decomposeParDict is not included in the system folder. I am not sure if this is due to BF not going through the whole workflow yet or an ommission on our side. Please feel free to add it in Github. I will also note it down and pass it to Mostaph to check. In the meantime please find attached a VERY detailed decomposeParDict file. I took the liberty to set it at 4 processors (the numberOfSubDomains value) and also selected (that is uncommented) the scotch decomposition method. It’s the easiest method to use since it is automatic and doesn’t require any more inputs on how the domain is decomposed on the x,y,z directions (which would require you to change values in the attached file).

Now, the different folders created are simply snapshots of the current solution at the specific timestep. To control how often the solver is saving change the writeInterval number in the controlDict file. You can also change almost all these values on the fly, while OF is running.

Finally, concerning the other errors of parafoam it seems somehow parafoam is reading the intial condition names instead of actual results from the solution files and it doesn’t like it.

Does this happen only when you open the case (i.e. at 0 time) or does it also happen when you move to an other timestep?

Also, are you using paraFoam, paraview or the paraFoam -builtin method?

The extension of the paraFoam file seems to be .foam which means you are probably using the built in viewer. That might be the issue but I’m not sure.

Can you try running paraview, navigate to your case folder, open the .foam file and see if there is still an error?

Also, if it isn’t much trouble can you zip one of the time folders and attach it here? I’d like to take a look at what’s inside to check against what the error report says.

Once again thanks for testing!

Kind regards,

Theodore.

decomposeParDict (3.56 KB)

Grasshope · August 6, 2016, 8:02am

Hi Theodore, Thank you very much!

I’m using ParaView to visualize the results. The case file for the last time step is attached here for your reference.

The slice visualization is interesting, but the colors are in big patches:

1769.zip (1.77 MB)

TheodorosGalanos · August 6, 2016, 10:06am

Hi Grasshoppe,

I don’t see anything irregular in the solution folder. It must be something to do with paraFoam itself.

Did you use paraview by actually typing paraview and navigating to the folder or did you type paraFoam to call the OF integrated paraview, or did you maybe type paraFoam -builtin? The last one was a workaround for when paraview installation has issues. I think I remember an old bug where the version not connected to OF would give out this error. I will check it as soon as I can to make sure it’s not smth in our case setup.

Concerning the boxes on the display that is the refinement of your mesh. The fastest way to get a more refined image is to go back to your blockMesh and change the number of cells in x and y directions (and thus the size of these squares) and go through the whole process of meshing and solving again. Bare in mind doubling the cell number makes a 4 times bigger mesh, which would also delay the simulation a bit (but really for such a small model it would still be fairly fast).

Another thing you can do in coarse or even medium quality meshes is to display the point values and not the cell values. You can do that in the dropdown menu where you select which fluid parameter to display (U, p, k, epsilon, etc.). In your screenshot I can see the cell value is currently selected. By selecting point values Parafoam should interpolate the display automatically and provide a more ‘refined’ image (but not a more accurate result). Should make a small difference in such a coarse mesh but this works quite nicely in medium to better meshes.

Kind regards,

Theodore.

Grasshope · August 8, 2016, 7:34am

Thanks, Theodore!

I didn’t open ParaView from within OF, i.e., I opened it by double click the ParaView thumbnail, and then did the following:

I shall try increasing the meshing parameter as suggested.

The visualization of U magnitude by point as suggested is shown below which might be improved if the meshing resolution is higher:

Thank you very much, again, for your detailed advice!

mostapha · August 9, 2016, 11:36am

Hi Grasshope and Theodore.

Try the new butterfly. It should work with the latest version of OpenFOAM and you should be able to run the analysis from inside Grasshopper.

Here is the directions for updating the current installation. Sorry for the delay. I was a way for a couple of weeks.

Mostapha

Grasshope · August 9, 2016, 12:20pm

Thank you very much, Mostapha!

The workflow works fine up to the execute simpleFoam component:

The error message is:

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”

The folders generated in the process are:

Hope you can kindly advise.

Thanks!

-Ji

mostapha · August 9, 2016, 12:55pm

Thank you for testing. It looks to be an issue with the mesh. Does it start iterating and fails after a couple of iterations or gives you the error as soon as you try to run the analysis. Can you try the indoor example too? That should give us a better idea about the source of the issue.

Grasshope · August 9, 2016, 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!

mostapha · August 10, 2016, 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

runmanager.py (5.74 KB)

Grasshope · August 10, 2016, 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:

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:

why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
what might be the cause of the unsuccessful run of simpleFoam in the end?

Hope you can kindly advise! Thank you!

Ji

simpleFOAM_error.txt (113 KB)

Grasshope · August 10, 2016, 9:20am

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

mostapha · August 11, 2016, 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!

TheodorosGalanos · August 22, 2016, 8:14pm

Hi Olivier,

Have you made sure you updated BF before running the case? There was an error in creating initial conditions and cases would diverge.

This is what seems has happened to your case. If you see, the results indicated in the error for pressure are, well I don’t think I know the name for those numbers. But values of XE+118 mean the simulation was diverging. I would recommend you to update BF, if you haven’t already, re-run the case and test after.

Also, you can post your mesh settings here. Most other times is mesh quality causing this.

Kind regards,

Theodore.

TheodorosGalanos · August 22, 2016, 8:39pm

I take it back!

Sorry I spoke too soon, from the file you provided the results seem ok. I believe Mostapha will have more on this.

Regards,

Theodore.

OlivierDambron · August 22, 2016, 8:40pm

Hi Theo,

I have indeed read the earlier thread on the initial conditions.
I did go through updating it, closed, reopened… I remain not confident with the different permissions and rooting of folders, as Im running Windows 10 on Parallels on a Mac. However I have been using a lot of softwares and have always found solutions.

Please find attached the GH definition in which you’ll see that I have not made significant changes, apart form increasing the reflevels of the wall boundary, thinking they would have to be comprised in the globalRefLevel of the wind tunnel. Also the wind speed.

Thank you for reaching.

Kind regards,

Olivier