Re: [iso2mesh-users] meshing porous media from micro CT scan data

[Qianqian Fang]

On 09/10/2012 06:06 AM, karthik kumar wrote:

Hello Dr. Fang,

hi Karthik

glad to know that you found iso2mesh useful.

First of all, congratulations for developing (an open source-based) really useful image-based meshing package. I have been using micro-CT to generate meshes of wide variety of porous media such as metal foams and sintered packed beds, for analyzing flow and heat transfer through them. So far, I have explored numerous available packages, e.g., amira, mimics, 3-matic, and simpleware to name a few. 

For the simulations I perform, I usually need a mesh in the fluid (empty, porous) region, and a mesh in the solid region (my solid+fluid image in 3d form a cuboid), along with a conformal (matching) mesh at the interface region separating the two. Further,I would prefer the bounding domain (6 faces each for the solid and pore domains) to be as flat as possible, so that I can later identify these easily, for applying my boundary conditions. So far, for this process, I have been successfully using a commercial package, simpleware, and now would like to switch to your open-source package, iso2mesh, as it provides a much wider flexibility, and the access to the original source code which is pretty well documented.

With this intention, I have been playing with iso2mesh for about 2 weeks now, and have also been following this group closely, along with the daily updates you make to the SVN repository. I would like to describe my experience thus far, and would be glad if you could comment and suggest a better workflow.

I begin by importing my image stack ( a grayscale or binary stack), and then use a similar approach as in the head+brain meshing demo. The only difference I find is that, in my case, the two domains are not disconnected and are not arranged such that one encloses the other completely. Instead, for my case, the two domains are inter-penetrating (6 x 2 + 1 = 13 surfaces overall). I have been playing with the various available meshing options, but with not much success. Though I see that the 'cgalmesh' option never fails, the generated mesh always seems to cause me problems, when I try to use it with my fluid flow/heat transfer solver (Fluent).

I am curious what kind of error you had encountered
with the 'cgalmesh' output. The only issue I would
expect from 'cgalmesh' is that it may not be able to
extract all components if they are disjoint, see my
report at CGAL mailing list:

http://cgal-discuss.949826.n4.nabble.com/missing-objects-when-meshing-a-3D-image-with-multiple-disconnected-inclusions-td3349283.html

but otherwise, it should work robustly. I am curious what
you got.

The other options however, such as 'simplify' and 'tetgen' based options, continuously fail, with the most common error, "two subfaces ... are found intersecting each other'.

However, I have been successful in doing one thing though: When I pad my solid+pore region first with some pore pixels and then with the background pixels (so as to mimic the head+brain demo case, in which we have a background, head and brain parts, one enclosed in the other, in order), I could generate a valid mesh for the both solid+pore domains (with the obvious exception that this time, the generated pore domain is my actual pore domain+padded boundary on the edges). For this, I had used the 'cgalsurf' option, but again, I am not sure if I was lucky for that one particular case or if it will always work fine. Though I can live with this approach for now, it would be great if I can just mesh my domain without the added boundaries, i.e., mesh the solid+pore region cuboid, with matching mesh at the interface.

I can share my test data with you, if you would like to have a brief look at it. 

It can be easier to diagnose if you can send me your
data, even a small section. Some screenshots of the
mesh/domain are helpful too.

Also, after much deliberation and playing around, I found the following workflow successful (and most useful), for all those trying to export the volume mesh generated by iso2mesh to fluent:

1) use saveabaqus.m to save the mesh generated by iso2mesh as an abaqus input file. (I had to change the element type of MeshTetra from S4R to C3D4, as the previous one was creating shell elements, and not volume elements. C3D4 seemed to create valid tetra elements. Dr. Fang, you may fix this in your code, upon further approval from other users.

I don't know much about ABAQUS element types. Is it
as simple as changing the TYPE field from S4R to C3D4?

2)Then use import abaqus input file option in fluent. At this point, I found that a bunch of different things can happen, depending on the mesh quality, etc I guess. But for me, for the most part, fluent was able to generate internal surfaces, etc by default. So, if you are lucky, you can skip the step 2.5 below and proceed with the simulation. We still need separate parts for setting the boundary conditions though.

so, basically you were only using iso2mesh to generate
surface meshes, why not do volumetric meshing inside
iso2mesh?

2.5) So, if there are any problems with the above step, or for creating boundaries from the existing mesh (for applying the boundary conditions), I found ICEM-CFD to be really useful. Simply import the abaqus mesh into ICEM, and first do a mesh-check. With this, it automatically identifies the internal faces (interface), i.e. the faces separating the two parts. Further, you can create additional boundaries using the create--> part option, such as the inlets, outlets etc from the existing surface mesh. Selections based on angle (work best if the boundaries are flat) or those based on location seemed to work the best. Be sure to only include 2d elements if you just want to create parts for applying Boundary conditions. Actually, ICEM can export the mesh in a number of solver formats, but beware, some of the export options require additional licenses.

in the svn, iso2mesh has incorporated an open-source
tool to repair surfaces:

http://code.google.com/p/meshfix/

