Today I worked some more on reformatting the fracture code. I have completed the Tetrahedron class (not tested or compiled, but the code has been transferred)
- I optimized the code in the calculating the strain/stress/derivatives (mostly eliminating redundant loops.
- Currently, the tetrahedron class is untemplated and uses floats. It also uses only House:: namespace libraries. This should be fixed in the future to take a custom data type. Also, the linear math system should either use a different library, or matrix/vector types should be passed as template parameters.
- I was thinking about making the tetrahedron class an abstract class with basic finite element functions which can be implemented with a derived class. This way, multiple element styles/numerical techniques can be tested by simply deriving with a custom element class.
- I am going to use smart pointers for the list of Node pointers which the tetrahedrons keep track of. This way, they can automatically be deleted when no tetrahedron is using them. There is an issue I need to look up before I do this.
? Can a std::vector of smart pointers resize itself when a smart pointer has no more owner? If not, then there will still be a dangling pointer in the vector which would eliminate any advantage of using smart pointers (of course, a routine per time step could go through and resize the vector).
More will be researched later.
Sunday, August 8, 2010
August 7, 2010
Today I finally got my fracture stuff implemented. Currently, it is extremely slow and not optimized, but I finally implemented an approximate fracture plane. Basically, I take each node and calculate the separation tensor described in Obrien.
I think take the points within the element, and get a vector from the node to those points ( Ni - Ncurrent where Ni != Ncurrent ). I think take the dot product with the eigenvector (seperation vector) and if the absolute value is greater than 0 for 2 or more nodes in the element, then that element gets assigned to one side of the fracture plane. 5 or 6 hours later, I got all of the memory leaks worked out. Basically, after this is done, new nodes are created, old nodes may be deleted, and the node's tetrahedron index values are changed, so I have to go through the nodes and delete all the unused nodes (if they are no longer part of the mesh) and update all of the elements' index values into this vector of nodes (for each of the 4 nodes).
Also, I looked at Ogre, Openscenegraph, and Bullet. I'm going to experiment with Ogre and Openscenegraph, but Bullet seems to be a good physics library so I might see if I can extend it with the fracture stuff.
I also got all the LOP tests for work. I finally managed to fix and issue with the grid. So now it goes through each cell, takes the neighbors and uses the neighbors in its calculations.
Preliminary results: The points approximate the thin surface of each object, but they are not equally spaced out as in the paper. More experimenting will be done to see if this is an issue with my code (more than likely not) or just an artifact of using the original uniformly sampled dataset to project itself onto itself (in the paper, they use a "blanket" of regular samples to project these points causing them to not clump). The only thing I'm worried about is the clumping in general.
Tomorrow I'm going to continue to experiment with fracture. I will also read some more papers and try to flesh out sketch of thesis proposal / previous works.
Todo next: Clean up code and rewrite to be more modular
I think take the points within the element, and get a vector from the node to those points ( Ni - Ncurrent where Ni != Ncurrent ). I think take the dot product with the eigenvector (seperation vector) and if the absolute value is greater than 0 for 2 or more nodes in the element, then that element gets assigned to one side of the fracture plane. 5 or 6 hours later, I got all of the memory leaks worked out. Basically, after this is done, new nodes are created, old nodes may be deleted, and the node's tetrahedron index values are changed, so I have to go through the nodes and delete all the unused nodes (if they are no longer part of the mesh) and update all of the elements' index values into this vector of nodes (for each of the 4 nodes).
Also, I looked at Ogre, Openscenegraph, and Bullet. I'm going to experiment with Ogre and Openscenegraph, but Bullet seems to be a good physics library so I might see if I can extend it with the fracture stuff.
I also got all the LOP tests for work. I finally managed to fix and issue with the grid. So now it goes through each cell, takes the neighbors and uses the neighbors in its calculations.
Preliminary results: The points approximate the thin surface of each object, but they are not equally spaced out as in the paper. More experimenting will be done to see if this is an issue with my code (more than likely not) or just an artifact of using the original uniformly sampled dataset to project itself onto itself (in the paper, they use a "blanket" of regular samples to project these points causing them to not clump). The only thing I'm worried about is the clumping in general.
Tomorrow I'm going to continue to experiment with fracture. I will also read some more papers and try to flesh out sketch of thesis proposal / previous works.
Todo next: Clean up code and rewrite to be more modular
Subscribe to:
Posts (Atom)