Very slow FEA integration relative to other codes

[David Anderson]

Hi dev team/community,

Recently I've been trying to do some benchmarking of Chrono and other libraries as FEA frameworks for use at a marine engineering company. In particular, we are interested in modeling algae as long cable-like elements.

I've created a test-model where numerous multi-element lines hang from a single "backbone" line with one free end (see model6 in the attached .h file). Briefly, I create a backbone line with fixed ends using 1m long ChSpringElements to link the nodes; I then compute nodal positions for each of the hanging lines, each with 10 1m ShSpringElement segments per-line. I've also set up this simulation in MoorDyn (an open source mooring model), MSC Marc, and Orcaflex.

Unfortunately, Chrono appears to be much slower than the other options: running a 16s simulation of a system with 100 hanging lines, for instance takes 3058 seconds in Chrono using the HHT timestepper and MINRES solver, 533 seconds in the alpha version of MoorDyn (using an RK2 stepper) and just 288 seconds in Orcaflex. With pending improvements to MoorDyn (including RK4/RKF45 integrators) I've been able to knock that simulation time down to just 31 seconds for MoorDyn.

Given this large discrepancy in runtimes, I was curious if:

1. there were obvious bugs with my model formulation,

2. if there are any standard steps that can be taken to speed up the FEA integration in chrono, and

3. Whether anyone has ideas as to why these massive discrepancies might exist.

Some basic profiling suggests that the solver is the computational bottleneck - I've tried swapping out all of the default solvers, but haven't seen huge increases in speed and am not familiar enough with the math of the solvers to delve deeply into the implementations.

I've attached my .h file defining my models (model6 is the model in question) and the wrapper program I am using to run my simulation (my_example.cpp). Any feedback/ideas are greatly appreciated.

Thanks,

David

[Radu Serban]

David,

 

I plan on doing some work that will improve performance of FEA simulations in Chrono (related to the frequency of Jacobian updates and factorizations).

 

Having said that, you should try using a sparse direct solver with your Chrono model.  While you can use one of the solvers in Eigen (Sparse_QR or Sparse_LU – which are already options in the code you attached), I suggest you get the Intel MKL libraries and use the Pardiso solver in there (turn on ENABLE_MODUE_PARDISO_MKL during CMake configuration of Chrono).  Look for example at demo_FEA_cablesMKL which solves a similar problem using the Pardiso solver.

 

--Radu

--
You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/2920668d-0033-4dd3-aea1-9c65a5e3191bn%40googlegroups.com.

[Alessandro TASORA]

Dear David, 

I suspect that the slow performance is caused, among other things, by the fact that you are using the MINRES solver. I suggest you to enable the Pardiso MKL module in Cmake, rebuild, and use the MKL solver in your code. For small to average-sized FEA problems, MKL Pardiso is my default choice. 

Alessandro Tasora 

Scarica Outlook per Android

---

From: projec...@googlegroups.com <projec...@googlegroups.com> on behalf of David Anderson <d.and...@kelsonmarine.com>
Sent: Thursday, August 11, 2022 7:58:39 PM

To: ProjectChrono <projec...@googlegroups.com>
Subject: [chrono] Very slow FEA integration relative to other codes

--

You received this message because you are subscribed to the Google Groups "ProjectChrono" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectchron...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/2920668d-0033-4dd3-aea1-9c65a5e3191bn%40googlegroups.com.

Firma il tuo 5xmille all’Università di Parma, aiutaci a essere sempre più accoglienti e inclusivi verso le nostre studentesse e i nostri studenti - Indica 00308780345 nella tua denuncia dei redditi.

[David Anderson]

Hi Radu, Alessandro -

Thank you for the suggestions. I set up the MKL solver today, and it appears to in fact run more slowly than MINRES at least as tested with both RK4 and HHT time integration schemes. Still at a loss as to how to speed things up. Running a simulation with 10 hanging chains takes around 298 seconds for 16 simulation seconds using RK4 (with a fixed time step of 0.00058) and MKL, while in MoorDyn I am able to run the same simulation in around 3.2 seconds. Not entirely sure where to start looking for the discrepancy.

Generally, the company I'm working at is very interested in developing a workflow based around Chrono in the future as it's a much more flexible modeling environment than domain specific codes such as MoorDyn and Orcaflex. We'd likely be interested in developing the marine-modeling features available to Chrono users if we can figure out a way to speed things up sufficiently.

Radu, I'm also curious whether the idea of integrating GPU modeling of flexible bodies into Chrono has been explored at all - I found this paper of yours as well as this paper which look to produce promising results, but most of what I've seen of GPU usage in Chrono these days seems to be limited to granular dynamics. Would be interested in hearing your thoughts.

Thanks again,

David

[alessand...@unipr.it]

Hi David,

I am on vacation so I cannot check your code, but it looks quite strange to me that you need so much CPU time for a simple chain with springs. Probably there are other bottlenecks to investigate.

By the way, even if there is explicit RK4 in Chrono, I do not encourage to use it because its implementation is mostly for comparison with other methods, but it lacks some optimizations. My suggestion is that you use one of these implicit methods: HHT or Euler implicit linearized (the default one), or Euler implicit. Note that HHT has more CPU overhead respect to Euler  , and you should use HHT only if you dessire low numerical damping.

As usual, the time step of implicit methods should be large enough to compensate their higher per-timestep CPU overhead respect to implicit methods.

Best regards

A. Tasora

To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/77cb6c65-050c-448d-8360-c1c705dfbe1an%40googlegroups.com.