Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Best way to connect volumes? (or: how to convert 4 to 10 node tets?)

Status
Not open for further replies.

eyeguy

Bioengineer
Nov 23, 2006
12
0
0
Hello,

I'm working on a MATLAB script that transforms data from an MRI scanner to an APDL script for analysis in ANSYS. From the MRI data I get nodes and connectivity for four node tetrahedrons. Unfortunately, however, there is no connectivity between these volumes: the only data I get is their material type. The ultimate goal of the project is to translate these four node tetrahedrons into 10 node tets.

My current scheme goes like this: I create a set of keypoints from the MRI node data (~10,000 keypoints for very low resolution); I then create a series of volumes from these keypoints using the MRI connectivity data (producing ~35,000 volumes). The problem is that in order to mesh this using VMESH I need to first use VGLUE to glue all the volumes together. Obviously with 35,000 volumes--and preferably far more than that--this takes forever! (Presumably it's checking each area of each volume against each other for whether they contact.)

Does anyone know of a better way that I could go about doing this? It seems like there should be other options. Keep in mind that the only data I have is the nodal locations, their connectivity in four node tetrahedrons, and the material type for each tetrahedron.

Also, if anyone has a better way to convert four node tets to 10 node tets I'm all ears. Many thanks.
 
Replies continue below

Recommended for you

Hi,
correct me if I'm wrong, but I seem to understand that you can create tetrahedra directly from your scanner data. So, instead of passing through keypoints+volumes, why not create the nodes directly and the elements directly? If you know where the nodes are and in which order you place them, you have the basis for creating the elements directly.
Maybe there's something in your process that I haven't understood very clearly...

Regards
 
Hello and thanks for your quick reply,

I had thought along similar lines, but as far as I know there is no way to create the midside nodes in my triangles that would be necessary to create a 10 node tetrahedral from my four node data. As far as I know, ANSYS is not capable of creating midside nodes in elements, but perhaps I am wrong?


An addendum to my first post: I left a model running overnight with the VGLUE command and it failed to work for reasons that are unclear to me (it suggested that I use VOVLAP instead). So I guess for large models it simply is not an option.
 
A couple of comments:

1 - Is it necessary to have all the interior points? Or could you just take the outer data points from your scan, form areas from them, and a solid from that? Then you could just mesh the internal volume

2 - Look up the help on the emid command, which will allow you to add/remove midside nodes. Here's a quick example I just verified works:

finish
/clear

/prep7
et,1,70
n,1,,
n,2,1
n,3,.5,1
n,4,.5,.5,1

e,1,2,3,4
et,2,90
emodif,all,type,2

emid,add,all
gplo


This was done with thermal elements, obviously use the appropriate element type for the physics you're solving for.

Hope this helps,
Doug
 
Oh yeah, one more comment. Try using the nummrg rather than a gluing operation. Just be careful you don't wind up merging stuff you didn't intend.

Sorry for the double post,
Doug
 
I've unfortunately tried using NUMMRG already with no results. It says that there are no coincident keypoints to merge. I assume this is the case because the original four node tetrahedrons already have shared nodes at their boundaries. However, in ANSYS this translates to me having 35,000 different volumes that happen to share points, rather than a continuous mesh.

Your earlier post is a very good idea however, and something that I will definitely look into. Thank you for including an example as well.
 
Don't confuse nodes with keypoints. If you are reading in your point cloud file as nodes, then there are no keypoints defined. The first argument in the nummrg command defines what you're merging. I would suggest using the nummrg,all to start with (make sure you save before you issue that).

Keypoints are used to define lines, which in turn define areas and volumes. If you mesh geometry within ANSYS, then volumes with shared keypoints will have shared nodes. The method you're using is a little unorthodox, so you need to be careful how you're building your model, and what you have to work with to ensure proper connectivity.

Hope this helps,
Doug
 
As others have said, NUMMRG is the command you should be looking at. Do you have any way of altering the density of the node (or kp) grid which MATLAB generates? If so what I would do is forgoe tet meshing altogether and take advantage of the fact that you can map mesh a prism shaped volume with brick elements. This is just a thought...35000 10-noded tets really isn't a bad model to work with but just a thought. If you implemented a subroutine to do this it might save you considerable time in the future when doing the same.

 
Hi,
to summarize, you have two options:

- read your point-cloud file not as keypoints but as nodes
- create tetrahedric elements from these nodes and not tetrahedric volumes from keypoints
- execute NUMMRG,nodes (or NUMMRG,all) to ensure there is no duplicated node in a same location
- add midside nodes to your elems

*OR*

- read your point-cloud file as keypoints, create tetrahedric volumes
- "compact" eventually overlapping keypoints by issueing NUMMRG,all
- now the volumes do share the same corner points. Mesh them in shuch a way that you are sure that each of them will have one single element: even the elems will share the nodes and the mesh will be connected, without any need of VGLUE or whatsoever.

I suppose that the idea of not using only the exterior points has to do with your previous post (and problem), i.e. the "compatibility" of meshes between two scannered objects... In this case, if you are worried about the numbering, then you should take care with the NUMMRG command, since it will destroy your original numbering sequence.

Regards
 
Status
Not open for further replies.
Back
Top