butterfly test: simulation for case with fvScheme updated is not working

Replies to This Discussion

Permalink Reply by Theodoros Galanos on August 27, 2016 at 1:59am

Hi Ji,

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.

 

Kind regards,

Theodore.

Attachments:

• fvSchemes, 1 KB

Permalink Reply by Grasshope on August 27, 2016 at 7:57am

Dear Theodoros,

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!

- Ji

Permalink Reply by Theodoros Galanos on August 27, 2016 at 10:07am

Hi Ji,

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!

Kind regards,

Theodore.

Permalink Reply by Mostapha Sadeghipour Roudsari on September 11, 2016 at 9:31am

Adding refinement regions should provide a good level of flexibility in meshing workflow.

https://github.com/mostaphaRoudsari/Butterfly/issues/59

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?