# [ICEM] What's the difference between points and vertices?

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

December 29, 2020, 13:44
Solved - What's the difference between points and vertices?
#1
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Hi,

I kinda get that vertices are the equivalent of points when we're dealing with blocks (versus volumes) although I would like to have a deeper understanding of what these represent exactly.

But what if my geometry - an enclosure - contains vertices instead of points when I import it into Icem? Will that pose any problem when I create blocks? I know that at some point I've got to link geometry points to block vertices and curves to edges in order to make the blocks match the shape of the geometry. But if my geometry is already made of edges and vertices, will that correspondance still be possible?

If not, how do I replace edges and vertices by curves and points in SpaceClaim/DesignModeler without too much hassle? Also, I may be mistaken but it seems to me that these geometry editors automatically interpret 3D points and curves as vertices and edges.

By the way, the geometry in question is the 3D model of half an aircraft. That's a wing-body problem.

Thanks,

Edit: Solved. Refer to messages What's the difference between points and vertices? and What's the difference between points and vertices? for some interesting points.
Attached Images
 icem_skylon_1.jpg (65.8 KB, 17 views)

Last edited by Bubbly; January 2, 2021 at 11:35. Reason: Solved

 December 30, 2020, 02:04 #2 Senior Member   Kira Join Date: Nov 2020 Location: Canada Posts: 319 Rep Power: 4 Hello, From the ICEM User's Manual: Vertices are corner points of blocks, of which there are at least eight, that define a block. Points are the literal x, y, z point definitions. Blocks are a volume made up of vertices, edges and faces, but not points. So you may only define a block by vertices, not points. I know you can restore points in ICEM by going to Edit -> 'Mesh -> Facets'. Playing around with these edit options couldn't hurt. I cannot confidently offer you advice on how to do this is SpaceClaim/DM.

December 30, 2020, 06:41
#3
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by aero_head From the ICEM User's Manual: Vertices are corner points of blocks, of which there are at least eight, that define a block. Points are the literal x, y, z point definitions. Blocks are a volume made up of vertices, edges and faces, but not points. So you may only define a block by vertices, not points.
Yeah I saw that in the user's manual (p. 28 for reference). But I'd like to know if there's any paper that goes more in-depth regarding blocking. I know that blocks define topology whereas volumes give geometrical info but I'm yet to find theoretical resources that explicitely give a definition for what a block is instead of what a block is made of. You know, that's the turbulence paradigm
Quote:
 Originally Posted by aero_head I know you can restore points in ICEM by going to Edit -> 'Mesh -> Facets'. Playing around with these edit options couldn't hurt. I cannot confidently offer you advice on how to do this is SpaceClaim/DM.
Thanks for the suggestion, but when I click on 'Mesh -> Facets', the software rightly tells me that no mesh is currently loaded so I can't revert back to faceted data. Even if I could, though, I don't know if that's what I'm looking for because I would like my vertices to become points, my edges to become curves and faces to become surfaces. Right now, I think my best bet is to work with either SC or DM to import the correct geometrical info into Icem. I believe the problem stems from having a solid body, so I need to find a way to transform it into some other type of body that contains points and curves, but I don't know how and what I should do.

Edit: Okay, reflecting on what I just said in the last paragraph, I think I've got a rough understanding about what's happening: After importing my STP file into either SpaceClaim or DesignModeler, I usually create an enclosure around the aircraft's body which is the standard procedure to generate a fluid domain around the geometry in order to mesh it with Ansys Meshing. However, it seems to me that bodies are by definition made of vertices, edges and faces, and enclosures happen to be bodies so my best option would be to import the .step/.stp CAD geometry in Icem and create a bounding box around it. Please correct me if I'm wrong.

 December 30, 2020, 13:50 #4 Senior Member   M Join Date: Dec 2017 Posts: 374 Rep Power: 7 I suppose you can think of vertices as the 1D entities of the block, while points are 1D entities of the geometry.

