WindTunnelPar: gradXYZ input

[TheodoreGalanos]

I do not think that the gradXYZ will currently work (as it is intended in OF) with the input required at the moment.

The required information OF wants in multiple grading are the following:

• number of sections to be graded differently
• percentage and distribution of cells across the sections
• expansion ratio for each section

This information is required for each of the X, Y, and Z directions. To give an example, imagine we wish to grade our mesh in 3 sections: 1 before the geometry, 1 surrounding the geometry, 1 after the geometry. This would mean we will require in total 6 vectors for X and Y, like so:

X-grading:

(0.2 0.4 1)
(0.6 0.2 1)
(0.2 0.4 1)

Y-grading:

(0.3 0.45 1)
(0.4 0.15 1)
(0.3 0.45 1)

The Z-direction would depend on the user, below an example of a grading for the 10 first meters and the rest of the geometry (in a 100 meter high blockMesh):

(0.1 0.05 1)
(0.9 0.95 1.2)

Each vector represents: (percentage of X, Y, Z length, percentage of cells distributed, expansion ratio).

So in the typical really case described above the input would require 8 to 9 vectors. That's a bit hard to get with one go in grasshopper. I would propose that we perhaps allow a multipleGradingPar component as an input to this one, while have the default value of simpleGrading (1 1 1).

P.S.: Can't remember if we were supposed to enable multiple grading with this input. If instead it is meant to represent the simple grading parameters then renaming it to expansion ratio for XYZ would also do it. Then the multiple grading is a new input for future development.

Kind regards,
Theodore.

[mostaphaRoudsari]

@TheodoreGalanos gradXYZ here is the simple grading for blockMeshDict in x, y, z. Two questions. Do we have an example for multiple grading? Looks like we need two new components for simple grading and multiple grading which both can be connected to this input which can be renamed to grading?

[TheodoreGalanos]

Hi @mostaphaRoudsari ,

The above post can be considered as an example for multiple grading, in the sense that copy pasting the brackets in the proper place of any blockMesh would create a multiple grading. I will forward an actual blockMesh for you to test soon.

I was also just thinking about how to approach grading in terms of components. I think we should have a component for multiple grading and we should hide the simple grading completely (leave it as additional parameters perhaps). The reason for this is the simplicity of simple grading implementation in OF. It is literally the static grading ratio of sorts for all 3 orientations, moving from min to max coordinate. I have never ever used a simple grading different than (1 1 1) simply because it doesn't make much sense in any physical modeling. This can make things easier for us leaving simple grading as a default (editable through additional parameters option perhaps) and allowing the user to enable multiple grading if he/she wants.

As for the component itself for multiple grading I think it's a very good idea to have one indeed. The reason isn't just to make it easier for the user to apply it but once again to use Rhino/GH interface to allow for parametric-type grading. For example, there can be a rectange input in the component where the user could draw directly on Rhino canvas the boundaries on which the grading to be applied. BF can then automatically get the percentages off of this boundary and apply them to the grading. All the user does after that is to select the percentage of cells in each part. I'd have to test this but it is one possibility I guess. Another possibility could be to select the regions of multiple grading directly from the input geometries, much like we do for blockMesh. For example the user can choose a percentage or a distance before and after the geometry (in X and Y) in order to create the center region.

For the cell distribution, from my own experience, it would be amazing if we could find a way to allow the user to define size of cells and ratio of difference between regions, apart from simply percentages (much like we need to do for the blockMesh component). I think I have an excel sheet somewhere that (almost) does the same thing, I'll send it over as an example tomorrow.

Kind regards,
Theodore.

P.S.: The above might make more sense once I send over the blockMeshDict example.

[mostaphaRoudsari]

Hi @TheodoreGalanos! Thank you for the quick reply. I'm looking forward to your example file.

Assuming that blockMesh is always a box or can fit inside a box we can have the user to input UV values between 0 and 1 instead of real distance and visualize the regions as an output of WindTunnel and blockMeshDict. It will be something similar to evaluate surface/volume in Grasshopper.

[mostaphaRoudsari]