a limitation of meshfix is that it can only repair a single closed
surface, but not multiple/intersecting ones. To try this on your
data, you can run meshcheckrepair(...,'meshfix').

3) Then you can perform the mesh check again, to be sure if the parts were created correctly, mesh is devoid of any other problems, etc, and export the processed mesh to fluent. (ICEM can also process the mesh, such as smoothing, coarsening  etc, but I guess it is always better to do this processing in iso2mesh).

instead of ICEM, which I've never used before, the open-source
tool meshlab also supports self-intersection removal,although,
sometimes the repaired surface can present self-intersecting
elements again.


Qianqian

Regards,

Karthik Bodla

--
You received this message because you are subscribed to the Google Groups "iso2mesh-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/iso2mesh-users/-/nEtMpAVoiUkJ.
To post to this group, send email to iso2mes...@googlegroups.com.
To unsubscribe from this group, send email to iso2mesh-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iso2mesh-users?hl=en.

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[karthik kumar]

Dr. Fang,

Thanks for your quick reply. So I do not get any error per se, while using Cgalmesh (at least the matlab script says meshing got completed successfully). It is only after I load it is fluent that fluent reports it is a bad mesh. The most common error is that fluent reports that the mesh has some degenerate vertices, which I am not sure what exactly means. I am guessing by degenerate it means co-linear vertices (for face elements) and/or co-planar vertices for volume elements. Further, technically, in fluent I should be able to separate out my solid and pore domain meshes, though I mesh them together, but with the meshes from cgalmesh, it fails saying there are degenerate faces and it cannot separate the mesh. 

I have included a small sample set (75 images of 75 x 75 pixels each) of a binary solid+pore domain. Here, the pixels with value = 3 correspond to my solid space, while the rest of the pixels are my pore space. Please have a look at it and suggest a suitable workflow. I first read them and convert them such as in the head+brain tutorial. That is, I change solid pixels to 1s and the fluid pixels to 2s and then pad them if I need (sample import script also attached for clarification). I have also included a sample binary image (white pixels-solid, black-pore). This images are originally jagged as you can see, but before importing I first process (gaussian filter 3d+thresholding+3d particle identification) them in ImageJ and then extract the labelled image. I ideally want only 2 labels, one for the solid and one for the pore space (mine is a bi-continuous domain in 3-dimensions, so technically i should not have 'loose' particles), so in the import_files.m file I achieve this by resetting all disjoint solid pixels to take the pore space value. The images I included in the zip file are after this image processing, i.e., in them value 3 pixels are solid and rest all are pore.

I do not know much about abaqus either, but the fix I found was based on how ICEM CFD (mesh processor) recognized the mesh based on S4R and C3D4. When I used S4R, I found that ICEM thinks all elements are shell elements, i.e., the mesh, according to it only has triangular shells (S3R) and 4-node (quadrangular?) shells (S4R). It failed to recognize that the 4-node elements are actually tetrahedral volumes. But, when I changed it to C3D4, ICEM immediately recognized the domain to have planar face elements (triangles) and volumetric tetrahedral elements! In fact, even fluent recognized the abaqus mesh directly (fluent has a default abaqus mesh import option), with this change. But again, as I have mentioned, it might be better to get it checked by others as well.

No, I am actually using both the surface and volumetric meshes generated by Iso2mesh, and not just the surface mesh. What I am using ICEM-CFD for, is to define my boundaries where I can apply my boundary conditions for the fluid and heat transfer simulations. Basically, unlike solid solvers, which are pretty much node based, fluid solvers need boundary condition on faces (more likely, face-groups) and so the natively exported mesh from iso2mesh lacks these face-group definitions. It is for this grouping that I use ICEM-CFD. Also, ICEM CFD can readily export the mesh, along with these groups in fluent readable .msh format. So, unless there is a more straight forward way to define these and export, I think it is better for fluent users to use this workflow.

Thanks,

Karthik 

On Monday, September 10, 2012 6:06:59 AM UTC-4, karthik kumar wrote:

Hello Dr. Fang,

First of all, congratulations for developing (an open source-based) really useful image-based meshing package. I have been using micro-CT to generate meshes of wide variety of porous media such as metal foams and sintered packed beds, for analyzing flow and heat transfer through them. So far, I have explored numerous available packages, e.g., amira, mimics, 3-matic, and simpleware to name a few. 

For the simulations I perform, I usually need a mesh in the fluid (empty, porous) region, and a mesh in the solid region (my solid+fluid image in 3d form a cuboid), along with a conformal (matching) mesh at the interface region separating the two. Further,I would prefer the bounding domain (6 faces each for the solid and pore domains) to be as flat as possible, so that I can later identify these easily, for applying my boundary conditions. So far, for this process, I have been successfully using a commercial package, simpleware, and now would like to switch to your open-source package, iso2mesh, as it provides a much wider flexibility, and the access to the original source code which is pretty well documented.

With this intention, I have been playing with iso2mesh for about 2 weeks now, and have also been following this group closely, along with the daily updates you make to the SVN repository. I would like to describe my experience thus far, and would be glad if you could comment and suggest a better workflow.

