Hello everyone,
I am searching for a good and general workflow to assign the global boundaries (Top,Bottom,North etc.) after importing the geometry (.f3grid) from Rhino/Griddle.
The command ‘zone face skin’ seperates the boundaries for every volume element I have built in Rhino, but this leads to the internal surfaces seen in the picture below (red surfaces).
One idea was to retrieve the max and min gridpoints and then assign the boundary conditions according to x_max/min, y_max/min and z_max/min, but I can’t find the code to find the max and min gridpoints of the model.
If you wish to not include internal faces when issuing the zone face skin command you can use the modifying keywords - zone face skin internal off. This will ignore internal faces when face grouping.
I may be misunderstanding the question, but assigning boundary conditions to face groups can be accomplished with the range logic. For example, assigning a zero-velocity condition to one of the sides of your model would look like this,
zone face velocity-normal 0.0 range group 'South1' or 'South2' or 'South3'
Hi,
as the topic is the selection of zone boundaries, I ask you if you know a way (fish function for example) to select the nodes of a zone group except the common nodes between this group and other zone groups. This is useful during a construction sequence to reset the displacements of the last activated zone group (which have no real meaning) without resetting the displacements at the nodes shared with already active groups.
It seems like the default value for internal is ‘off’, meaning that the issue encountered by Sen is not related to this option, as you suggested.
For him to apply the “zone face velocity-normal” with a range logic, he would have to manually identify which South (he seems to have many of them: South1, South2, South3, etc.) is actually an external boundary, to avoid applying velocities within (internally) for example.
Not sure how to fix this though… There are not many options with the face skin command. I played with break-angles and was not able to fix the issue either…
The problem might be that the coordinates of gridpoints from the 3rd mesh generator software have some round-off differences. This can be solved by a few steps and lines:
Manually query one gridpoints at a surface, write-down the coordinates, using a range like
“range position-x value1 tol value2” to redefine the face group, where value1 can be estimated from the query and value2 is just a suitable tolerance.