OpenFOAM command Failed!

[bitacovir]

When I solve the process stopped at Time=492 Then the process finishes with this report

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  Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
 #4  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"
 #5  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so"
 #6  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so"
 #7  Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
 #8  Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
 #9  ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
 #10  __libc_start_main in "/lib64/libc.so.6"
 #11  ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"

I am working on a Windows 10; intel core i7 16GB Ram

[TheodoreGalanos]

@bitacovir

First of all thank you for testing out Butterfly! Hope you find the program useful and easy to navigate. Please let us know of any improvements you might want to see.

Concerning the error this is not a Docker/VM, OF, or Butterfly bug. The error you see means that your simulation has diverged, something that generates increasingly high residuals (most of the times in the order of unrealistically high numbers). When that happens, due to the way OF calculates fields you will end up dividing with zero (this is w hat the Sigfpe error means).

99/100 times this happens due to mesh quality and setup. Given that the default BF boundaries have been generating reasonable results in many tests I do believe that this is a mesh issue.

You can try increasing the quality of the background mesh (increasing divisions in blockMesh component) and the snappyHexMesh (increasing refinement level in input geometries). We are currently enabling refinement regions as well where you can select the region (usually around your geometry) to refine by drawing any shape and pluging into BF. We hope to have this soon.

In the meantime, try to progressively increase your mesh quality and see what happens.

Finally, make sure that the extension of the blockMesh is sufficient. You generally don't want the edges to be anywhere near your geometry (I would extend it 2-3 times the height of your geometry).

Hope this helps! Much more, and wiser, advice you can find in www.cfd-online.com. Usually, there's multiple threads answering most of the common issues in CFD studies.

Kind regards, Theodore.

[bitacovir]

Thanks for the clarification. I will try what you suggest. I am not CFD expert. I just have some experience with VASARI, ANSYS and ODS-Studio. I am very interested in this work. With a group of colleagues we developed a mini wind tunnel using arduino sensors and rhino3D + grasshopper for visualisation http://www.grasshopper3d.com/group/mini-airflow-tunnel-project We think this new feature can be very useful in a workflow with our mini wind tunnel.

In addition I have a couple of suggestions: 1) I would suggest to change the terms of _landscape parameter in CreateCaseFromTunnel node landscape: An integer between 0-7 to calculate z0 (roughness). 0 > '0.0002' # sea 1 > '0.005' # smooth 2 > '0.03' # open 3 > '0.10' # roughlyOpen 4 > '0.25' # rough 5 > '0.5' # veryRough 6 > '1.0' # closed 7 > '2.0' # chaotic You could change them to urban suburban, open land, etc. So, the people can associate the roughness.

2) The second things is, previous the solve process, I only can see the background mesh or blockmesh in Paraview. I can not see the snappyhexmesh around the buildings. Only after I run the case I can see the whole mesh around the buildings in Paraview. I think it is better to have the possibility of observer this snappyhexmesh before of the solve process to make changes in the mesh if we consider it.

Anyway, I think it is a wonderful tool.

[mostaphaRoudsari]

Hi @bitacovir,

Thanks for suggestions.

1. That's a good idea. We still need to come up with terms for all seven parameters. What is your suggestion?
2. You can already visualize the mesh after you run snappyHexMesh. No need to run the case.

[bitacovir]

1) I think you could use terms like: Ocean or Coastline (sea) Rural grass (smooth) Rural (open) Rural (roughly open) Suburbs (rough) Suburbs (very rough) Urban (closed) City Skyscrapers (chaotic)

2) Ohhh I see... You must run Load Mesh node. Ok

[mostaphaRoudsari]

Thanks, @bitacovir. @TheodoreGalanos any comments?

[TheodoreGalanos]

@bitacovir @mostaphaRoudsari

Thanks for the suggestions @bitacovir , I agree that giving descriptive values for the users is the way to go. Your classification seems to be the revised Davenport classification which is what we also used for the values. The terms suggested are okay, or if we want to be a bit more detailed (depending on how we want the tooltip to show) we can give the first sentence or so from the Landscape description of the Davenport table (see below)

For example:

Open sea or lake, dessert (Sea) Featureless land surface without noticeable obstacles or vegetation (Smooth) Level country with low vegetation and isolated obstacles (Open) Cultivated area with low crops or plant cover and occasional obstacles (Roughly Open) Cultivated area with high crops and scattered obstacles (Rough) Intensively cultivated landscape with many rather large obstacle groups or covered by low buildings (Very Rough) Urban area or mature forests (Skimming) City centres with a mix of low-rise and high-rise buildings, large forests (Chaotic)

I don't think my suggestions are such an improvement to the previous ones, more like an aesthetic difference. I think as long as we are giving them a link for further details, e.g. something like http://onlinelibrary.wiley.com/doi/10.1002/met.273/pdf then it should be ok. We want the users to also learn through this.

Kind regards, Theodore.

[mostaphaRoudsari]

Thanks @TheodoreGalanos! I like the text description. I'm worried that simplifying it too much makes it unclear which is also the problem with what I did originally. I will update the descriptions tonight and close this issue.

Also @bitacovir we added a lot of new features to butterfly including refinement region and grading which gives you more control on meshing. You can update butterfly and download the updated example files from Github.

[bitacovir]

@mostaphaRoudsari @TheodoreGalanos! Thanks for the attention on my suggestion. I do not know if you are aware, but with this app you are bringing an engineering tool (OpenFOAM) to the designers and architects scope and workflow. You are pushing some of the hardest barriers for people who does not have this kind of background. In this sense, it is necessary to find or establish a "shared knowledge" from where you can develop your application for multiple users. Thus, it would be good to avoid the use of acronyms and to try to use common language for description of terms. In addition, I think it would be great to include in the wiki a introductory chapter about basic concepts of aerodynamics. Regards

[mostaphaRoudsari]

@bitacovir I totally agree with your comments about establishing "shared knowledge" or as I usually put it "shared language". What we have been trying to do so far, mainly in Honeybee, is to educate the users gradually by including both. Using common language is great to get people started and acronyms and technical terms are essential for finding references and reading more about the topic. An introductory chapter about basic concepts of aerodynamics will be very helpful. I think we need a similar link for introduction to OpenFOAM. I can think of a couple that I have seen online but they are all engineering references. Do you know of a good online reference for designers that doesn't oversimplify the topic?

I will close this issue since it's not about documentation. Please add your further comments here.