December 30, 2020, 15:47
#5
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by AtoHM I suppose you can think of vertices as the 1D entities of the block, while points are 1D entities of the geometry.
Yes, I know that already. But I want to know how blocks are coded inside Icem, I want to know whether having a geometry made of vertices risks making things more difficult for me when I block the fluid domain, or not. I assume that the initial geometry should be made of points, curves and surfaces. If it is made of vertices and edges, I can't link these entities to the vertices and edges of subsequently created blocks, can I?

 December 31, 2020, 06:48 #6 Senior Member   M Join Date: Dec 2017 Posts: 374 Rep Power: 7 No idea how it is coded and I doubt you will find any resource on that. Anyway I do not see how you have vertices instead of points when importing any geometry into ICEM. If you import geometry, it will be points. If you import blocking, it will be vertices. Or do I miss something?

December 31, 2020, 08:52
#7
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by AtoHM No idea how it is coded and I doubt you will find any resource on that. Anyway I do not see how you have vertices instead of points when importing any geometry into ICEM. If you import geometry, it will be points. If you import blocking, it will be vertices. Or do I miss something?
This is what I expected, but if you have a look at the picture I joined in the original post, you'll see that points are referred to as vertices and curves are replaced by edges. Plus they're colored in green, which strongly suggests these are block features, which doesn't make any sense to me.

 January 1, 2021, 05:49 #8 Senior Member   M Join Date: Dec 2017 Posts: 374 Rep Power: 7 Interesting. Sorry didn't check out the image before. What file format are you using to transfer the geometry into ICEM? I always used step-files and never had any issues like yours.

 January 1, 2021, 12:07 #9 New Member   Join Date: Jun 2016 Location: France Posts: 16 Rep Power: 6 Happy new year! I'm using a .stp geometry but that's the first time I'm doing so. This file was shared over the internet so I don't really know how the author made it and which software he used. Do you reckon this might be the reason why the geometry contains vertices instead of points? Is there a way I can change that using, say, Solidworks and does it even matter in the end?

 January 2, 2021, 07:37 #10 Senior Member   Sebastian Engel Join Date: Jun 2011 Location: Germany Posts: 555 Rep Power: 17 ICEM has these three domains of entities: geomety, mesh, and premesh(blocking) - neglecting the non-cfd features. points, curves, and surfaces are the terminology for geometry entities, while vertex, edge, and block are entities of the premesh domain. This nomenclature has been chosen at some point of the development of ICEM. Do not consider it universally applicable. Other programs might use different words for the same kind of entity. In ICEM, each domain processing domain is only somewhat linked to each other. Its hierarchy is directional. The geometry is used to derive the mesh. If you change the geometry, such as scaling, the discreet mesh would change after recomputing it. But mesh operations cannot change the geometry. Premesh is practically an intermittent step between geometry and mesh. You could import a blocking without having a geometry in ICEM. I recall, there is a way to create a mesh without geometry. Only the associating features link premesh entities to the geometry entities. Anyhow, each entity can have labels which is different than internal sequential numbering. If the imported geometry used the label VERT123 for a geometry point, it is still a point for ICEM. It is likely that the original data format had these labels, or the converting algorithm has these prefixes hardcoded to label previously unlabeled entities. I have the impression, that the geometry shown in the screenshot does contain points, curves and surfaces. I am pretty sure, if you switch visibility of these entities in the model tree, you can confirm, that the curves called EDGE123 are just curves with a label. Bubbly, AtoHM and aero_head like this.

January 2, 2021, 10:08
#11
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by bluebase ICEM has these three domains of entities: geomety, mesh, and premesh(blocking) - neglecting the non-cfd features. points, curves, and surfaces are the terminology for geometry entities, while vertex, edge, and block are entities of the premesh domain. This nomenclature has been chosen at some point of the development of ICEM. Do not consider it universally applicable. Other programs might use different words for the same kind of entity.
Thanks for this very thorough answer. Nice to know. I thought these terms were a universal designation but turns out it's a bit of an arbitrary choice by the ICEM developers.

