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<https://aka.ms/AAb9ysg> ________________________________ From: [email protected] <[email protected]> on behalf of David Anderson <[email protected]> Sent: Thursday, August 11, 2022 7:58:39 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]<mailto:[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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fprojectchrono%2F2920668d-0033-4dd3-aea1-9c65a5e3191bn%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Calessandro.tasora%40unipr.it%7Cea8b774eb19c460d7bdb08da7bc320df%7Cbb064bc5b7a841ecbabed7beb3faeb1c%7C0%7C0%7C637958376278770264%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=jlhY21hUsxcvbsBJanjOBj8767V%2B5ibigmzidpWm7UA%3D&reserved=0>. 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. -- 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/PAXPR07MB8625E1CB1A89F6C639C713BF93679%40PAXPR07MB8625.eurprd07.prod.outlook.com.