I begin by importing my image stack ( a grayscale or binary stack), and then use a similar approach as in the head+brain meshing demo. The only difference I find is that, in my case, the two domains are not disconnected and are not arranged such that one encloses the other completely. Instead, for my case, the two domains are inter-penetrating (6 x 2 + 1 = 13 surfaces overall). I have been playing with the various available meshing options, but with not much success. Though I see that the 'cgalmesh' option never fails, the generated mesh always seems to cause me problems, when I try to use it with my fluid flow/heat transfer solver (Fluent). The other options however, such as 'simplify' and 'tetgen' based options, continuously fail, with the most common error, "two subfaces ... are found intersecting each other'.

However, I have been successful in doing one thing though: When I pad my solid+pore region first with some pore pixels and then with the background pixels (so as to mimic the head+brain demo case, in which we have a background, head and brain parts, one enclosed in the other, in order), I could generate a valid mesh for the both solid+pore domains (with the obvious exception that this time, the generated pore domain is my actual pore domain+padded boundary on the edges). For this, I had used the 'cgalsurf' option, but again, I am not sure if I was lucky for that one particular case or if it will always work fine. Though I can live with this approach for now, it would be great if I can just mesh my domain without the added boundaries, i.e., mesh the solid+pore region cuboid, with matching mesh at the interface.

I can share my test data with you, if you would like to have a brief look at it.  

Also, after much deliberation and playing around, I found the following workflow successful (and most useful), for all those trying to export the volume mesh generated by iso2mesh to fluent:

1) use saveabaqus.m to save the mesh generated by iso2mesh as an abaqus input file. (I had to change the element type of MeshTetra from S4R to C3D4, as the previous one was creating shell elements, and not volume elements. C3D4 seemed to create valid tetra elements. Dr. Fang, you may fix this in your code, upon further approval from other users.

2)Then use import abaqus input file option in fluent. At this point, I found that a bunch of different things can happen, depending on the mesh quality, etc I guess. But for me, for the most part, fluent was able to generate internal surfaces, etc by default. So, if you are lucky, you can skip the step 2.5 below and proceed with the simulation. We still need separate parts for setting the boundary conditions though.

2.5) So, if there are any problems with the above step, or for creating boundaries from the existing mesh (for applying the boundary conditions), I found ICEM-CFD to be really useful. Simply import the abaqus mesh into ICEM, and first do a mesh-check. With this, it automatically identifies the internal faces (interface), i.e. the faces separating the two parts. Further, you can create additional boundaries using the create--> part option, such as the inlets, outlets etc from the existing surface mesh. Selections based on angle (work best if the boundaries are flat) or those based on location seemed to work the best. Be sure to only include 2d elements if you just want to create parts for applying Boundary conditions. Actually, ICEM can export the mesh in a number of solver formats, but beware, some of the export options require additional licenses.

3) Then you can perform the mesh check again, to be sure if the parts were created correctly, mesh is devoid of any other problems, etc, and export the processed mesh to fluent. (ICEM can also process the mesh, such as smoothing, coarsening  etc, but I guess it is always better to do this processing in iso2mesh).

Regards,

Karthik Bodla

[karthik kumar]

sorry, forgot to attach the actual script I use for meshing. I am including it here (sinter_meshing.m).

[Qianqian Fang]

On 09/10/2012 01:44 PM, karthik kumar wrote:

Dr. Fang,

Thanks for your quick reply. So I do not get any error per se, while using Cgalmesh (at least the matlab script says meshing got completed successfully). It is only after I load it is fluent that fluent reports it is a bad mesh. The most common error is that fluent reports that the mesh has some degenerate vertices, which I am not sure what exactly means. I am guessing by degenerate it means co-linear vertices (for face elements) and/or co-planar vertices for volume elements. Further, technically, in fluent I should be able to separate out my solid and pore domain meshes, though I mesh them together, but with the meshes from cgalmesh, it fails saying there are degenerate faces and it cannot separate the mesh.

CGAL tools generate meshes based on mesh quality
criteria. It keep refining a mesh until some specified quality
bounds are met. So it is impossible for cgalmesh/cgalsurf
to generate degenerated elements. This really sounds
to me like you have incorrectly exported your mesh, likely
including the unwanted region ID column. Can you
double check and make sure you only export node(:,1:3)
and elem(:,1:4)?

I have included a small sample set (75 images of 75 x 75 pixels each) of a binary solid+pore domain. Here, the pixels with value = 3 correspond to my solid space, while the rest of the pixels are my pore space. Please have a look at it and suggest a suitable workflow. I first read them and convert them such as in the head+brain tutorial. That is, I change solid pixels to 1s and the fluid pixels to 2s and then pad them if I need (sample import script also attached for clarification). I have also included a sample binary image (white pixels-solid, black-pore). This images are originally jagged as you can see, but before importing I first process (gaussian filter 3d+thresholding+3d particle identification) them in ImageJ and then extract the labelled image. I ideally want only 2 labels, one for the solid and one for the pore space (mine is a bi-continuous domain in 3-dimensions, so technically i should not have 'loose' particles), so in the import_files.m file I achieve this by resetting all disjoint solid pixels to take the pore space value. The images I included in the zip file are after this image processing, i.e., in them value 3 pixels are solid and rest all are pore.

