Chainmail Simulation Query

33 views
Skip to first unread message

Owen Zoyt

unread,
May 20, 2024, 6:40:26 PMMay 20
to ProjectChrono
Hello All,

I'm working on 3d-printed programmable fabrics for medical compression garments and mechanical counterpressure spacesuits. For manufacturing, I have been using a technique that is similar to the chainmail dress demonstration detailed in Professor Hammad Mazhar's PhD Thesis (pg. 135). However, the methods I have been using for rigid body physics simulation have proven insufficient for our current needs, leading me to explore Chrono.

I was incredibly impressed by the quality and efficiency of Professor Mazhar's chainmail simulation and have encountered challenges in implementing similar interconnected structures using PyChrono. Professor Mazhar describes the rings as being generated as several connected cylinders, but I have not figured out how to use PyChrono to add multi-part colliders with specified translation/rotation from a starting point. In an ideal world, I can add a triangle mesh torus as the visual layer (which later gets printed), and distribute many sphere colliders around the torus that are oversized from the surface, so that the visual layers never actually touch. In the end, I also need to figure out how to export the visual layer as a mesh for manufacturing. 

I would greatly appreciate any advice on how to execute this with PyChrono.

Thank you very much!

June Knauth

unread,
May 30, 2024, 6:12:10 PMMay 30
to ProjectChrono
Hey All,

Sorry to bump this- we just got a basic test sim running that effectively replicates our chainmail geometry. The issue, however, is that it immediately fills the RAM of anything we run it on. We have ~2.5k bodies in this sim, each of which uses 10-20 spheres for collisions. We ran this on our largest compute instance and it consumed 46GB of RAM immediately before being OOM killed. Having seen chrono effectively simulate 17k links with only 128GB of memory, my immediate assumption is that we're missing a crucial optimization step. Currently, we are using Bullet collisions and the default solver in PyChrono. Here's a snippet of the code we're using to generate our links:

```
        link_body = chrono.ChBodyAuxRef()
        collision_model = chrono.ChCollisionModel()
        visual_model = chrono.ChVisualModel()
       
        sphere_locs = self.generate_xtorus_pts(link.extension_distance, link.major_radius, num_spheres)

        for x, y in sphere_locs:
            collision_sphere = chrono.ChCollisionShapeSphere(self.contact_material, link.minor_radius)
            visual_sphere = chrono.ChVisualShapeSphere(link.minor_radius)
            frame = chrono.ChFramed(chrono.ChVector3d(x, 0, y))

            collision_model.AddShape(collision_sphere, frame)
            visual_model.AddShape(visual_sphere, frame)

        link_body.AddCollisionModel(collision_model)
        link_body.AddVisualModel(visual_model)
```
After generating a set of 2D points associated with an extended torus ("pill" shape), we add collision and visual spheres to the body for each point using a ChFrame. 

After the above step is complete, we place each link in the proper position and run the simulation.

This code gives us a working sim, but as mentioned, memory usage is untenably high for higher link counts.  I don't think this is a PyChrono-specific issue, considering we're just accessing cpp bindings- all the Python objects we use to store our links are under 250MB in size, including the chrono bodies themselves. My best guess is that, because we start with a lot of barely-intersecting geometry in our dense link mesh, many collisions must be simultaneously considered, leading to exponential memory growth. This is undercut, though, by the fact that the memory usage stays constant over time.

Part of the difficulty is that I can't find many good resources on optimizing Chrono sims. If anyone has advice on this specific situation, something I missed, or can point me in the right direction of getting this running well, please let me know.
Reply all
Reply to author
Forward
0 new messages