Subdomains created when using gridmerge

Hello,

I am attempting to create a model via the mesh commands within MATLAB. The model will need to be run using OpenFOAM since I have to run a turbulence model. However, when I create my grid using ringgrid, holegrid, and rectgrid, it makes each grid type a separate domain even after using gridmerge. How can I get around this so that I can use OpenFOAM? I would prefer to avoid creating the geometry and then use tet meshing rather than using quadrilaterals.

StoneFrench wrote

... when I create my grid using ringgrid, holegrid, and rectgrid, it makes each grid type a separate domain even after using gridmerge.

After gridmerge, when you have your grid struct, for example "grid" it should be enough to do:

  grid.s(:) = 1;

to set the subdomain grid cell index to "1" (grid.s is a row vector with one integer for each grid cell indicating the corresponding subdomain number). Note that this does not affect boundary numbering so you would still be left with 14 external boundary segments in this case, to automatically renumber boundaries you can use the "gridbdr" function.

Also note that automatic unstructured quad meshing is available with the "gmsh" and "built-in" mesh generators in 2D (from version 1.14.1). However, manually assembling a quad grid like you have done most likely will get you the best control and quality.

Can you provide some clarification on the use of gridbdr for renaming the boundaries? I looked up the inputs for gridbdr and used gridbdr(grid.p,grid.c,grid.a); to call out the p,c,a terms. However this doesn't appear to reset the boundary overcount. Looking at the fix_bdr portion of the inputs it states that it is a logical but does not state for what exactly? Lastly, looking at b0, I am assuming this is the input for the boundaries that the user intends to merge back together based on the fix_bdr logic condition?



Second, I attempted to run the model with the extra boundaries and I am running into an issue I did not expect. Even though the end of the model is considered to be outflow/pressure=0, the flow is not traveling within the domain at all after being input at the opposite end. I confirmed my input and outputs were correct but it appears to be acting as if the model has no outflow parameters. Please let me know what your thoughts are.

StoneFrench wrote

Can you provide some clarification on the use of gridbdr for renaming the boundaries? I looked up the inputs for gridbdr and used gridbdr(grid.p,grid.c,grid.a); to call out the p,c,a terms. However this doesn't appear to reset the boundary overcount. Looking at the fix_bdr portion of the inputs it states that it is a logical but does not state for what exactly? Lastly, looking at b0, I am assuming this is the input for the boundaries that the user intends to merge back together based on the fix_bdr logic condition?

The gridbdr syntax would something of the form:

  th = 50;   % Separation angle (degrees).
  grid.b = gridbdr(grid.p, grid.c, grid.a, atan(th*pi/180));

The angle "th" will determine the effective angle at which the boundaries will be recomputed. "fix_bdr" is a logical or boolean scalar (0/1) that bypasses the boundary splitting and assigns all boundary edges/faces to boundary 1, effectively "grid.b(3,:) = 1;".

StoneFrench wrote

Second, I attempted to run the model with the extra boundaries and I am running into an issue I did not expect. Even though the end of the model is considered to be outflow/pressure=0, the flow is not traveling within the domain at all after being input at the opposite end. I confirmed my input and outputs were correct but it appears to be acting as if the model has no outflow parameters. Please let me know what your thoughts are.

From only the picture, it looks like the case where only the initial conditions have been returned (as can happen if the solver fails for some reason).

Thank you for the assistance. This helped.

With kind regards,

-Stone French