I tried your script, it worked fine, except that your
mesh density is really high. I normally avoid doing
this because your mesh accuracy is bounded by
the voxel size. A mesh denser than the voxels
does not gain much, but takes much longer to
process. If I really need a fine mesh (for example
the stability condition requires), I will split the
process to v2s and s2m and insert smoothsurf
in between; or I convert the original mesh into
gray-scale and use v2s('cgalsurf') to extract the
smooth surface.

in any case, is this mesh usable at all?

I do not know much about abaqus either, but the fix I found was based on how ICEM CFD (mesh processor) recognized the mesh based on S4R and C3D4. When I used S4R, I found that ICEM thinks all elements are shell elements, i.e., the mesh, according to it only has triangular shells (S3R) and 4-node (quadrangular?) shells (S4R). It failed to recognize that the 4-node elements are actually tetrahedral volumes. But, when I changed it to C3D4, ICEM immediately recognized the domain to have planar face elements (triangles) and volumetric tetrahedral elements! In fact, even fluent recognized the abaqus mesh directly (fluent has a default abaqus mesh import option), with this change. But again, as I have mentioned, it might be better to get it checked by others as well.

I just committed this change in the SVN:

http://iso2mesh.svn.sourceforge.net/viewvc/iso2mesh?view=revision&revision=388

I invite other users to test it and let me know if this
works.

No, I am actually using both the surface and volumetric meshes generated by Iso2mesh, and not just the surface mesh. What I am using ICEM-CFD for, is to define my boundaries where I can apply my boundary conditions for the fluid and heat transfer simulations. Basically, unlike solid solvers, which are pretty much node based, fluid solvers need boundary condition on faces (more likely, face-groups) and so the natively exported mesh from iso2mesh lacks these face-group definitions. It is for this grouping that I use ICEM-CFD. Also, ICEM CFD can readily export the mesh, along with these groups in fluent readable .msh format. So, unless there is a more straight forward way to define these and export, I think it is better for fluent users to use this workflow.

for boundary faces, you may try volface.
It can extract the exterior face from a
tetrahedral mesh. For example, you can do the following:

f1=volface(elem(elem(:,5)==1,1:4)); % surface for region 1
f2=volface(elem(elem(:,5)==2,1:4)); % surface for region 2
f3=volface(elem(:,1:4)); % exterior surface for both regions

f12=[f1 ones(size(f1,1),1); ...
         f2 ones(size(f2,1),1)*2];  % surface merging both regions, last column is the label

[f3map,f3loc]=ismember(sort(f3,2),sort(f12(:,1:3),2),'rows');  % look up f3 in f12

face=f12(f3loc,:);  % get the new "f3" with region labels
plotmesh(node(:,1:3),face,'z<40');


Qianqian

Thanks,

Karthik 

On Monday, September 10, 2012 6:06:59 AM UTC-4, karthik kumar wrote:

Hello Dr. Fang,

First of all, congratulations for developing (an open source-based) really useful image-based meshing package. I have been using micro-CT to generate meshes of wide variety of porous media such as metal foams and sintered packed beds, for analyzing flow and heat transfer through them. So far, I have explored numerous available packages, e.g., amira, mimics, 3-matic, and simpleware to name a few. 

For the simulations I perform, I usually need a mesh in the fluid (empty, porous) region, and a mesh in the solid region (my solid+fluid image in 3d form a cuboid), along with a conformal (matching) mesh at the interface region separating the two. Further,I would prefer the bounding domain (6 faces each for the solid and pore domains) to be as flat as possible, so that I can later identify these easily, for applying my boundary conditions. So far, for this process, I have been successfully using a commercial package, simpleware, and now would like to switch to your open-source package, iso2mesh, as it provides a much wider flexibility, and the access to the original source code which is pretty well documented.

With this intention, I have been playing with iso2mesh for about 2 weeks now, and have also been following this group closely, along with the daily updates you make to the SVN repository. I would like to describe my experience thus far, and would be glad if you could comment and suggest a better workflow.

I begin by importing my image stack ( a grayscale or binary stack), and then use a similar approach as in the head+brain meshing demo. The only difference I find is that, in my case, the two domains are not disconnected and are not arranged such that one encloses the other completely. Instead, for my case, the two domains are inter-penetrating (6 x 2 + 1 = 13 surfaces overall). I have been playing with the various available meshing options, but with not much success. Though I see that the 'cgalmesh' option never fails, the generated mesh always seems to cause me problems, when I try to use it with my fluid flow/heat transfer solver (Fluent). The other options however, such as 'simplify' and 'tetgen' based options, continuously fail, with the most common error, "two subfaces ... are found intersecting each other'.

