IMKBilin implementation confirmation

[z-ichinohe]

Though I'm not sure that current IMKBilin have a specific problem, I'm working on revising the code. It may improve the maintainability to build it again based on the principle same as IMKPeakOriented and IMKPinching.

Then, I've had four questions.

1. Unloading stiffness after it reaches the residual branch. In line No. 230, unloading stiffness is revised as 0.5*Ke if it has already reached the residual branch. Is it a correct implementation? I think it's different from PeakOriented or Pinching and quite a rough method to reduce the unloading stiffness. I also want to know whether residual branch ahead of pre-capping branch is effective or not. You can see that in fig 2.
2. Yield and failure in positive and negative. I noticed that Pinching has two yield flag for each direction and only one failure flag not separated by the direction. However, Bilin has two failure flag for each direction and only one yield flag. It may be reasonable because each represents reinforced concrete or wood and steel. I want to confirm that it's your intended implementation.
3. Post-Capping Branch Stiffness Re-consideration In line No.253-258, post-capping stiffness is reconsidered reflecting the yield point deterioration, when residual strength is not zero. (I think line No. 254 just means initial stiffness where residual strength is zero.) As the project point of the post-capping branch is fixed, it means the strengthening from the backbone curve.
4. Pre-Capping Branch Stiffness Re-consideration In line No. 266-271, pre-capping stiffness is reconsidered. I thought it means the situation in fig 2. With pre-capping branch fixed at the yield point, it seems strange for me. Let me know whether it's exactly what you intended or not.

[amaelkady]

So far, there are no major problems with IMKBilin, but feel free to make the code consistent with the others. I think that will be beneficial.

Regarding your questions,

1. Yes, the unloading stiffness deteriorates by 50% when it reaches the residual branch. This is exaplained in the original research by Ibarra. I would not consider the residual branch effective ahead of pre-capping branch. So, in fig 2, I would move from point 7 to 9 directly. This is more representative physically. I understand that this might not be the case in the current code which consider it effective.

2. With respect to yielding, I used two yielding flages in the IMKPinching model just to fix a reported bug related to force overshooting. That's the only reason. I think this is not an issue though for your updated code. With repsect to failure, I used two flags in IMKBilin so that I can set the boundary moment equal to Mres in the opposite direction (Line 434) which is similar to what we observe in steel behaviour. Perhaps, the same can be done for the pinching/peakoriented models since these model can represent flexible steel connections as well as concrete components. In any case, there is no strict rule here; it's debatable.

Let me think about questions 3 and 4 carefully because I don't remeber the concept behind it

[amaelkady]

With respect to fig 1, the backbone shall be updated by updating (i.e, deteriorating) the My and the projected Mmax. The slopes are then computed based on the updated values. Note here that with this rule, Kpc value will be going lower (i.e., it keeps going flat as you load further) which is representative of what is observed experimentaly.

[z-ichinohe]

Thank you so much. I'm so satisfied to hear your understanding and intention because I'm new to bilinear model.

In pinching model, two yielding flags seem to prevent the positive/negative deterioration from starting when it doesn't yield in positive/negative. I thought that it might be reasonable in concrete. I now confirmed that the deterioration starts from the first excursion towards negative in your illustration and Ibarra's illustration. I will fix the code.

To conclude your remarks, fig 1 have no problem though the branch 7-8 must be underneath the branch 2-3 where basic strength and post-capping strength deteriorate at the same rate. Fig 2 should not be 6->7->8->9 but should be 6->7->2 and there is no residual branch ahead of pre-capping branch but the unloading ends at the residual strength and go up on the backbone curve.

At the last, I have one more question. In bilinear, the yield point displacement Dy is calculated with Fy and Kunload (or K_j) instead of Ke. It may accelerate the deterioration of basic strength. Is it correct? I thought that just deteriorating the projected My may be simple and straight-forward way.

[amaelkady]

@z-ichinohe sorry, I just noticied your meesage above.

Could clarify what code line you are refering to regarding your question about Dy being calcaulted based on Kunload?

Also, please let me know if you have any last minute updates for the IMKPinching and IMKPeakOriented models before I submit to OpenSees. FYI, I have conducted several trials on the models and they seem to be stable and behave properly.

[z-ichinohe]

@amaelkady It can be seen at the line No. 265 and 290. K_j is the unloading stiffness, which is deteriorated at the line No. 223. I have some updates for the PeakOriented and Pinching models because Yield_Flag problem I have raised here must be fixed and Bilin had some better parts when calculating backbone deteriorations.

