Problems with Constraints in Modal Analysis

168 views
Skip to first unread message

David Marten

unread,
May 11, 2017, 5:19:39 PM5/11/17
to ProjectChrono
Dear all,

I wrote in this forum a few months ago when I was successfully using CHRONO to develop a structural model for the wind turbine simulation code QBlade. I have not touched my code for a while but recently went back to work on the modal analysis functionality.

To solve the Eigenvalue problem I use the GetMassMatrix, GetConstraintJacobianMatrix(&Cq), etc... functions from the CHSystem class to get the matrices. The the A and B matrices for the generalized eigenvalue problem are constructed and I use the LAPACK GEP function to solve.

Generally the resulting frequencies and modeshapes look reasonable - but the problem is that they are not reproducable, sometimes "new" modes emerge and frequencies are shifted
when I use constraints in my model (using the exact same boundary conditions). As soon as I remove the constraints the resulting modelshapes and frequencies are fully reproducable again.I looked into the Cq matrix, that I got from the ChSystem and observed that many values are very small (up to 1E-37).

Could a floating point error be the problem here? I guess that the modal analysis is very sensitive to small changes withing the input matrices.
Do you have any other Idea what the problem could be and how to possibly fix this? Or is there an inbuild alternative to constraints in CHRONO (that also allows to leave certain DOF "unconstrained")?

Thanks and kind regards,

David


Alessandro Tasora

unread,
May 12, 2017, 4:51:25 AM5/12/17
to projec...@googlegroups.com

Hi David,

what do you mean for 'non reproductable'? I mean, do you compare the results of the constrained modal analysis vs some other software (es Abaqus) with same constraints? Or do you compare  constrained vs unconstrained, both with Chrono matrices?
Because in the second case I am not surprised that adding even a simple constraint somewhere in the model will change all mode shapes.

Also: is there any redundancy in the constraints that you add? I mean, check the rank of Cq....  In case of redundancy, depending on the type of eigen solver, you may still get results but those will be unreliable.

other comments:



I wrote in this forum a few months ago when I was successfully using CHRONO to develop a structural model for the wind turbine simulation code QBlade. I have not touched my code for a while but recently went back to work on the modal analysis functionality.

To solve the Eigenvalue problem I use the GetMassMatrix, GetConstraintJacobianMatrix(&Cq), etc... functions from the CHSystem class to get the matrices. The the A and B matrices for the generalized eigenvalue problem are constructed and I use the LAPACK GEP function to solve.
ok, in fact I remember your past work (that was a nice result, by the way). Yes, using the GetMassMatrix and other ChSystem: functions you can get those M, K, Cq matrices that you need for the generalized eigenproblem, there should be no hidden issue here.



Generally the resulting frequencies and modeshapes look reasonable - but the problem is that they are not reproducable, sometimes "new" modes emerge and frequencies are shifted
when I use constraints in my model (using the exact same boundary conditions).
Same boundary conditions _plus_ you add constraints in one of the two models, or is it rather that in model A you get a 'fixed' boundary condition using the SetFixed(true) function for some FEA nodes whereas in model B you leave the node free and you fixit to ground using chrono constrints? because in the 2nd case I expect that the eigenmodes must be the same, except for some numerical issues.

As soon as I remove the constraints the resulting modelshapes and frequencies are fully reproducable again.I looked into the Cq matrix, that I got from the ChSystem and observed that many values are very small (up to 1E-37).
Yes, but those should not interfere. Each row in the jacobian is 'almost' normalized, in most constraints, so numbers usually range in the -1...+1 interval. Probably, if the issues you get are due to numerical troubles with iterative solvers for eigenproblems (are you using Lanczos?) then it could be that the norm of the jacobian Cq is too large or too small respect to the values in M or K. In theory the norm of Cq should not change free eigenvalues, but in practice it happens that the numerical iterative eigensolver could crawl to the solution with more difficulty; therefore: try to pre-multiply or post-multiply the jacobian by some scaling and see what happens.


Could a floating point error be the problem here? I guess that the modal analysis is very sensitive to small changes withing the input matrices.
yes, this is always true in modal analysis even without constraints (but for the lowest frequencies, the result should not be affected much)

Do you have any other Idea what the problem could be and how to possibly fix this? Or is there an inbuild alternative to constraints in CHRONO (that also allows to leave certain DOF "unconstrained")?
Try that scaling of Cq and tell me what happens.

Also, try changing the settings of the LAPACK solver (I do not use it, so I cannot give hints, but keep in mind that it is not unusual that even commercial FEA software have difficulties to match high frequencies, ex. shifted or swapped modes; so computing eiginevalues is a very sensitive numerical problem - not a big issue since one usually finds the first N modes and that's all)

Alessandro


Thanks and kind regards,

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 projectchron...@googlegroups.com.
To post to this group, send email to projec...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Marten

unread,
May 12, 2017, 9:44:15 AM5/12/17
to ProjectChrono, alessand...@unipr.it
Hi Alessandro,

thanks for the quick response.

what do you mean for 'non reproductable'? I mean, do you compare the results of the constrained modal analysis vs some other software (es Abaqus) with same constraints? Or do you compare  constrained vs unconstrained, both with Chrono matrices Because in the second case I am not surprised that adding even a simple constraint somewhere in the model will change all mode shapes. Also: is there any redundancy in the constraints that you add? I mean, check the rank of Cq....  In case of redundancy, depending on the type of eigen solver, you may still get results but those will be unreliable.

With non reproducable I mean that when I repeat the exact same simulation in CHRONO (that includes constraints) I get different results (modeshapes and frequencies). I just used three constrains without any redundancy.

I think that I found the main reason for the error that I experienced. During the simulation (at each timestep) I was modifying the constrained DOF via the SetConstrainedCoords() function. Then calles ChSystem->Update; ChSystem->Setup and exported the matrices from the ChSystem via the Get...Matrix functions. I modified the constraints to get a "fixed" rotor in the modal analysis from the "free" that rotates during the simulation to get the rotationally augmented frequencies (the fixed rotor is required to get certain modeshapes). Changing the constrained DOF at the rotor, then updating the system and exporting the matrices, and then changing the constrained DOF back for the next timestep caused the issues that I was experiencing. I got the feeling that maybe not all matrices were updated in time as I sometimes also had crashes occur when calling the Get...Matrix functions directly after the calls to Update() and Setup().

Yes, but those should not interfere. Each row in the jacobian is 'almost' normalized, in most constraints, so numbers usually range in the -1...+1 interval. Probably, if the issues you get are due to numerical troubles with iterative solvers for eigenproblems (are you using Lanczos?) then it could be that the norm of the jacobian Cq is too large or too small respect to the values in M or K. In theory the norm of Cq should not change free eigenvalues, but in practice it happens that the numerical iterative eigensolver could crawl to the solution with more difficulty; therefore: try to pre-multiply or post-multiply the jacobian by some scaling and see what happens.


Thanks for this suggestion. I tried pre-scaling the Cq matrix and could see an effect on the resulting mode shapes and frequencies. I'll see if I can get better results using the scaling!

Again, thanks a lot for your help and your suggestions!

David
Reply all
Reply to author
Forward
0 new messages