However, I have been successful in doing one thing though: When I pad my solid+pore region first with some pore pixels and then with the background pixels (so as to mimic the head+brain demo case, in which we have a background, head and brain parts, one enclosed in the other, in order), I could generate a valid mesh for the both solid+pore domains (with the obvious exception that this time, the generated pore domain is my actual pore domain+padded boundary on the edges). For this, I had used the 'cgalsurf' option, but again, I am not sure if I was lucky for that one particular case or if it will always work fine. Though I can live with this approach for now, it would be great if I can just mesh my domain without the added boundaries, i.e., mesh the solid+pore region cuboid, with matching mesh at the interface.

I can share my test data with you, if you would like to have a brief look at it.  

Also, after much deliberation and playing around, I found the following workflow successful (and most useful), for all those trying to export the volume mesh generated by iso2mesh to fluent:

1) use saveabaqus.m to save the mesh generated by iso2mesh as an abaqus input file. (I had to change the element type of MeshTetra from S4R to C3D4, as the previous one was creating shell elements, and not volume elements. C3D4 seemed to create valid tetra elements. Dr. Fang, you may fix this in your code, upon further approval from other users.

2)Then use import abaqus input file option in fluent. At this point, I found that a bunch of different things can happen, depending on the mesh quality, etc I guess. But for me, for the most part, fluent was able to generate internal surfaces, etc by default. So, if you are lucky, you can skip the step 2.5 below and proceed with the simulation. We still need separate parts for setting the boundary conditions though.

2.5) So, if there are any problems with the above step, or for creating boundaries from the existing mesh (for applying the boundary conditions), I found ICEM-CFD to be really useful. Simply import the abaqus mesh into ICEM, and first do a mesh-check. With this, it automatically identifies the internal faces (interface), i.e. the faces separating the two parts. Further, you can create additional boundaries using the create--> part option, such as the inlets, outlets etc from the existing surface mesh. Selections based on angle (work best if the boundaries are flat) or those based on location seemed to work the best. Be sure to only include 2d elements if you just want to create parts for applying Boundary conditions. Actually, ICEM can export the mesh in a number of solver formats, but beware, some of the export options require additional licenses.

3) Then you can perform the mesh check again, to be sure if the parts were created correctly, mesh is devoid of any other problems, etc, and export the processed mesh to fluent. (ICEM can also process the mesh, such as smoothing, coarsening  etc, but I guess it is always better to do this processing in iso2mesh).

Regards,

Karthik Bodla

--

You received this message because you are subscribed to the Google Groups "iso2mesh-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/iso2mesh-users/-/f8DVlhY-sKwJ.

To post to this group, send email to iso2mes...@googlegroups.com.
To unsubscribe from this group, send email to iso2mesh-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iso2mesh-users?hl=en.

[karthik kumar]

Dr. Fang,

I have been using saveabaqus.m for exporting the mesh and I just rechecked it again. It just uses node(:,1:3), face(:,1:3) and elem(:,1:4), while picking up the labels from face's (or elem's) last column, so I don't know what the issue is.  

