Infill-RC Frame Interaction with element removal

[ankurjain1992]

Good morning Sir,
I have seen a littel difference in your infill modelling that you taught in your e-Learning and the one available on the opensees.berkeley website.

In the opensees website, they have provided fiber in the local z coordinate...

uniaxialMaterial Steel01 $infmattag $fyfibinf $EminfM 0.02;
fiber 0.0 $zfibinf $areafibinf $infmattag;


whereas, when i have seen your code for the example you solved in the e-learning, the fiber is provided in the y-direction.

section fiberSec 9 -GJ 1.00e+11 {
# Fiber 1
uniaxialMaterial Steel01 10 0.47627682527392046 500.0 0.02;
fiber 33.974723578336 0.0 6.358714266193955 10;

May i know why is this difference ?

Also, i wanted to know one thing that the fibers in the element has to be along the x-direction right. Since the local axis is along the length of the element. Kindly explain this a bit with some figure.

Thank you in advance

[STKO Team]

I have seen a littel difference in your infill modelling that you taught in your e-Learning and the one available on the opensees.berkeley website.
In the opensees website, they have provided fiber in the local z coordinate...
whereas, when i have seen your code for the example you solved in the e-learning, the fiber is provided in the y-direction.

That simply depends on the local orientation given to the beams, In the OpenSees website example, the building was oriented in another plane (if I remember correctly, the global Y was the vertical direction...).
Anyway, the point is that for the infill beams, the fibers should be oriented in the out-of.plane direciton. Now in their case, it was the local-z, in my case it was the local-y.

Also, i wanted to know one thing that the fibers in the element has to be along the x-direction right. Since the local axis is along the length of the element. Kindly explain this a bit with some figure.

This is not correct. the fibers should be places in the local Y-Z plane, exactly because they should be orthogonal to the beam-axis. The fiber strees will then be directed along the beam local-x axis

[ankurjain1992]

Thank you so much sir.

[mmc]

Dear all,

I have tried to follow the webminar to model the infills in a RC frame structure. However, the following error appears which I do not understand. I think that it is related to this topic openned a while ago. I think that it has do to with the -j that appears in the code. It also appears in the next fiberSec tag...

Also, a question arises. Is is possible to perform nonlinear analysis modelling the infills following this approach?

I have uploaded the file and I copied the error.

Thanks.

Code: Select all

Invalid #args, want: uniaxialMaterial Steel01 1084 fy? E? b? <a1? a2? a3? a4?>>
WARNING - error reading information in { }
expected floating-point number but got "(0.4594982776787085-5.35528161649479e-11j)"
    while executing
"uniaxialMaterial Steel01 1084 (0.4594982776787085-5.35528161649479e-11j) 500.0 0.02"
    invoked from within
"section fiberSec 1079 -GJ 1.00e+11 {
        # Fiber 1
        uniaxialMaterial Steel01 1080 0.009006465533472795 500.0 0.02;
        fiber 2.1851264523673315 0.0 2.185126..."
    (file "elements.tcl" line 6465)
    invoked from within
"source elements.tcl"
    (file "./main.tcl" line 13)
Presione una tecla para continuar . . .

[STKO Team]

Dear user,
We just fixed a bug in the MasonryInfillWallElement.py element. It will be fixed in the next STKO version. In the meantime here is the corrected file that you can replace in
C:\Program Files\STKO\external_solvers\opensees\element_properties\special_purpose

MasonryInfillWallElement.zip

(7.08 KiB) Downloaded 14 times

Futhermore, when using the infill wall element, the surface should be discretized with just 1 element. because it will create a diagonal truss there... su just go to mesh -> Global Sees -> Uniform by Division = 1

[mmc]

Hello,
I have updated the file and changed the mesh of the structure. However there is an error appearing. I do not know what might be wrong.

Regards.

Code: Select all

SectionForceDeformation *getSectionForceDeformation(int tag) - none found with tag: 0
ID::resize() - size specified 0 <= 0
Increment: 13 - Iterations: 1 - Norm: 8.08711329448877157917e-05 ( 12.999999999999998 % )
WARNING: symbolic analysis returns -8 -- Umfpackgenlinsolver::setsize
WARNING:UmfpackGenLinSOE::setSize : solver failed setSize()
StaticAnalysis::handle() - LinearSOE::setSize() failedStaticAnalysis::analyze() - domainChanged failed at step 0 of 1
OpenSees > analyze failed, returned: -1 error flag
ERROR: the analysis did not converge
    while executing
"error "ERROR: the analysis did not converge""
    ("for" body line 51)
    invoked from within
"for {set i 1} {$i <= $ncycles} {incr i} {
        set itime [lindex $time $i]
        set itime_old [lindex $time [expr $i-1]]
        set iU [lindex $U $i]
        set iU_old [l..."
    (file "analysis_steps.tcl" line 346)
    invoked from within
"source analysis_steps.tcl"
    (file "./main.tcl" line 15)
Presione una tecla para continuar . . .

[STKO Team]

Here is the corrected file that now reaches the end of the analysis.

MOD1_Infills_2.zip

(229.71 KiB) Downloaded 11 times

The main source of error was due to the fact that, for this kind of element removal, the only system that works is the BandGeneral, because it is the only one that correctly resizes the system matrix after element removal triggered by the remove recorder. Hopefully the OpenSees developers will fix the incompatibility with other system command soon.

Then I also changed the time-step method from Fixed to Adaptive, so that when it encounters a convergence problem, instead of stopping, it tryies to reduce the time step to overcome the convergence issue.

Finally I also included the monitor step (not mandatory), which is very useful to plot the load-displacement curve in real time during the analysis

[mmc]

Hi again,

I tried to model the infills in this new model in which the RC elements are divided to be retrofitted.. The thing is that when I tried to mesh the faces, they are divided into squares due to the other elements divisions. I do not know what to do so that the faces can be divided into one to obtain the trusses.
Also, when I merged the wire with the faces, some elements properties disappeared. I tried to add them again but they do not appear and I think that they might not be considered during the analyses. The boundary conditions are also missing and I can not define them again.

Regads.

[mmc]

Here is the corrected file that now reaches the end of the analysis.
MOD1_Infills_2.zip

The main source of error was due to the fact that, for this kind of element removal, the only system that works is the BandGeneral, because it is the only one that correctly resizes the system matrix after element removal triggered by the remove recorder. Hopefully the OpenSees developers will fix the incompatibility with other system command soon.

Then I also changed the time-step method from Fixed to Adaptive, so that when it encounters a convergence problem, instead of stopping, it tryies to reduce the time step to overcome the convergence issue.

Finally I also included the monitor step (not mandatory), which is very useful to plot the load-displacement curve in real time during the analysis

Hi:
I have analysed the model and the pushover curve stills stops at a very low percentage... There is still a convergence problem. I think that for nonlinear analysis this procedure is not suitable yet... What do you think?
Regards.

[STKO Team]

I have analysed the model and the pushover curve stills stops at a very low percentage... There is still a convergence problem. I think that for nonlinear analysis this procedure is not suitable yet... What do you think?

No, it is weird... With the corrected file that I sent you, I reach the 100% of the analysis:

i1.png (35.25 KiB) Viewed 254 times

I tried to model the infills in this new model in which the RC elements are divided to be retrofitted.. The thing is that when I tried to mesh the faces, they are divided into squares due to the other elements divisions.

Yes, unfortunately the Infill element, assumes that the face is discretized with only 1 quad element.
If you really need to discretize your beams, then you need to:

• draw the frame and the faces as 2 separated geometries, in this way they can have a different discretization
• attach the corners of the faces with the corner of the frames with an interaction
• create an EqualDOF condition for that interaction. In this way, the 2 separated geometries will be "glued" together with kinematic constraits

However, probably you do not really need to discretize your mesh for retrofitting. If what you need to do, is to assign different sections at different locations of a single beam element, you can use the User-Defined integration scheem (in the beam physical property) instead of the standard Lobatto. In this way you can define how many gauss points you want, their location, their weigth, and their sections.

Also, when I merged the wire with the faces, some elements properties disappeared

It happens because when "merging" an edge with a property, with another edge (of a face) without a property, the "Merging" algorithm just pick one of them randomly, so it cannot guarantee that the property assignment will be held.
However you can re-assign it. You just need to go into sub-selection mode with only edges selectable, and then select your edges and drag-and-drop your property