Suggestion on non-symmetric non-positive-definite real-valued generalized problems

[dariomangoni]

Hi guys,
I've been trying to solve the following problem:

where

I anticipate that M_tilde and K_tilde matrices are real, but are NOT positive-definite and NOT symmetric, none of them.
Tuckling multibody+finite-elements...

I read from ARPACK guide that dnaupd+dneupd, that are the "most" fit for the purpose, require that my M_tilde should be symmetric and positive-definite

I tried nonetheless to run the problem with dnaupd realizing that returns ido=99 and info=0.
However, when calling dneupd, the dr vector returns just a long list of eigvalues all really close to sigmar and non-sense eigenvectors...

I know I'm in a quite desperate situation, but any suggestion on how to tackle such kind of problems is hugely appreciated.

Using ARPACK-NG 3.8.0

[caliarim]

Hi, are -M_bar and/or K_bar SPD?

[dariomangoni]

hi @caliarim, unfortunately no;
in aeroelasticity we cannot ensure that neither K_bar, M_bar or C_bar are symmetric nor that are positive-definite.
We are looking for solutions for the most general problems that we could encounter, but I'm struggling to find a proper method for handling such cases.

I think that using Krylov-Schur methods I might get a way out but, since we are already using ARPACK, I wanted to double check if we could handle these cases with IRAM so to avoid adding any additional dependency.

I'm not sure if a transformation of the problem into a non-generalized form (as suggested in the ARPACK guide 3.2.2 M is NOT Hermitian Positive Semidefinite) is a proper way of dealing with this issues.
We operate on big matrices and a decomposition is always something that I prefer to avoid, but since it's not required to store the inverse I can make a try if it makes sense.

[caliarim]

If I am not wrong, inv(M_tilde)*K_tilde = [0,I;-inv(M_bar)*K_bar,-inv(M_bar)*C_bar]. So, you can turn it into a regular eigenvalue problem, provided that M_bar is not singular.

[dariomangoni]

Yes, you are right and we are already doing so, however this causes a strong filling up: the starting matrices are sparse, while the inversion make them quite dense. Is there any chance to leave them sparse?

[fghoussen]

Playing with workspace size / shift / invert and / or solvers (BiCG instead of LLt for instance possibly with PC) when mode > 1 may help : arpackmm maybe convienient for such testing.

arpack-ng/EXAMPLES/MATRIX_MARKET/README

Line 18 in 0a655d9

- if solve breaks down, you may:

Arpack is maintained but no more developed so if you don't find a solution here, you may give a try to slepc (LOPSI ? SRRIT ? QMRPACK ? not sure if these are neither stable, nor designed for sparse [or dense ?] matrices)