Variable names change and modification of the returned value of getTangent for a convergence problem.

[z-ichinohe]

Variable Names Change

(...)ResF_0 have been renamed as (...)FresFy_0, in order to maintain consistency with other variables (...)FcapFy_0.

Modification for Convergence Problem

I encountered a convergence problem of the static analysis with P-Delta effect. One of the reasons seemed to be the drastic change of the tangent stiffness. Then, I modified the behavior as it returns the gradient between the last point and the current point when the tangent stiffness changes. Though it's not effective enough to wipe out the problem, improved the performance.

[amaelkady]

@z-ichinohe hi Kazuki, I have been running some tests on the model. There are few things:

** With respect to the convergance issue, I believe this may be due to the code returning tanget K values equal to zero. You may want to add code line to make tanget K very small number in those case instead of zero (typically 1.e-6).

** Another issue that I believe also affect the convergance is the residual branch. Specifically, I was trying the pinching model under symm, protocol and it seems the code faces problems (does not convergance; see image below) once it reaches the residual force (776 kN in this case). Here are the model parameters if you want to check further.

** I will continue to run further tests before pushing to the master branch. set Ke 203823522; set thetap 0.12; set thetapc 0.094; set thetau 0.24; set My 2772; set Mc_My 1.15; set Mres_My 0.28; set lambda 1; set c_S 1.; set c_C 1.; set c_K 1.; set c_A 1.; set kappaF 0.3; set kappaD 0.6;

[z-ichinohe]

Thank you for your testing.

I can't reproduce that behavior. Could you specify the deformation history and the modeling procedure? Have you tried implementing the zero -> 1e-6 method and is it improved? The residual branch is the only branch that have zero stiffness inherently. Thus, it might have strong relationship between them.

[amaelkady]

@z-ichinohe I haven't tried implementing the zero -> 1e-6 but this is my past experience developing the original code. This is also something that you will find in most of material codes in opensees.

I was having the issue with residual branch with all protocols that I have tried, ex,: set disp [list 0.0 2 -2 2 -2 5.5 1.5 4.5 1.5 5.5 1.5 3.5 5.5 1.5 5.5 1.5 9 5 8 5 9 5 7];

[amaelkady]

Note that in my checks above, I used a compiled opensees executable because may be these issues do not appear if you run/debug the code outside opensees.

[z-ichinohe]

I've tried to check the code with a compiled OpenSeesPy library.

I want to know how you model that. Do you use the "testUniaxialMaterial"? I think the deformation in plot is not compatible with the displacement history you noted. You may model that with a 2D or 3D spring. I agree with the method might be reasonable if it goes wrong without that.

[amaelkady]

@z-ichinohe I am running it using a tcl file. You are right, i was using a 0.02 scale factor for the protocol i sent earlier. But then again, I am experiencing this problem with any protcol.

[amaelkady]

I emailed you the tcl file that i use for debugging

[z-ichinohe]

Thank you. I confirmed the behavior you've mentioned. I'll figure out what happens through translating them to python in the next week.

[z-ichinohe]

The behavior has been improved by the zero -> 1e-6 method.

Even if it's not implemented, it succeeded with the BandGen system while it failed with the UmfPack system. I have not checked the other systems yet. However, the method might be reasonable because it's effective for the UmfPack system.

Even though the method is employed, it fails with the ProfileSPD system due to the negative stiffness branch. I don't think it's handled with some modifications in hysteresis models.

[amaelkady]

ok, that's good. Any news about the residual branch issue.

[amaelkady]

you can commit any updates you may have