Ya, I do understand your concern that my mesh is smoother (denser) than my original pixels. The settings in the file just reflect one set of parameters, and I have been playing with them a lot lately. I actually followed your advise from an other post, where I think you suggested a smaller opt.radbound (don't remember the exact post). Did you try the script with other options, say 'cgalsurf' or 'simplify'. For me, they seem to fail continuously, and only worked when I had padded pixels as I mentioned earlier. Thanks for the boundary face identification script. I will now try it.

Regards,

[karthik kumar]

Dr. Fang,
I am attaching a warning message from fluent when i read in the generated abaqus mesh. The mesh is successfully read in, with the change C3D4, as I mentioned earlier. We can see 5 zones, with the 'default_interiors' corresponding to the core tetrahedral meshes, and the 'default_exteriors' corresponding to the bounding box faces, while fluent automatically generates the 'interface1_2' zone. For some simulations, I just need one of these domains, so instead of remeshing, exporting again, what I do is deactivate or delete the zone I do not need, but here as you can see, when I try to do that, fluent says it cannot do that because of degenerate face zones, and I am not sure what this error exactly means. (Actually in this case, the mesh check worked fine, but usually I also used to get a mesh-check failed warnings also. I will try to reproduce that and post back).

[Qianqian Fang]

On 09/10/2012 03:40 PM, karthik kumar wrote:

Dr. Fang,
I am attaching a warning message from fluent when i read in the generated abaqus mesh. The mesh is successfully read in, with the change C3D4, as I mentioned earlier. We can see 5 zones, with the 'default_interiors' corresponding to the core tetrahedral meshes, and the 'default_exteriors' corresponding to the bounding box faces, while fluent automatically generates the 'interface1_2' zone. For some simulations, I just need one of these domains, so instead of remeshing, exporting again, what I do is deactivate or delete the zone I do not need, but here as you can see, when I try to do that, fluent says it cannot do that because of degenerate face zones, and I am not sure what this error exactly means. (Actually in this case, the mesh check worked fine, but usually I also used to get a mesh-check failed warnings also. I will try to reproduce that and post back).

did you export the face directly from v2m('cgalmesh') output?
I forgot to mention (in the documentation) that the cgalmesh
face output does not only include the triangles on the outside,
but also those on the internal boundaries. Every internal face
is repeated twice for the two regions that share it.

If that was causing the trouble, I hope by using the face
extraction script I provided in the last email, you should
be able to get around the issue. Let me know

Qianqian

Regards,

Karthik

On Monday, September 10, 2012 6:06:59 AM UTC-4, karthik kumar wrote:

Hello Dr. Fang,

First of all, congratulations for developing (an open source-based) really useful image-based meshing package. I have been using micro-CT to generate meshes of wide variety of porous media such as metal foams and sintered packed beds, for analyzing flow and heat transfer through them. So far, I have explored numerous available packages, e.g., amira, mimics, 3-matic, and simpleware to name a few. 

For the simulations I perform, I usually need a mesh in the fluid (empty, porous) region, and a mesh in the solid region (my solid+fluid image in 3d form a cuboid), along with a conformal (matching) mesh at the interface region separating the two. Further,I would prefer the bounding domain (6 faces each for the solid and pore domains) to be as flat as possible, so that I can later identify these easily, for applying my boundary conditions. So far, for this process, I have been successfully using a commercial package, simpleware, and now would like to switch to your open-source package, iso2mesh, as it provides a much wider flexibility, and the access to the original source code which is pretty well documented.

With this intention, I have been playing with iso2mesh for about 2 weeks now, and have also been following this group closely, along with the daily updates you make to the SVN repository. I would like to describe my experience thus far, and would be glad if you could comment and suggest a better workflow.

I begin by importing my image stack ( a grayscale or binary stack), and then use a similar approach as in the head+brain meshing demo. The only difference I find is that, in my case, the two domains are not disconnected and are not arranged such that one encloses the other completely. Instead, for my case, the two domains are inter-penetrating (6 x 2 + 1 = 13 surfaces overall). I have been playing with the various available meshing options, but with not much success. Though I see that the 'cgalmesh' option never fails, the generated mesh always seems to cause me problems, when I try to use it with my fluid flow/heat transfer solver (Fluent). The other options however, such as 'simplify' and 'tetgen' based options, continuously fail, with the most common error, "two subfaces ... are found intersecting each other'.

However, I have been successful in doing one thing though: When I pad my solid+pore region first with some pore pixels and then with the background pixels (so as to mimic the head+brain demo case, in which we have a background, head and brain parts, one enclosed in the other, in order), I could generate a valid mesh for the both solid+pore domains (with the obvious exception that this time, the generated pore domain is my actual pore domain+padded boundary on the edges). For this, I had used the 'cgalsurf' option, but again, I am not sure if I was lucky for that one particular case or if it will always work fine. Though I can live with this approach for now, it would be great if I can just mesh my domain without the added boundaries, i.e., mesh the solid+pore region cuboid, with matching mesh at the interface.

I can share my test data with you, if you would like to have a brief look at it.  

Also, after much deliberation and playing around, I found the following workflow successful (and most useful), for all those trying to export the volume mesh generated by iso2mesh to fluent:

1) use saveabaqus.m to save the mesh generated by iso2mesh as an abaqus input file. (I had to change the element type of MeshTetra from S4R to C3D4, as the previous one was creating shell elements, and not volume elements. C3D4 seemed to create valid tetra elements. Dr. Fang, you may fix this in your code, upon further approval from other users.

2)Then use import abaqus input file option in fluent. At this point, I found that a bunch of different things can happen, depending on the mesh quality, etc I guess. But for me, for the most part, fluent was able to generate internal surfaces, etc by default. So, if you are lucky, you can skip the step 2.5 below and proceed with the simulation. We still need separate parts for setting the boundary conditions though.

2.5) So, if there are any problems with the above step, or for creating boundaries from the existing mesh (for applying the boundary conditions), I found ICEM-CFD to be really useful. Simply import the abaqus mesh into ICEM, and first do a mesh-check. With this, it automatically identifies the internal faces (interface), i.e. the faces separating the two parts. Further, you can create additional boundaries using the create--> part option, such as the inlets, outlets etc from the existing surface mesh. Selections based on angle (work best if the boundaries are flat) or those based on location seemed to work the best. Be sure to only include 2d elements if you just want to create parts for applying Boundary conditions. Actually, ICEM can export the mesh in a number of solver formats, but beware, some of the export options require additional licenses.

3) Then you can perform the mesh check again, to be sure if the parts were created correctly, mesh is devoid of any other problems, etc, and export the processed mesh to fluent. (ICEM can also process the mesh, such as smoothing, coarsening  etc, but I guess it is always better to do this processing in iso2mesh).

Regards,

Karthik Bodla

--

You received this message because you are subscribed to the Google Groups "iso2mesh-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/iso2mesh-users/-/jsgaWfW5M0IJ.

[karthik kumar]

Yes I did use 'face' variable from 'cgalmesh' directly. I will now try your script and get back. Much thanks for your prompt and helpful responses.

[karthik kumar]

Dr. Fang,

