Performance questions in Windows

[tangpengbin]

Hi,

Thanks for sharing this project! I complied it in Windows by Visual Studio 2019, but I found its performance is much lower than in Ubuntu. I checked that I used MKL intel blas and lapack to build sparsesuit package from https://github.com/jlblancoc/suitesparse-metis-for-windows. I used the hello world example and get both output files of "info1.txt" in Windows and Ubuntu as follows. I used the same threads (=12) in both Windows and Ubuntu for the simulation. The left one is the output from Windows, and the right one is from Ubuntu. when outputting this first output file, those two cubes and the ground are not get contacted with each other. From the output, basic every step is lower even for matrix manipulation, so I don't know if I missed something else that would make the performance lower so much.

Thanks!

[liminchen]

We haven't tested performance on Windows. My experience is that the issue may be related to the memory management of Eigen backend. One thing you may try is to swap out Eigen's malloc with dlmalloc.

[liminchen]

What's the overall performance look like? Are you testing with the visualization or not? Using 100 mode can run IPC without online visualization.

[tangpengbin]

I just tried to use dlmalloc in Windows, but I don't know how to solve the issue of redefinition in Visual Studio. Then, I found an allocator called "mimalloc" and used it, but the performance improvement is not very large.

Both the above testings and the following one are with visualization mode. is the overall performance recorded in "info.txt"? if it's the case, here is their comparison. The left and right ones are also from Windows and Ubuntu respectively. It seems CCD also costs a lot in Windows.

[liminchen]

Yes, the overall performance is recorded in info.txt. Not sure why it can be that slower on Windows.

[tangpengbin]

ok, I will try something else later. if I can get some new I will post them here.

By the way, I want to ask a question about the contact handling situation if I use a discrete elastic rod model. In your paper, the contact will be enabled if the distance of a primitive pair smaller than the threshold d^{hat}, so I wan to ask if we use the elastic rod model how could we deal with the contact between rods (with radius)? Since the representation of the elastic rod uses edges, is it ok to set d^{hat}=radius to handle them? Or we have to use the explicit surface to do the contact.

Thanks!

[liminchen]

Great! Thank you!

For discrete rods simulation, I think either way will be interesting to try:

1. Setting dHat to be radius_a + radius_b will be able to handle contact between rods with radius_a and radius_b (similarly for rods' self-contact). But if the rods are too thin, then probably the convergence cost will be large. This also assumes rods can be compressed in the radial direction, and the compression effect is modeled by IPC.
2. Using an explicit surface would be more expensive as number of contact primitives increases, but it can allow modeling the radial deformation independently with contact, so that you can either model radial deformation using the constitutive model, or simply applying Kirchoff-Love assumption.

Another way you could consider is to modify IPC's constraint definition, changing D>0 to D>radius_a+radius_b, while this would also require some modification on the implementation of IPC. This does not assume radial compression, and IPC's dHat could be used as is (without assigning it with more physical meaning).

[zfergus]

I think if you set dHat to radius_a + radius_b then this will guarantee the medial axes do not intersect or pass through each other, but there is no guarantee the rods will be intersection free. As Minchen suggests, this might be okay if you are able to model this as radial compression.

One option to prevent intersections of the rods would be to use a distance function of d_rod_rod(e_a, e_b, radius_a, radius_b) = d_edge_edge(e_a, e_b) - radius_a - radius_b. This way the zero distance occurs when the rods come into contact. With this formulation, you can use a standard dHat value as in our paper. This is something I have thought about for collisions between implicit surfaces, but I have not experimented with it.

One difficulty with this approach would be finding a reliable CCD that supports collision at a distance. This paper discusses an approach by solving a degree six polynomial, but there are numerical difficulties with this approach.

[tangpengbin]

Great! Got the idea, thanks! :)

[tangpengbin]

I found for the example of 2cubesFall, Windows gives poor performance if I use the default spdlog output setting. When I disabled the spdlog by setting "args.logLevel = 6;", the 2cubesFall example can give a comparable performance to Ubuntu. I don't know why this log gives us such a big difference. I attached my "info.txt" for the disabled one at the end.

I also tested the example of chain10, the one enabled is about 8% slower than the disabled one.

[zfergus]

Interesting, I did not know spdlog was so much slower on Windows.

[tangpengbin]

ok, I am not sure about the reason of spdlog, but I think this issue can be closed.

Thanks @liminchen @zfergus for your valuable suggestions! :)