|
[Sponsors] |
March 9, 2013, 15:08 |
Block creation
|
#1 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
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.
__________________
Lefteris |
|
March 9, 2013, 16:56 |
|
#2 |
Senior Member
Chris Sideroff
Join Date: Mar 2009
Location: Ottawa, ON, CAN
Posts: 434
Rep Power: 22 |
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 |
|
March 9, 2013, 21:17 |
|
#3 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
Ah, thank you so much Chris! It was simplicity itself but I hadn't understood that point! Thank you!
__________________
Lefteris |
|
June 18, 2014, 14:44 |
|
#4 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
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
__________________
Lefteris |
|
June 22, 2014, 14:21 |
|
#5 |
Senior Member
John Chawner
Join Date: Mar 2009
Location: Fort Worth, Texas, USA
Posts: 275
Rep Power: 18 |
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.
__________________
John Chawner / jrc@pointwise.com / www.pointwise.com Blog: http://blog.pointwise.com/ on Twitter: @jchawner |
|
June 22, 2014, 21:50 |
|
#6 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
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
__________________
Lefteris |
|
July 14, 2014, 21:16 |
|
#7 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
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
__________________
Lefteris |
|
July 15, 2014, 08:46 |
|
#8 |
Senior Member
John Chawner
Join Date: Mar 2009
Location: Fort Worth, Texas, USA
Posts: 275
Rep Power: 18 |
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.
__________________
John Chawner / jrc@pointwise.com / www.pointwise.com Blog: http://blog.pointwise.com/ on Twitter: @jchawner |
|
July 15, 2014, 10:59 |
|
#9 |
Senior Member
David Garlisch
Join Date: Jan 2013
Location: Fidelity Pointwise, Cadence Design Systems (Fort Worth, Texas Office)
Posts: 307
Rep Power: 14 |
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. |
|
July 15, 2014, 22:38 |
|
#10 |
Senior Member
Lefteris
Join Date: Oct 2011
Location: UK
Posts: 337
Rep Power: 15 |
John, David,
Thank you for your answers. I think it's more clear now.
__________________
Lefteris |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
foamLog not solving for Ux, Uy, Uz | aerospain | OpenFOAM Post-Processing | 5 | April 18, 2012 10:01 |
[ICEM] Quest for seemingly simple Blocking (degenerate block) | la7low | ANSYS Meshing & Geometry | 0 | July 12, 2011 19:48 |
[Commercial meshers] Icem Mesh to Foam | jphandrigan | OpenFOAM Meshing & Mesh Conversion | 4 | March 9, 2010 02:58 |
blockMesh: block with 6 vertexes | dani | OpenFOAM | 3 | June 25, 2009 13:13 |
About block creation | Stefano Bertoldo | Siemens | 1 | March 27, 2001 19:16 |