I did try the script you provided, and I still get the same error. I think fluent understands repeated faces, internal faces etc by default, and so it does not matter if I used the original 'face' data from cgalmesh or the extracted one from the script you provided. I am still not sure what is wrong. Though, to get around this, I can just extract faces of a particular domain, instead of going to fluent and deactivating the zone I do not need. However, the fact that I am not able to do this in Fluent would mean that something might still be wrong with the mesh.

I have a second, much bigger issue though. Sometimes, fluent reports some of my cells have only wall faces (in fluent all the boundaries are wall boundaries by default), and with such a mesh, I cannot run a fluid-flow problem. Again, I would be glad if you know/advise me what the issue could be. I am guessing this could be because of tetrahedral elements attached to rest of the domain by a vertex or edge instead of a face (in which case, at least one of the faces would be an internal one and fluent would not complain). I was not able to visually verify this is the case though. Any help from other members of the group is also much appreciated.

Thanks,

Karthik

[Qianqian Fang]

On 09/10/2012 07:56 PM, karthik kumar wrote:

Dr. Fang,

I did try the script you provided, and I still get the same error. I think fluent understands repeated faces, internal faces etc by default, and so it does not matter if I used the original 'face' data from cgalmesh or the extracted one from the script you provided. I am still not sure what is wrong. Though, to get around this, I can just extract faces of a particular domain, instead of going to fluent and deactivating the zone I do not need. However, the fact that I am not able to do this in Fluent would mean that something might still be wrong with the mesh.

ok, another possibility is the element/face orientation.
I found that CGAL mesher outputs are not always consistently
oriented. You can use meshreorient() and surfreorient
(svn only) to correct the orientation before you extract
the surfaces. For a quick test, can you tell me the output
of the following command?

  length(find(elemvolume(node(:,1:3),elem(:,1:4),'signed'))<0)

another quick test to show orientation inconsistency is to run

  plotmesh(node(:,1:3),volface(elem(:,1:4)));
  camlight; lighting phong

if you see strange patterns on the surface, that means
the face orientation was not consistent.

[Qianqian Fang]

On 09/10/2012 11:56 PM, karthik kumar wrote:

Dr. Fang,

The output of the command was non zero (value = 34924). Does this mean I have wrongly oriented faces? I

yes, I believe so. Try running the following code and re-exporting your mesh

newelem=meshreorient(node(:,1:3),elem(:,1:4)) ;
elem=[newelem,elem(:,5)];

Qianqian

Thanks,

Karthik

[karthik kumar]

Dr Fang,

I just tried it. But, I still have the same error. (Now there are no negative volume elements though).

Karthik

[Qianqian Fang]

On 09/20/2012 12:41 PM, karthik kumar wrote:

Dr. Fang,

Just to update you, as I had mentioned earlier, for my case, CGAL seems to generate few cells (~0.5 %) that have only wall faces. I re-checked this using the function faceneighbors.m. When I look at the output, I see that few cells have all columns as 0!, i.e., cells with only boundary faces and no interior faces.

I sill don't think they should be there in the first place.
well, but I can be wrong.

These cells pose me problems when used in my solver. Hence, I identified these cells, and deleted them, before actually exporting the mesh. Now everything seems to be working okay, though, I still have few cells which are almost flat. But, as it seems so, my solver is able to handle such complex cells. I am including a couple of snapshots of my results, obtained on meshes generated by iso2mesh, after deleting the only-boundary cells.

I am glad that you figured out a workaround, but please check
your scripts again, and make sure you had handled the mesh
data properly. Always keep in mind that the last columns of node,
face and elem can sometimes be labels! they are not part of the
mesh geometry, remember to take them out before you feed them
to other iso2mesh functions.

Qianqian

Cheers,

Karthik

On Wed, Sep 19, 2012 at 1:01 PM, karthik kumar <karthi...@gmail.com> wrote:

Sure. Please find the corresponding files attached. The main file is the foam.m file. Also, I have used 64-bit cgalmesh on linux for meshing this data. Thanks for taking a look. 

The saveabaqus_mod is the modification with 'C3D4' type. While bface.m is for labeling the different boundaries, for applying BCs in my solver. Actual data is in ou2.mat.

Karthik

On Wed, Sep 19, 2012 at 12:55 PM, Qianqian Fang <fan...@gmail.com> wrote:

On 09/19/2012 12:47 PM, karthik kumar wrote:

Dr. Fang,

Thanks for your reply and clarification. 

I did check my quality and volume values using meshquality and elemvolume. While my quality seems to be good (min = 0.174, mean = 0.7948), I do have elements with 0 volume (mean = 0.4928, max = 53.7325). In one particular mesh I seem to be having 16388 elements with a 0 volume out of the generated 7726119 tetras.

can you send me the code/mesh data where you got 0-volume
elements?

Qianqian

--

Karthik 

On Wed, Sep 19, 2012 at 12:20 PM, Qianqian Fang <fan...@gmail.com> wrote:

On 09/19/2012 11:25 AM, karthik kumar wrote:

Dr. Fang,