[amaelkady]

@z-ichinohe Great. Please commit these updates if they are ready. I will check you question and let you know.

[amaelkady]

@z-ichinohe regarding your question, I think you are right, there is no reason to compute Uy based on K_j, Ke can be used instead.

Also, please commit any updates you have for the other models cause I'm planning to submit the updated model to OpenSees by Monday.

[amaelkady]

@z-ichinohe Hi Kazuki, I commited the modified IMKPinching and IMKPeakOriented models today to OpenSees. M. Scott will probably merge them tomorrow. I have also specified both our names and contact info in the documentation such that we can be contacted in the future if there are any issues.

Moving forward, I recommend you fork the master Opensees repo (if you have not done so already) and make any updates/commits directly to the main branch. Ofcourse, you can also do this here first if you want me to check something before commiting to the master repo.

I think the IMKPinching and IMKPeakOriented models are reasonably stable now. There are some minor issues that need fixing but this can be done in due coarse. One issue I noted for example is if you have a constant-amplitude cyclic protocol, the material seems to keep deteriorating without stabilizing at the residual strength (see below). For this example, I'm using the following paramters:

set Ke 10000.; set thetap 0.01; set thetapc 0.05; set thetau 0.08; set My 100.; set Mc_My 1.10; set Mres_My 0.10; set lambda 0.50; set c_S 1.00; set c_C 1.00; set c_K 1.00; set c_A 1.00; set D_pos 1.00; set D_neg 1.00;

and a protocol oscillating around 0.02

[z-ichinohe]

@amaelkady Thank you! I think it occured because line No. 248-250 is in the else clause. I'll have it fixed in this weekend.

[z-ichinohe]

@amaelkady This new Bilinear model shown below might satisfy the discussion above. Blue solid line is older one and orange dotted line is newer one. There are two major differences. Whether the residual branch is effective ahead of pre-capping branch or not and unloading stiffness deterioration speed. Then, I've got two questions. Question 1. At the line No. 424, if Failure took place in a given direction the Boundary Moment will be set the residual strength in the opposite direction. However, if fail flag is reached in any loading direction, the current moment will be set equal to zero. Which will be more appropriate behavior? I chose the latter one because it's the behavior the current Bilin returns. Question 2. I utilized same stiffness deterioration part as the one used in PeakOriented and Pinching. However, it doesn't coincide with the behavior in the current Bilin. Mine deteriorates faster than the current one. Though I could have not found out which part of sources made that, the doubled reference energy might be one of the causes. Could I make it same as PeakOriented and Pinching? Issue #3 have some conversations about that in PeakOriented and Pinching. At the last, you can see the modified PeakOriented model satisfy that the deteriorated backbone can't be lower than the residual strength in the bottom and rightmost plot.

[amaelkady]

@z-ichinohe Thanks. Regarding your questions:

1) If failure took place in one direction, then I would revert to the residual in the other direction. This is representative of reality; may be the current code might have missed that.

2) Yes, you can use the same stiffness deterioration as the IMKPinching and IMKPeakoriented.

[z-ichinohe]

@amaelkady Thank you. The residual strength backbone in the opposite direction where failure took place in one direction has been implemented. You can see them in the fifth row. Besides, the blue line represents the model merged to OpenSees/OpenSees yesterday, so strength deterioration in its negative region doesn't begin at the first excursion towards negative even if it has yielded in the positive. It's now repaired as all deteriorations begin after it experienced yielding. Then, I've got two more things I would like to confirm.

1. The Bilin model will have the residual strength even after failure took place in the other direction. However, the PeakOriented and Pinching model won't have the strength after failure took place in any directions.
2. Kpc will be reduced in the lines No. 257-262. The line No. 258 means that Kpc won't be reduced anymore when it doesn't have residual branch. Is that right?

[amaelkady]

@z-ichinohe response to quieries:

1) Yes, let's keep it like that for now.

2) I would only keep Line 261 and remove the rest.

One more thing, please commit any changes to the amaelkady/Updated-IMK-Models-for-OpenSEES as well so I can keep track. Also, tag me in any commits you make to OpenSees/OpenSees. By the way, I don't see your merge/commit request to OpenSees/OpenSees that you mentioned above.

[z-ichinohe]

@amaelkady Then, should I just keep Line 261 alone and remove if clauses around that? After that I'll make pull requests for you and OpenSees. The merge I mentioned above is what you had requested. OpenSees#1029

[amaelkady]

@z-ichinohe yes keep line 261 and delete the rest of the if clauses