Quote:
 Originally Posted by bluebase In ICEM, each domain processing domain is only somewhat linked to each other. Its hierarchy is directional. The geometry is used to derive the mesh. If you change the geometry, such as scaling, the discreet mesh would change after recomputing it. But mesh operations cannot change the geometry. Premesh is practically an intermittent step between geometry and mesh. You could import a blocking without having a geometry in ICEM. I recall, there is a way to create a mesh without geometry. Only the associating features link premesh entities to the geometry entities.
This makes a lot of sense and it was worth repeating since one tends to think that meshes are somewhat automatically bound to the geometry until they remember what the association steps are for.

Quote:
 Originally Posted by bluebase [...] Anyhow, each entity can have labels which is different than internal sequential numbering. If the imported geometry used the label VERT123 for a geometry point, it is still a point for ICEM. It is likely that the original data format had these labels, or the converting algorithm has these prefixes hardcoded to label previously unlabeled entities. I have the impression, that the geometry shown in the screenshot does contain points, curves and surfaces. I am pretty sure, if you switch visibility of these entities in the model tree, you can confirm, that the curves called EDGE123 are just curves with a label.
Now this is news to me. I thought the software would be a bit smarter so as to label geometric or topological features correctly and bypass user input, but I guess there's no foolproof function to rename them automatically (since alternative labelling might be intended). Checking "geometry info" in the message box tells me that there are only prescribed points, curves and surfaces in the geometry. Once I start blocking, is there a way to discriminate edges from curves and vertices from points? Or do I have to simply assume the nature of these entities based on their color? Because everything is colored in green which looks a bit suspicious, and "show point/curve info" only tells me what the entity is called, which part it belongs to and where it is located (or its connectivity). But what you said eases my mind to some extent, because it is very unlikely that Icem would make dubious manipulations with the data and that only seems to be a labelling issue

 January 2, 2021, 11:21 #12 Senior Member   M Join Date: Dec 2017 Posts: 374 Rep Power: 7 Sebastian, great response. I too hadn't considered the labelling shown might be just derived from something in the file. Toggeling visibility of all the entities surely proofs what kind of entities ICEM consideres them as. I recognized this earlier, but was a bit distracted by the labelling: in the picture shown by Bubby, the entities named as vertices most certainly have the looks of points (big filled circles) and not verteces. Bubbly likes this.

January 2, 2021, 11:28
#13
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by AtoHM Sebastian, great response. I too hadn't considered the labelling shown might be just derived from something in the file. Toggeling visibility of all the entities surely proofs what kind of entities ICEM consideres them as. I recognized this earlier, but was a bit distracted by the labelling: in the picture shown by Bubby, the entities named as vertices most certainly have the looks of points (big filled circles) and not verteces.
Damn, that's right. I forgot that vertices are usually displayed as crosses while points are represented with filled circles.

January 2, 2021, 15:49
#14
Senior Member

Sebastian Engel
Join Date: Jun 2011
Location: Germany
Posts: 555
Rep Power: 17
Quote:
 Originally Posted by Bubbly Now this is news to me. I thought the software would be a bit smarter so as to label geometric or topological features correctly and bypass user input, but I guess there's no foolproof function to rename them automatically (since alternative labelling might be intended). Checking "geometry info" in the message box tells me that there are only prescribed points, curves and surfaces in the geometry. Once I start blocking, is there a way to discriminate edges from curves and vertices from points? Or do I have to simply assume the nature of these entities based on their color? Because everything is colored in green which looks a bit suspicious, and "show point/curve info" only tells me what the entity is called, which part it belongs to and where it is located (or its connectivity). But what you said eases my mind to some extent, because it is very unlikely that Icem would make dubious manipulations with the data and that only seems to be a labelling issue
In most cases you actually want to keep the labels from the original file. It usually helps to distinguish the geometry. But of course not every data format is designed to be used for simulations.

If you do not like the color of the geometry look into the model tree and select the respective part, in the context menu you can change the part's color. This will also change the color in the screen.

