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

Replies to This Discussion

Permalink Reply by Theodoros Galanos on August 2, 2016 at 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.

Permalink Reply by Grasshope on August 2, 2016 at 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!

Permalink Reply by Theodoros Galanos on August 5, 2016 at 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
        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.   

Permalink Reply by Grasshope on August 6, 2016 at 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!

Permalink Reply by Theodoros Galanos on August 6, 2016 at 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.

Attachments:

• decomposeParDict, 4 KB

Permalink Reply by Grasshope on August 6, 2016 at 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:

Attachments:

• 1769.zip, 1.8 MB

Permalink Reply by Theodoros Galanos on August 6, 2016 at 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.

Permalink Reply by Grasshope on August 8, 2016 at 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!

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

... and here is the case file for the outdoor_airflow demo I have so far.

Attachments:

• outdoors_airflow.zip, 3.7 MB

Permalink Reply by Mostapha Sadeghipour Roudsari on August 9, 2016 at 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

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

Thank you very much, Mostapha!

The workflow works fine up to the execute simpleFoam component:

The error 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"

The folders generated in the process are:

Hope you can kindly advise.

Thanks!

-Ji

Permalink Reply by Mostapha Sadeghipour Roudsari on August 9, 2016 at 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.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page