hi, recently i’m looking of matrix library solver for AMD cpu since experiences MKL seems not optimized. Several tests from external references (i.e Mathworks) have shown faster using AMD Optimizing CPU Libraries (AOCL) than Intel MKL (Pardiso) about 20% speed up. Hopefully, this solver will be available in the future version of CalculiX, best.
@xyont, are these just optimized blas, lapack, libm, etc, for AMD? Do they have an actual sparse solver like pardiso? Remember that the pardiso solver that ships with MKL is an older version of the solver. The newer version is faster compared to the MKL versions - Panua Technologies
seems it has own sparse solver when looking from documentation and project. The link of Pardiso from Panua is an improvement of original versions, the library is proprietary commercial for both end user and developer, but Intel MKL available free for user. Maybe this is the reason to not become popular as Intel does, even shown and reported faster than MKL. In contrast, AOCL is opensource project by AMD, it has been used by many also, e.g Matlab, Ansys, LS Dyna, MSC Nastran and Comsol,
Did you ever find any info on using AOCL with calculix? I was wondering the same thing.
I could look into it, but not sure what kind of speedup to expect. If just 10% or less then not sure it is worth the effort. And not sure how many people use AMD cpus?
3 Likes
Yeah… I think we have to find a better mechanism to include new solvers so that we could test different options for appropriate models. I would love to test petsc, trilinos, mumps, superlu, suitesparse/umfpack, but I haven’t had the chance to work on this.
as comparison, some reported it has performed better in Ansys (link)
Ansys Mechanical with AMD optimized AOCL BLIS deliver a geomean speedup of 1.26x with gains as much as 2.12x
If you do find time to work on that, please choose solvers that “match” CalculiX itself;
- free software,
- runs on all platforms that CalculiX runs on,
- [added 20241206] written in C or Fortran for easy integration.
If the source code for the solver is not available, finding bugs becomes a lot harder. And I suspect very few people will choose to spend thousands of euros on a solver.
Furthermore, linking CalculiX with a proprietary library violates the license that CalculiX is distributed under.
Added 20241206:
- Solvers written in Fortran or C are probably easiest to integrate.
- Ideally, one should profile the existing and new solvers before investing much time in integration!
1 Like
That’s exactly what I had in mind and those are fair points for advancing the use of ccx.
100% agree with you there.
I’ll need to do a deep dive into the different licenses since each of these solvers operates under a unique license. I’m leaving the links here for future reference to review them thoroughly. These might also be useful for anyone else exploring the same topic:
Don’t forget MFEM. That’s a great library and already got the solvers implemented.
They use some of the ones I already mentioned, but I forgot about hypre, certainly worth exploring:
I use AMD CPU’s (looking to upgrade to Ryzen 9 soon) but I’m sure they’re not all that common for HPC-type applications 
Agreed 110% on the profiling of solvers. I feel this is a common thing though (how many people need sparse equation solvers and how many sparse solvers are out there - quite a few), are there standard benchmarks that you’ve seen available for these options?
I did some reading on AOCC sparse solver. Seems it is just an interative solver, not direct? I don’t believe many users are using iterative solvers with Calculix. That is common in CFD where all element are the same solid type. See:
If people are using iterative solvers then there are probably better ones to explore first before AOCC. Something with MPI capability specifically.
1 Like
Interesting, why not use iterative solvers?
In my experience (commercial mechanical FEA tools for linear/nonlinear statics and modal dynamics), direct solvers are better for smaller problems and iterative solvers are more important for larger ones.
Iterative solvers only work if your entire mesh is all solids. If there are any beams, rigids, shells etc. then they don’t converge.
1 Like
Ah, interesting! I did some reading and this page helped clear up my confusion:
https://classes.engineering.wustl.edu/2009/spring/mase5513/abaqus/docs/v6.6/books/usb/default.htm?startat=pt03ch06s01aus39.html
Thanks!
1 Like