Quote:
 but I guess there's no foolproof function to rename them automatically (since alternative labelling might be intended)
I guess, it might be difficult to do this in a general way. But have a look at ICEM's scripting capabilities when you feel more advanced.

To keep it simple save the following code snippet as rename.tcl. Then run the script via File > Replay Script > Run from script > chose rename.tcl.
Code:
``` # Catch all entities
set pointlist [ic_geo_get_objects point]
set crvlist [ic_geo_get_objects curve]

# Rename them assuming original names have the format VERT123, and EDGE123
foreach pnt \$pointlist {
ic_geo_set_name point \$pnt [regsub -- "VERT(.*)" \$pnt "pnt.\\1"]  1 1
}

foreach crv \$crvlist {
ic_geo_set_name curve \$crv [regsub -- "EDGE(.*)" \$crv "crv.\\1"]  1 1
}```
I haven't tested this code since i won't be back in the office for another few days.
If it does not work, it is likely between these brackets: [regsub ... ]. It is a regular expression to replace the respective strings VERT and EDGE with "pnt." and "crv.", respectively.

The first of the tailing 1 will autorename the suggested new name if it finds a duplicate. The second 1 will warns you if the autorename occurs.

To understand all of it, a tutorial/course for the interpreter language tcl is necessary.

Best,
Sebastian

January 2, 2021, 16:01
#15
New Member

Join Date: Jun 2016
Location: France
Posts: 16
Rep Power: 6
Quote:
 Originally Posted by bluebase In most cases you actually want to keep the labels from the original file. It usually helps to distinguish the geometry. But of course not every data format is designed to be used for simulations. If you do not like the color of the geometry look into the model tree and select the respective part, in the context menu you can change the part's color. This will also change the color in the screen. I guess, it might be difficult to do this in a general way. But have a look at ICEM's scripting capabilities when you feel more advanced. To keep it simple save the following code snippet as rename.tcl. Then run the script via File > Replay Script > Run from script > chose rename.tcl. Code: ``` # Catch all entities set pointlist [ic_geo_get_objects point] set crvlist [ic_geo_get_objects curve] # Rename them assuming original names have the format VERT123, and EDGE123 foreach pnt \$pointlist { ic_geo_set_name point \$pnt [regsub -- "VERT(.*)" \$pnt "pnt.\\1"] 1 1 } foreach crv \$crvlist { ic_geo_set_name curve \$crv [regsub -- "EDGE(.*)" \$crv "crv.\\1"] 1 1 }``` I haven't tested this code since i won't be back in the office for another few days. If it does not work, it is likely between these brackets: [regsub ... ]. It is a regular expression to replace the respective strings VERT and EDGE with "pnt." and "crv.", respectively. The first of the tailing 1 will autorename the suggested new name if it finds a duplicate. The second 1 will warns you if the autorename occurs. To understand all of it, a tutorial/course for the interpreter language tcl is necessary. Best, Sebastian
Thanks a million for the code, that's more than I was asking for! I'll try it out and will let you know. Now that I know there's seemingly nothing wrong with the geometry, I feel much more confident about meshing it.

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post [snappyHexMesh] layer not added Rasmusiwersen OpenFOAM Meshing & Mesh Conversion 1 January 2, 2020 09:43 [snappyHexMesh] SHM Layer Addition Phase dickcruz OpenFOAM Meshing & Mesh Conversion 4 November 1, 2018 07:05 [snappyHexMesh] .STL: non-closed manifold surface giulio.topazio OpenFOAM Meshing & Mesh Conversion 32 November 25, 2016 03:15 [snappyHexMesh] No layers in a small gap bobburnquist OpenFOAM Meshing & Mesh Conversion 6 August 26, 2015 09:38 [snappyHexMesh] crash sHM H25E OpenFOAM Meshing & Mesh Conversion 11 November 10, 2014 11:27

All times are GMT -4. The time now is 04:03.

 Contact Us - CFD Online - Privacy Statement - Top