[Aeronautics El. K.]

Hello all!

I'm trying to make an unstructured block by assembling the 6 domains that comprise it. The result is an empty block with 0 cells. Does anyone have any idea why this is happening?

Thank you.

[cnsidero]

That's the first step. The second step is to initialize the block. Select the block and click the Initialize button on the toolbar or go to the Grid > Solve ... menu and click Initialize there.

-Chris

Originally Posted by Aeronautics El. K.

Hello all!

I'm trying to make an unstructured block by assembling the 6 domains that comprise it. The result is an empty block with 0 cells. Does anyone have any idea why this is happening?

Thank you.

[Aeronautics El. K.]

Ah, thank you so much Chris! It was simplicity itself but I hadn't understood that point! Thank you!

Originally Posted by cnsidero

That's the first step. The second step is to initialize the block. Select the block and click the Initialize button on the toolbar or go to the Grid > Solve ... menu and click Initialize there.

-Chris

[Aeronautics El. K.]

Hello again.

I chose to post in this thread instead of creating a new one since the topic is similar.

So, I have created several unstructured domains (I used the advancing front method) and then assembled them in a block. However, block initialization fails with the following message "One or more entities could not be initialized".

I changed the domains and I used the Delaunay method but again the initialization failed.
I flipped the direction of the surface normals but the result was the same.

Right now, I have no idea what I'm doing wrong. I would appreciate it someone could help me.

Lefteris

[jchawner]

When unstructured blocks can't be initialized, it's (almost) always a result of some problem with the surface mesh. For example, there may be widely varying cell sizes where two faces come together. So the first thing I'd do is check the quality of the surface meshes and see where that takes you.

If that is still a problem, contact our tech support engineers at support@pointwise.com.

Best Regards

P.S. Surface normals should always point into the block.

[Aeronautics El. K.]

Hello John,

Thank you for the reply!

Meanwhile, I was experimenting and I realised that I could follow a different strategy.

So what I did was to make an unstructured mech at the tip of the wing using the T-rex. In addition, I used the extrusion method to make a structured C-type domain around the aerofoil and finally, I just translated the domains. I ended up with 2 structured block with hexaedra and 1 block with prisms.

MUCH much simpler than what I was trying to do initially and at a fraction of time. I provide some pictures to take a look if you care at all of course

Kind regards,

Lefteris

[Aeronautics El. K.]

Hello all.

Me and my nacelle again... I've entered the final phase of meshing and I have one more question, silly probably.

I have attached a figure to illustrate the geometry of the nacelle. It consists of an outer cell, an inner part with a clearance in between which is filled by a "lip" in the inlet but they end at the same connector at the outlet.
I have oriented all structured domains to be right handed and the normals of all unstructured domains are pointing outwards (or to put differently, towards the inside of the block that is going to be created).

Now I want to create the block inside the nacelle. The (2) domains there are structured. This means that they should be right handed like all the other structured domains so that the normals are pointing into the block, right? Can someone confirm this please? John already told me so but I'm kind of confused in this case.

Now I'll pose the question in a different way. The tutorial with the Boeing nacelle is very informative and shows a very simple way to create the block. But let's say that someone, for whatever reason, instead of following that procedure, creates straight from the beginning unstructured domains at the inlet and the outlet. Then the connectors at the boundaries will be shared by 3 domains. Therefore those connectors will be non-manifold. Firstly, what's the implication of having non-manifold connectors?

Secondly, given that there would be different blocks on either side of those unstructured domains (one inside the engine and one on the outside) where should the normals be pointing in this case? Is there a way to have two normals pointing in opposite directions or you need two domains oriented accordingly?

Thanks for taking the time to even read my long posts!

Lefteris

[jchawner]

Hello:

If you're making a 3D structured block, the orientation of its bounding domains is largely irrelevant. All that matters is the orientation of their use in the block. I hope that makes sense. If it's simpler to think of it in 2D, a connector has a beginning and an end. But that direction doesn't matter to the domain its used in. What matters is the connector's usage in the domain.

Non-manifold connectors imply nothing about the eventual ability to create blocks. Imagine a Rubik's cube. On the interior there will be connectors used by 4 domains and 4 blocks each. Not a problem.

As for the orientation of the domain at the entrance to the nacelle, it can be used in two blocks. But what matters is the orientation of each block's face, not the orientation of the domain. Going back to my first statement, the domain has an orientation unto itself. What matters to the block is the orientation of its face(s). The two are different.

I hope this clarifies these topology issues.

[dgarlisch]

I hope this diagram helps understand the underlying structure of domains and blocks in Pointwise.

This example is for connectors and domains in a 2D grid*.

However, there is a parallel relationship between connectors, domains, and blocks in 3D grids.

* for clarity, I did not include the boundary connectors and faces in the diagram.

[Aeronautics El. K.]

John, David,

Thank you for your answers. I think it's more clear now.