Dear butterfly team, thanks for updating the butterfly components.
Now the demo case for outdoor airflow is working, but only when step 1.2 update fvScheme is bypassed.
First, allow me to briefly show the steps of the successful run when step 1.2 is bypassed (note that the and OpenFOAM session is open in the background while running the Butterfly demo file):
- create wind tunnel, and use different parameters of (4,4) for globalRefLevel as suggested by Theodoro in this post
- run blockMesh:
- run snappyHexMesh:
- run checkMesh:
- connect the case from checkMesh to simpleFOAM and run the simulation:
- the simulation converged at 1865 iteration, but the results visualization part has some problem:
- so I revised this part according to suggestions from Hagit:
- and the results can be visualized for P and U values:
The GH file used for the successful run shown above is attached here.
Now, the following is the error I got when the case from the update fvScheme component is used for simpleFOAM simulation:
the warning message on the simpleFOAM component 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 error message from the readMe! output node is attached below as a text file.
Hope you can kindly advise what the important steps or parameters I might have missed here. I assume it might be related to OpenFOAM rather than with the Butterfly workflow…
Thank you very much!
butterfly_simpleFOAM_error.txt (442 KB)
outdoor_airflow_ZJ_v004.gh (423 KB)
Thanks for sharing this, glad to see that you have are running whole simulations now! The results look ok, wake regions are where they are supposed to be. Ofc, I can tell the mesh quality is still quite rough.
I went through your attached log but it seems to be a successful run, perhaps the error log wasn’t attached. In any case, I believe we have identified this issue. The goal of the update fvSchemes component was to apply schemes to finalized meshes in an automatic way. While this is useful for new users it is also a dangerous thing to do in CFD studies.
The component works by relating mesh quality to the mesh non-orthogonality, which the checkMesh component reports. While non-orthogonality is one of the important criteria of mesh quality it does present difficulties on some kind of meshes, especially like the simple cases that BF has been meshing so far.
The example case of simple box buildings in a wind tunnel above for instance will appear as a good quality case for even the lowest of cell-count meshes, simply because it is an orthogonal geometry. That means that checkMesh will probably report low values (imagine an empty blockMesh of 10m blocks has a non-orthogonality of 0) which in turn means that higher order schemes might be paired with actually low quality meshes. This I believe is causing problems.
I posted a possible solution to this here https://github.com/mostaphaRoudsari/Butterfly/issues/57. The idea is that Buttefly provides additional options to the users, enabling them to choose between first-order (faster, more robust, but lower quality schemes) and second-order (slower, less robust, but more accurate) schemes depending on mesh quality, stage of assessment, etc. In cases like the above mesh quality a first-order scheme might provide a better option. To test this I am attaching an fvSchemes file you can use by replacing yours in the /system folder of the case.
As a note however, I would like to stress there is so much that a tool like Butterfly can provide in this area. Meshing is a quite complicated and demanding part of the process, involving a lot of trial and error. Sometimes the problem is just the mesh and not the solution options (GIGO stands true in CFD as well). It does however get easier with experience. The safe advice is the simplest one: when changing solution options doesn’t help, refine mesh and run again.
fvSchemes (1.41 KB)
Thank you very much for the prompt reply and the detailed advice!
The following image shows the fvScheme file before and after running the update fvScheme component, and the fvScheme file you shared in the above post. The differences are highlighted. Are they correct?
I replaced the fvScheme file with the one you shared, and ran the simpleFOAM component. Now, there is no warning, but the simulation didn’t converge after the 2000 iterations:
then I changed the number connected to the endTime from 2000 to 4000, and the simulation continued for another 2000 iterations without any sign of converge … and then GH freezes completely … and Rhino+GH has to be shut down …
While waiting for the team to consider the “first/second order” function to be added to the update fvScheme component as you suggested on GitHub, may I ask how to improve the mesh quality before the update fvScheme step?
Thank you very much!
Glad to hear the simulation kept on working with the updated fvSchemes. I think it looks alright to be honest. Not converging is not really an issue because it does look converged to me at least for the quality of the mesh.
Actually, convergence is much more than simply having low residuals. You can have a wrong solution with very low residuals. Usually, it is a combined process of both run time information on residuals and having an idea or expectation of what the simulation results should be. Another way of assessing convergence is if the residual values have been stable (within a very small limit, e.g. 1E-5) for more than a certain number of iterations (e.g. 1000). We are planning to provide run-time residual plots in Butterfly, hopefully soon. These plots can help keeping an eye on the solution.
You could try as a test if you want to switch to a blend of first and second order (by swapping upwind with linearUpwind in the fvSchemes)
Concerning mesh quality there are a number of ways, some of which are a bit advanced for this post and for BF’s current capabilities. The best way to start is by refining the background mesh (i.e. the blockMesh). You can do that by assigning more cells to the x, y and z directions in the blockMesh component. However, make sure you increase the max global cells. I would suggest you monitor the output of the blockMesh in order to know the total number of cells there. Your max global cells has to be higher than that for SHM to even work. I’d suggest 2x to start with. Ofc all that requires a bit of trial and error depending on the case at hand.
Hope this helps!
Adding refinement regions should provide a good level of flexibility in meshing workflow.
I wonder if we should stop auto updating fv-scheme and let users choose between available options. Similar to radiance parameters. We can just suggest based on the mesh but don’t change the default?