Meshing inspector

[DambronOlivier]

Hi @TheodoreGalanos and @mostaphaRoudsari ,

I was thinking of a Meshing inspector/assistant component. Perhaps the following ideas would be helpful for butterfly users. I may be making many assumptions which I'd like to either correct or confirm with you :).

1. In order to understand and use the segment grading I've built on GH a crafty cluster to visualise the wireframe of the computational domain and the lines that mark the divisions along x, y and z. This allows me to focus the grading conveniently toward the area of interest. Perhaps such component could also allow to visualise the surface wireframe of the blockmesh in Rhino of only two faces of the blockmesh (bottom one for XY and front one for Z). So far I am changing settings in GH, blockmesh runs and switching to Paraview to measure the smallest cell before re-adjusting. This would allow to immediately view the effect of the grading settings without waiting for Rhino to load the full mesh, help understand and optimise them.

This component could also return the cell size at the center of the graded blockmesh at the area of interest which for the following points can be referred to as the pre_refinement_cellsize_Level0.

2. For an outdoor simulation - wind around buildings, as a rule of thumb I keep in mind that cell size needs to be 1m near areas of interest or less. target_cell_size = 1. or In the case of an outdoor simulation - wind through buildings, I keep in mind that the cell_count_at_the_smallest_opening ~ 10 cells (following some best practice guidelines if I'm not mistaken). Once I measured the opening I divide it by 10 and that becomes my target_cell_size.

Now I need to find the number of refinement levels X for :
pre_refinement_cellsize_Level_X ~ target_cell_size.

If this number is greater than 5 then return "initial_blockmesh_cell_size is too big" as this is likely to be computationally too costly. There could be an indicative output as a log that indicate " pre_ref_cellsize_Level0 > target_cell_size pre_ref_cellsize_Level0 * 2 > target_cell_size pre_ref_cellsize_Level0 * 2^2 > target_cell_size pre_ref_cellsize_Level0 * 2^3 ~ target_cell_size <-- pre_ref_cellsize_Level0 * 2^4 < target_cell_size pre_ref_cellsize_Level0 * 2^5 < target_cell_size

recommendation => set upper refinement level of geometry of interest to level 3 or decrease blockmesh cell size"

3. It seems that the bounds of the global refinement levels need to be widest range of refinement levels input for the geometries. Maybe this can be automated.

4. Something I picked up when using snappyHexMesh is that the surfaceFeatureExtract level should match the highest refinement level set in the geometries, otherwise the mesh breaks or things may become unstable. Maybe this can be automated.

let me know what you think.

Olivier

[TheodoreGalanos]

Hi @DambronOlivier Thank you so much for your thoughts and suggestions!

This is something we have been discussing for a while now and I must say I was supposed to come up with a way to automate gradient meshing. All your recommendations on the first point are valid and resemble how I was thinking to automate this. One slight difference is that I felt we don't really need to load any surfaces from the case but instead have our component visualize lines according to our gradient meshing parameters. However, loading is needed to check the case before running so it might be a good option. I was also thinking if the component should have a sort of rectangle input that allows the user to quickly reference the area of interest, with the component then automatically generating the other areas around it.

Concerning the second point, while this is indeed a good idea I feel it can be a bit dangerous to automate this. I want users to try (and fail sometimes) when deciding on their minimum cell size. It is a very important learning step that if bypassed might create issues in the future. Additionally, some cases might surprise you in the sense that the defaults you had in mind won't work. I think what you described is what we want users to have in mind and get to, which will allow them to learn how to set up a CFD case without being in a way 'addicted' to BF.

P.S.: I wonder if some of these posts are helpful to be on the discourse site as well. Feels users can learn a lot by what you posted!

Kind regards, Theodore.

[DambronOlivier]

Hi @TheodoreGalanos ,

I built a component for my first point (draft). You can plug the points of the wind tunnel into it and visualize the grading. Let me know what you think.

GradingComponent.gh.zip

[mostaphaRoudsari]

@DambronOlivier, you will like this new component. Applying a custom area of interest is not implemented yet but for now it uses the bounding box of the geometries for the calculation.