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 <https://scholarship.rice.edu/bitstream/handle/1911/80756/Spike_Flex_IJNME.pdf?sequence=1> as well as this paper <https://asmedigitalcollection.asme.org/computationalnonlinear/article-abstract/8/4/041003/370788/Efficient-Parallel-Simulation-of-Large-Flexible?redirectedFrom=fulltext> 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 On Friday, August 12, 2022 at 1:35:55 PM UTC-4 Radu Serban wrote: > 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 > <https://github.com/projectchrono/chrono/blob/main/src/demos/fea/demo_FEA_cablesMKL.cpp> > > which solves a similar problem using the Pardiso solver. > > > > --Radu > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *David Anderson > *Sent:* Thursday, August 11, 2022 12:59 PM > *To:* ProjectChrono <[email protected]> > *Subject:* [chrono] Very slow FEA integration relative to other codes > > > > 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 > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/projectchrono/2920668d-0033-4dd3-aea1-9c65a5e3191bn%40googlegroups.com > > <https://groups.google.com/d/msgid/projectchrono/2920668d-0033-4dd3-aea1-9c65a5e3191bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/77cb6c65-050c-448d-8360-c1c705dfbe1an%40googlegroups.com.
