FEA: High frequency oscillation in reaction forces

[Vito Zago]

Hello everyone,

I'm modelling a structure with ANCF elements and I get high frequency spurious oscillations on reaction forces when using high values of Young's modulus. I'm using the MINRES solver and Newmark time stepper. I'd like to know what's the way to solve this issue in Project Chrono.

I've also read this paper http://qu-zhe.net/Resource/Struct/2019_CCEE.pdf that associates oscillations to an instability of the Newmark time stepper when using Rayleigh damping and simulating stiff elements. I've run a test using softer elements and in fact the oscillations disappear, but this way I'm changing the behavior of the structure. In this work they suggest to use a dissipative stepper (e.g. Bathe's) or a frequency-insensitive damping: are these or some equivalents to these available in Project Chrono?

Thanks,

Vito

[Mike Taylor]

Vito,

Here are a couple of suggestions of things to try:

I would recommend using HHT with one of the direct linear solvers with ANCF meshes.  Below is part of a previous forum reply from Radu on this topic.  Note that there are also some direct linear solvers in Eigen that are also exposed SparseLU & SparseQR in addition to Pardiso (from MKL) and MUMPS..

• For models with FEA meshes, you should prefer using the HHT (or maybe the implicit Euler) timestepper, not the implicit linearized Euler. The latter will work, but the results will not be accurate. Furthermore, for models that also include 3D bodies, you should use the “ACCELERATION” mode of HHT (which is the standard HHT scheme and also the default for the Chrono HHT integrator).  This is because the “POSITION” mode is technically incorrect when quaternions are present (that mode may be a bit better for a model with only FEA meshes.
  
  
• In conjunction with an implicit integrator (such as HHT), I recommend always using a direct sparse linear solver (either Pardiso through Chrono::MKL like you were doing, or else the Mumps solver through Chrono::Mumps).  Iterative linear solvers are prone  to stagnate on our type of problems (saddle point) especially since we do not have a good preconditioner (except for the simple diagonal preconditioner we provide as an option).  Having said that, if you do want to experiment with a Krylov solver, you’re better off using GMRES.  Since you are using the latest code in ‘develop’, you are aware that I have recently refactored the Chrono solvers and now interface to the iterative linear solvers provided in Eigen.  The MINRES solver from Eigen seems to be particularly fragile – this is an issue I’ve been looking at lately.

You could also look at shrinking your step size as well.

Note: I believe that all of the ANCF elements use a damping model that is proportional to the strain rates (i.e. a linear Kelvin-Voigt model).  This is a different damping model than Rayleigh damping.

Best Regards,

Mike

[Vito Zago]

Dear Mike,

thank you for your help. I've been trying to use a direct solver but without any success.
I'm copying below the messages that I'm getting with each solver.

- Using MKL gives the following error:
 
    Solver setup failed 
    inputs are invalid, or the algorithm has been improperly called-done

I saw the other post (https://groups.google.com/forum/embed/?place=forum%2Fprojectchrono&showsearch=true&showpopout=true&parenturl=https%3A%2F%2Fprojectchrono.org%2Fforum%2F&pli=1#!topic/projectchrono/f4KlPuctc1A) but I wasn't able to find a solution from it.

- Using SPARSE_QR generates a series of these messages:

  count 2  NormHE -nan                                                                                                                                                                                                                      
  count 3  NormHE -nan                                                                                                                                                                                                                      
  count 4  NormHE -nan                                                                                                                                                                                                                      
  count 5  NormHE -nan                                                                                                                                                                                                                      
  count 6  NormHE -nan                                                                                                                                                                                                                      
  count 7  NormHE -nan                                                                                                                                                                                                                      
  count 8  NormHE -nan                                                                                                                                                                                                                      
  count 9  NormHE -nan

- Using SPARSE_LU generates this errors:

    feaSolver setup failed
    LU factorization reported a problem, zero diagonal for instance
    -done
 

I hope this can help understanding how to solve the problem.

Thanks,
Vito

[Mike Taylor]

Vito,

Since you are getting results with the iterative solver, but the direct solvers are not working, I wonder if you have redundant constraints with your system.

As a start, you could try disabling/removing all of the constraints in your system to see if the direct solvers start working.  If so, you could start adding in the constraints one by one until you find the source of the problem.

Best,

Mike