I just checked an as-produced mesh and see that there are in fact some 'bad' tetras with very high dihedral angles (almost flat tetras). These I am  guessing are what are posing me problems in the solution. I checked CGAL documentation, which seems to have various options such as exuding, perturbing and smoothing to avoid these, but I am not sure how to run these using cgalv2m or a similar m-file using Matlab. I also understand that a few iterations of these are applied by default, but I suspect for my complex geometry these are not sufficient. Do you have any inputs/ideas how I may improve my quality? Please refer to the attached images (Good tetras in green, while the bad, almost flat ones are in blue) corresponding to the meshes I just generated, from a 
92 x 122 x 250 pixel volume (2-labels).  The used settings are as follows:

as I mentioned in the earlier email (and also your own online search),
both CGAL and tetgen are criteria based. To my understanding, unless
the meshing process is terminated half-way, it is impossible to
generate slivers in the process, because this will violate the predefined
quality criterion. Degenerated elements are also not possible.

For the error reported by your simulation package, I still think this
is due to incorrect file exporting/formatting issues.

You can use meshquality() and elemvolume() to plot the
elements at the lower quality margin. I doubt there is any
degenerated elements in the output.

Qianqian

opt.radbound = 20.0;

opt.distbound = 0.15;

opt.angbound = 30;

maxvol=100;

opt.reratio=1.2; 

Also, reducing the opt.reratio seemed to help a bit, but I am not sure if I can reduce it further.

Best,

Karthik

On Wed, Sep 19, 2012 at 8:19 AM, karthik kumar <karthi...@gmail.com> wrote:

Dr. Fang,

I have been investigating my issues further, since we last talked about. I have a feeling that may be my mesh has some slivers (Ref., fig.1.,  http://www.imr.sandia.gov/papers/imr18/Tournois.pdf ). I have come to this conclusion mainly because when I read it in fluent, it complains of degenerate face boundaries.

But, as I went through CGAL documentation online, I see that CGAL runs a mesh optimizer by default, which fixes up these slivers and improves the overall quality of the mesh. Please correct me if I am wrong. Is there any way to change (increase) the number of optimization/sliver removal and check iterations in CGAL that we can use via 'cgalv2m.m' easily? Or, is there any option in 'meshcheckrapir.m' which checks for these slivers and repairs them? I can include my image set if you like to investigate further. I mainly get these when I try to mesh metal foam and surrounding pore space as in the attached figure. (This figure corresponds to an older paper of mine, in which I had used Simpleware to generate the meshes).

Thanks,

Karthik 

On Tue, Sep 11, 2012 at 3:14 AM, karthik kumar <karthi...@gmail.com> wrote:

Dr. Fang,

I have also tried to export the mesh into tecplot format and then read in icem to see if everything was okay, but I had no luck. I can share my 'savetecplot.m' file (checked, and it seems to work) if you think it will be useful.

Karthik 

[karthik kumar]

Dr. Fang,

Thanks for your suggestions, and really helpful comments. Also, many thanks for taking time to look at my data and scripts. 

Like some other users of the group, I am interested in the below mentioned aspects, in case you have any plans to implement them soon. Of course, I would also love to make contributions to the extent possible.

a) Meshes with flat boundaries. Currently I am controlling the flatness of the bounding box images via opt.distbound, but yet the meshes are not 100% flat. Not to mention the huge increase in mesh size because of a smaller opt.distbound value. So, It would be great, for simulation purposes, to have meshes with 100% flat boundaries and the mesh still being coarse overall.

b) Smooth interfaces, when multiple iso-value surfaces touch each other as in my case. Currently, I am controlling the smoothness by importing more images (i.e., low resolution scans). In an other mail, you had suggested first smoothing the surface and then using s2m to generate the mesh mesh, but I am not sure how we can do this when we have multi-labeled images as in my case.

c) Periodic meshes. With periodic meshes (starting with images which are periodic themselves), we can run effective simulations and would be requiring smaller domain sizes.Thereby, it would be helpful if we have a means to generate periodic meshes in iso2mesh. Of course, one requirement would be that the original images be periodic themselves. This feature is in fact not present in the commercial packages I have tried. Therefore, I believe it would be a big plus if implemented. I know of a number of colleagues who want to use realistic structures for simulations, but just because their solvers and computational methods demand periodic meshes, they are forced to stick themselves to fake, artificial structures.

Best,

Karthik

[Qianqian Fang]

On 09/21/2012 03:36 AM, karthik kumar wrote:

Dr. Fang,

Thanks for your suggestions, and really helpful comments. Also, many thanks for taking time to look at my data and scripts. 

Like some other users of the group, I am interested in the below mentioned aspects, in case you have any plans to implement them soon. Of course, I would also love to make contributions to the extent possible.

hi Karthik

there are all great features that I had thought about.
I am sure some of these will be supported in the future.

If anyone want to contribute to implement any of
these features, you are certainly welcome!

Qianqian

To view this discussion on the web visit https://groups.google.com/d/msg/iso2mesh-users/-/gA6t6tSGmUQJ.

To post to this group, send email to iso2mes...@googlegroups.com.
To unsubscribe from this group, send email to iso2mesh-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iso2mesh-users?hl=en.