Difference in natural period

[hyunee]

Hello,
I just found that there is a little difference in the natural period of a structure when I run it with ver. 2.3.2 and ver. 2.4.3.
I used exactly the same script with exactly the same structure. I run the example problem of 2-Story Steel Moment Frame with Concentrated Plasticity.
When I run this example with ver. 2.3.2, it gave me the natural period of 0.826 and 0.223, and 0.820 and 0.208 with ver. 2.4.3. Although the difference is quite small, I just wonder that this difference is meaningless or not. I think this difference can be much larger with higher structure.

Thank you.

[andreascj]

Does doing modal analysis before and after gravity make a difference?

[hyunee]

I don't think the gravity load makes this difference. When I used a 9-story building model, I got quite large difference in the natural period between ver. 2.4.3 and ver. 2.3.2. I think the gravity load can make difference to the result of analysis but the natural period.

[fmk]

we made a small change to eigen command, in that now, if an analysis already exists, it will use the existing solver and constraint handler. the solver might give small discrepencies, the constraint handler larger. the default used to be a transformation for the constraint handler. if this is not your issue you will need to send the example.

[hyunee]

With my 9-story building model, I got 1.09 sec in ver. 2.4.3 and 2.19 sec in ver. 2.3.2 for the first mode natural period respectively. I think this is too large discrepancy.
Is this a possible discrepancy due to the constraint handler? Even though I got quite different natural period, the actual results from dynamic analysis were almost the same. However, I use the natural period for the response spectrum analysis and this large discrepancy in natural period can be a very important issue to me.

[fmk]

i will need to see the script.

[hyunee]

Here is my script. The actual model is 9-story building.
Thank you.

[fmk]

i need you to email me it and all supporting files in a single zip. fmckenna ATTTTTTT berkeley DDOOOOTTTTT edu

[fmk]

the problem relates to a change in the default system that is used in the eigen command.

As mentioned, we changed the eiegen command to work with the current analysis object that has been defined (we did this to cut down on the memory requirements and for performance reasons for larger models). In the change we kept it so it would also work if no analysis had been previously created. The default stuff chosen was modified slightly, instead of using a BandedGeneral solver I choose to use a ProfileSPD (for speed reasons). The original was a BandedGeneral solver.

If you want to see the same results as before simply put the command
system BandGeneral
before the eigen commmand.

The question you may ask is why is the Profile solver failing? if the BandGeneral works and this fails it would typically indicate the system is negative definite or badly conditioned. however if i put a static analysis and issue an analyze 1 with 0 loads i don't get the error message. this indicates the problem is in the iterations going on for the arpack solver.

[andreascj]

This problem with change in frequency has also been noted before:

http://opensees.berkeley.edu/community/ ... =2&t=48413

http://opensees.berkeley.edu/community/ ... =2&t=47390

In both above, a difference of up to 10% in periods was found between carrying out analysis before and after applying gravity. Even with elastic elements. fmk, could you please confirm this and provide some insights? Thanks.

[fmk]

when the eigen command is issued OpenSees simply calculates the eigenvalues for the state of the model at that time using the system specified and constraint handler specified .. it is as simple as that.

so why would the eigenvalues change say before and after a gravity analysis:
1) the most significant change in eigenvalues is simply because the model is not elastic. if model is nonlinear, particularly if it involves concrete, and the tangent of the materials changes depending on the state of stress it is in (0 stress, stress after gravity analysis (think fibers in tension if concrete)) then the eigenvalues are going to change.
2) default transformation method is used if no analysis exists, if user has penalty method in analysis, eigenvalues will shift due to way constraints are enforced.
3) like transformation, solver change may effect .. but this is roundoff and results should not vary much. if they do, it means the model is sensitive to roundoff .. think poorly conditioned .. think model nearly unstable.

[andreascj]

Thanks fmk for the explanation that (a) constraint handler and (b) SOE solver affect the results of eigen analysis. Is is true that the default for these in the version 2.4.3 are (a) transformation and (b) ProfileSPD, respectively? But it appears that reissuing constraint handler and solver to these default after performing an analysis with different constraint handlers and solver has not effect.

[fmk]

1). yes those wehere the defaults

2 .yes they effect the results BUT I am only included them as they can have an influence on result. The biggest influence on the eigenvalues is the state of the model (especially if before and after gravity .. one should probably never even bother with eigenvalues before gravity unless the model is elastic as they are pretty meaningless)

as to their influence, it depends on the model (does it have MP Constraints like say a rigid floor) and the condition number of the matrix. If no MPs, changing Transformation method will have no effect and if you do the difference between Penalty and Transformation will depend on the size of the Penalty factors (if reasonable values for Penalty factors the difference will be small). Likewise, If model not near to being unstable, the system will have no effect either as condition umber of matrix is probably pretty low. This is because you only start seeing noticable differences in solution to Ax=b, if A is ill-conditioned.