Hallo,
I am trying to run a cyclic analysis on a single bay bare frame, using displacement time-history (static time-history analysis). The concept is similar to the verification example 1 of the software validation, where comparison with experimental results is performed.
The problem is the configuration of the experiment I am trying to reproduce. The horizontal displacement is imposed in such a way that always results in beam compression. Therefore, application of displacement on the left corner node of the frame is not accurate, since during the reverse cycle (negative displacement) it will result in tension force developing at the beam.
I want to ask the following questions:
1) Is it possible to apply successively the displacement histories at the opposite nodes of the frame? I didn't seem to manage it at my first efforts..
2) I tried to use link gap_hk elements to apply the displacement at both opposite nodes, in order to impose motion transfer only in the direction related to beam compression. The trick worked as intended, yet I obtained a few "parasitic" spikes at beam axial force when loading reversal takes place, that I would be happy to get rid of.
Any ideas?
Cyclic analysis with constant beam compression
Re: Cyclic analysis with constant beam compression
Hi greser. I wonder if it might be possible to use an incremental displacement load applied at the left nodes with a positive curve multiplier for stage 1 of the analysis. Then add a second stage which uses the same curve, but with a negative multiplier and applied to the right nodes. This could be continued, though I am not sure what the maximum number of stages allowed is. The curve could be a simple straight ramp up to the maximum at your desired time. Just a thought.
Best of luck with the work.
Best of luck with the work.
Tim Huff
Re: Cyclic analysis with constant beam compression
Hallo huffte, thanks for your response.
I am not sure if your suggestion is feasible. When I define the Applied Loads I can only relate the imposed displacement on a node with a predefined Curve and not with a specific analysis stage. Therefore, it will not be possible to terminate the loading on the left node when stage 1 ends (positive displacement), keep the left node loading inactive during stage 2 (negative displacement) and then reapply when stage 3 begins (positive displacement again).
Is there a way to define a specific stage and not a full loading curve on a node during loading application?
I've already tried applying successive time-history curves with different start-end times for the opposite nodes, using either a single or multiple analysis stages, without any success (error message).
If the experiment was force controlled it would have been much easier, since I could just provide the full static time-history on each node using zero force values during the negative loading direction phase.
I am not sure if your suggestion is feasible. When I define the Applied Loads I can only relate the imposed displacement on a node with a predefined Curve and not with a specific analysis stage. Therefore, it will not be possible to terminate the loading on the left node when stage 1 ends (positive displacement), keep the left node loading inactive during stage 2 (negative displacement) and then reapply when stage 3 begins (positive displacement again).
Is there a way to define a specific stage and not a full loading curve on a node during loading application?
I've already tried applying successive time-history curves with different start-end times for the opposite nodes, using either a single or multiple analysis stages, without any success (error message).
If the experiment was force controlled it would have been much easier, since I could just provide the full static time-history on each node using zero force values during the negative loading direction phase.
Re: Cyclic analysis with constant beam compression
Ah, I think I see your point now, greser. I wonder if the following strategy - or one similar - might work.
1. Define three extra nodes. Call them EX1, EX2, and EX3. EX1 is coincident with the left node at the top of the frame you wish to push to the right. EX2 is coincident with the right node at the top of the frame you wish to push to the left. EX3 is at midspan and somewhere above the beam.
2. Define link elements LINK1 and LINK2. LINK1 is from the left frame node to EX1. LINK2 is from the right frame node to EX2. The links are asymmetric and linear with very high positive stiffness and very low negative stiffness in the 1-direction. The links would have symmetric and very high stiffness in the local direction which corresponds to vertical.
3. Define a constraint with EX3 as the master and EX1, EX2 as slaves.
4. Apply the desired displacement history to node EX3.
Just another thought. I'll be curious if you find something that works.
1. Define three extra nodes. Call them EX1, EX2, and EX3. EX1 is coincident with the left node at the top of the frame you wish to push to the right. EX2 is coincident with the right node at the top of the frame you wish to push to the left. EX3 is at midspan and somewhere above the beam.
2. Define link elements LINK1 and LINK2. LINK1 is from the left frame node to EX1. LINK2 is from the right frame node to EX2. The links are asymmetric and linear with very high positive stiffness and very low negative stiffness in the 1-direction. The links would have symmetric and very high stiffness in the local direction which corresponds to vertical.
3. Define a constraint with EX3 as the master and EX1, EX2 as slaves.
4. Apply the desired displacement history to node EX3.
Just another thought. I'll be curious if you find something that works.
Tim Huff
Re: Cyclic analysis with constant beam compression
I managed to try this out on a simple frame and it did work, greser. The displacement and hysteresis results made sense and the beam stayed in compression throughout every cycle.
Tim Huff
Re: Cyclic analysis with constant beam compression
huffte, thanks again for your help, your last comments are exactly what I am talking about.
I have already tried something similar, using two gap-hook link elements connected to the left and right node and it did work. The only problem was that during the displacement reversal, an artificial (?) spike appeared on the axial force value of the beam (time history values). It was not very significant since at this instant the beam bending moment is close to zero, therefore the beam section is not near yielding conditions. Yet, I would like to get rid of those spikes.
In your test if you check the developing beam compression do you see any similar spikes when the opposite link starts to apply the loading? I will try later the link type you suggest and post the results.
I have already tried something similar, using two gap-hook link elements connected to the left and right node and it did work. The only problem was that during the displacement reversal, an artificial (?) spike appeared on the axial force value of the beam (time history values). It was not very significant since at this instant the beam bending moment is close to zero, therefore the beam section is not near yielding conditions. Yet, I would like to get rid of those spikes.
In your test if you check the developing beam compression do you see any similar spikes when the opposite link starts to apply the loading? I will try later the link type you suggest and post the results.
Re: Cyclic analysis with constant beam compression
huffte I tried your idea.
It did work somehow better compared to my efforts, since only a couple of spikes at the beam axial force appeared in the first few cycles.
I am posting below 2 snapshots from the developing axial force at the frame elements. In red color is the beam axial force which is always under compression. You can see what the spikes I am referring to look like..
greser analysis results (axial forces, beam in red color)
http://i60.tinypic.com/33cq5qc.jpg
huffte suggestion analysis results (axial forces, beam in red color)
http://i57.tinypic.com/2gxi7gy.jpg
The main difference of my effort was that I did not use a master node to impose the motion. I applied the motion at both the EX1 and EX2 nodes at the same time. Although in theory is exactly the same, my approach probably created some numerical issues that resulted in those spikes you can see in the snapshot. Your suggestion seems to be more efficient (if you exclude the rather annoying spike at the first loading cycle).
One question, do you suggest to use a master-slave constraint for all 6 DOFs? I had to use this constraint, along with zero restraints of EX3 node, to achieve those results. Yet I cannot understand why a constraint of the x-direction alone is not working.
Also, why use large stiffness in the vertical link properties since I do not want to transfer any vertical motion? (of course there is no vertical motion in the first place since the loading is horizontal).
Thanks again for your very helpful comments.
It did work somehow better compared to my efforts, since only a couple of spikes at the beam axial force appeared in the first few cycles.
I am posting below 2 snapshots from the developing axial force at the frame elements. In red color is the beam axial force which is always under compression. You can see what the spikes I am referring to look like..
greser analysis results (axial forces, beam in red color)
http://i60.tinypic.com/33cq5qc.jpg
huffte suggestion analysis results (axial forces, beam in red color)
http://i57.tinypic.com/2gxi7gy.jpg
The main difference of my effort was that I did not use a master node to impose the motion. I applied the motion at both the EX1 and EX2 nodes at the same time. Although in theory is exactly the same, my approach probably created some numerical issues that resulted in those spikes you can see in the snapshot. Your suggestion seems to be more efficient (if you exclude the rather annoying spike at the first loading cycle).
One question, do you suggest to use a master-slave constraint for all 6 DOFs? I had to use this constraint, along with zero restraints of EX3 node, to achieve those results. Yet I cannot understand why a constraint of the x-direction alone is not working.
Also, why use large stiffness in the vertical link properties since I do not want to transfer any vertical motion? (of course there is no vertical motion in the first place since the loading is horizontal).
Thanks again for your very helpful comments.
Re: Cyclic analysis with constant beam compression
After several efforts i now have more questions than answers!
Let me present once again the case I am working and the problems I am facing.
The experiment I want to reproduce is a single-story single-bay RC frame, with horizontal cyclic displacement time-history imposed successively on the opposite frame joints. This configuration results in beam under compression during the entire experiment.
In order to achieve a response where the beam is always under compression, theoretically it should be enough to:
a) Use 2 links, Link1 at the left and Link2 at the right end of the beam (at the beam-column joint). Nodes EX1 and EX2 of the links are connected with internal nodes IN1 and IN2 of the frame respectively.
b) Use asymmetric (or gap-hook type) properties in Link local axis 1, introducing a very large stiffness in compression and almost zero stiffness in tension (or zero gap but infinite hook length). Thus, link can only transfer loading on the frame when it is under compression. Stiffness properties in the other directions should be theoretically indifferent (unless close to zero values cause numerical problems).
c) Impose the cyclic loading (displacement) simultaneously at the start nodes EX1 and EX2 of each link (either directly, or using an equal DOF constraint in the X direction, or even using a third external master node where the motion is imposed).
The expected behavior during analysis would be the application of the displacement history only at the frame node where the link is under compression. For example, positive displacement transfers loading only on node IN1 through the left link joint EX1 where the motion is applied, since only Link1 is under compression. Since the beam is expected to present a non-zero deformation under compression, the opposite beam end joint IN2 will always have a smaller horizontal displacement compared to the imposed at IN1. Therefore, the opposite Link2 should remain inactive during the first half-cycle.
During the reversal of the displacement, the exact same thing will take place only this time at the opposite node IN2, where displacement loading will be applied through EX2 and Link2 that is now under compression.
Main problem during analysis:
When the loading is applied at the left node IN1, the horizontal displacement of node IN1 should be larger than the displacement of the opposite beam node IN2 (due to beam axial deformation during compression). Yet, horizontal displacement of IN2 is larger than IN1.
Isn't this opposite to the expected behavior or am I missing something?
The same takes place even without the links, when I am analyzing a frame under horizontal force (or displacement) using infrm elements. It seems that the beam under compression increases instead of decreasing slightly its length. Could this be attributed to different fibre lengths at the section due to moment-axial force combination, that results in a decrease of the length at the centroid where node IN2 is presumably located?
Only when "Run with Linear elastic properties" is checked, the beam decreases its length under compression.
Taking into consideration the above, it is not possible to employ the 2-Link configuration I mentioned earlier, in order to impose a beam-compression-only horizontal loading on the frame. The reason is that both links are always under compression, due to the lengthening of the beam behavior I described.
I managed to achieve the desirable response using some tricks, in the following two cases
1) Use the above configuration with Link1 and Link 2, yet create different loading time histories for nodes EX1 and EX2. For example, during the first half-cycle of positive displacement, the displacement values imposed on EX2 were "artificially" increased, in order to achieve that Link2 is under tension and remains inactive (despite the inexplicable slight increase of the beam length).
2) I used an external master node EX3 where I applied the motion, and created a "Rigid Link" connection (all DOFs) with slave nodes EX1 and EX2. This type of constraint, along with large stiffness values in all the other Link directions, should have resulted in all kinds of mistakes from the modeling point of view. Surprisingly (!!!) it was the only combination of master-slave constraint and Link properties where analysis both converged and provided meaningful results (e.g. beam decreased length during compression, zero link axial force during tension stage of imposed loading etc).
Considering that this type of constraint and Link properties, transfers not only horizontal loading but also forces and moments in all directions, I can only assume that this is a coincidence (?)
I believe that the best solution to this problem is to be able to provide successive time-histories to different nodes of the structure in a future program version.
I am sorry for the very very long post [:)]
Let me present once again the case I am working and the problems I am facing.
The experiment I want to reproduce is a single-story single-bay RC frame, with horizontal cyclic displacement time-history imposed successively on the opposite frame joints. This configuration results in beam under compression during the entire experiment.
In order to achieve a response where the beam is always under compression, theoretically it should be enough to:
a) Use 2 links, Link1 at the left and Link2 at the right end of the beam (at the beam-column joint). Nodes EX1 and EX2 of the links are connected with internal nodes IN1 and IN2 of the frame respectively.
b) Use asymmetric (or gap-hook type) properties in Link local axis 1, introducing a very large stiffness in compression and almost zero stiffness in tension (or zero gap but infinite hook length). Thus, link can only transfer loading on the frame when it is under compression. Stiffness properties in the other directions should be theoretically indifferent (unless close to zero values cause numerical problems).
c) Impose the cyclic loading (displacement) simultaneously at the start nodes EX1 and EX2 of each link (either directly, or using an equal DOF constraint in the X direction, or even using a third external master node where the motion is imposed).
The expected behavior during analysis would be the application of the displacement history only at the frame node where the link is under compression. For example, positive displacement transfers loading only on node IN1 through the left link joint EX1 where the motion is applied, since only Link1 is under compression. Since the beam is expected to present a non-zero deformation under compression, the opposite beam end joint IN2 will always have a smaller horizontal displacement compared to the imposed at IN1. Therefore, the opposite Link2 should remain inactive during the first half-cycle.
During the reversal of the displacement, the exact same thing will take place only this time at the opposite node IN2, where displacement loading will be applied through EX2 and Link2 that is now under compression.
Main problem during analysis:
When the loading is applied at the left node IN1, the horizontal displacement of node IN1 should be larger than the displacement of the opposite beam node IN2 (due to beam axial deformation during compression). Yet, horizontal displacement of IN2 is larger than IN1.
Isn't this opposite to the expected behavior or am I missing something?
The same takes place even without the links, when I am analyzing a frame under horizontal force (or displacement) using infrm elements. It seems that the beam under compression increases instead of decreasing slightly its length. Could this be attributed to different fibre lengths at the section due to moment-axial force combination, that results in a decrease of the length at the centroid where node IN2 is presumably located?
Only when "Run with Linear elastic properties" is checked, the beam decreases its length under compression.
Taking into consideration the above, it is not possible to employ the 2-Link configuration I mentioned earlier, in order to impose a beam-compression-only horizontal loading on the frame. The reason is that both links are always under compression, due to the lengthening of the beam behavior I described.
I managed to achieve the desirable response using some tricks, in the following two cases
1) Use the above configuration with Link1 and Link 2, yet create different loading time histories for nodes EX1 and EX2. For example, during the first half-cycle of positive displacement, the displacement values imposed on EX2 were "artificially" increased, in order to achieve that Link2 is under tension and remains inactive (despite the inexplicable slight increase of the beam length).
2) I used an external master node EX3 where I applied the motion, and created a "Rigid Link" connection (all DOFs) with slave nodes EX1 and EX2. This type of constraint, along with large stiffness values in all the other Link directions, should have resulted in all kinds of mistakes from the modeling point of view. Surprisingly (!!!) it was the only combination of master-slave constraint and Link properties where analysis both converged and provided meaningful results (e.g. beam decreased length during compression, zero link axial force during tension stage of imposed loading etc).
Considering that this type of constraint and Link properties, transfers not only horizontal loading but also forces and moments in all directions, I can only assume that this is a coincidence (?)
I believe that the best solution to this problem is to be able to provide successive time-histories to different nodes of the structure in a future program version.
I am sorry for the very very long post [:)]