Page 1 of 1
DB and FB elements
Posted: 14 Mar 2011, 18:55
by Andre
Hi,
Is it inadvisable to use infrmDB and infrmFB in the same model? I was thinking I could use infrmFB for columns and infrmDB for beams where reinforcement patterns change. I'm not sure if mixing these two types of elements will create convergence problems.
Re: DB and FB elements
Posted: 15 Mar 2011, 17:44
by seismosoft
Hi André,
No, mixing those two elements in the same model will not necessarily cause numerical difficulties.
Seismosoft Support
Re: DB and FB elements
Posted: 15 Mar 2011, 23:04
by kalianis
How we should model beam reinforcement (which is different at supports and midspan) when assessing reinforced concrete structures using nonlinear static analysis?
Re: DB and FB elements
Posted: 19 Mar 2011, 01:09
by seismosoft
Simply define elements with different cross-sections. Seismosoft Support
Re: DB and FB elements
Posted: 24 Mar 2011, 21:39
by kalianis
Thank you for your answer. Should i define these elements using force based or displacement based elements? Which one do you suggest? If using force based can we divide the member in 3 elements (so that we can have different reinforcement patterns at supports and midspan) or element can only be divided in 2, 4, 5 and 6 sub-elements? When using section additional weight in section properties menu in what units do we need to enter the mass, in tonns or tn/m?
Finally when assessing a structure is it worth of modelling the beams this way (with different reinforcing patters) and distribute the load to the beams or we can just use the simpler way of modeling the beam as one element (with support reinforcing pattern only) and lamp the mass at nodes? In seismosoft manual it says that modelling the beam as one element has the advantage of readily reading chord rotations. This is not the case when subdividing the member in elements?
Thank you in advance.
Re: DB and FB elements
Posted: 26 Mar 2011, 01:42
by Romain
Hi Kalianis,
In general i would recommend you to use FB elements. FB elements make use of a more sophisticated formulation with respect to DB elements providing, this way, a more accurate representation of the members response. However, especially in large models, the use of FB elements may significantly increase the time to process the analysis.
You can define several FB elements for each member (similarly to DB elements). However, following this procedure, the advantage of directly extract the chord rotations of the member is lost.
Because in columns, the reinforcement typically doesn't change over the length, the use of a single FB element is clearly recommended. On the other hand, defining one beam element with the support reinforcement (using lumped mass at the beam column joints) may lead to nonconservative results. The reason behind this fact is not on the implementation of a single beam element but instead in concentrating the mass at the joints, ignoring, this way, the moments developed due to gravity loads.
In summary, in order to obtain the correct estimation of the beams chord rotations you should define the beams with the correct reinforcement (usually 3 elements) and the mass distributed over the element. The additional mass in the section properties should be defined in tonnes/m.
In my personal opinion, you may follow the approximate procedure to do a fast assessment of the building. Nevertheless, you must be aware that the results may not be representative of the real behaviour.
Cheers,
Romain
Re: DB and FB elements
Posted: 26 Mar 2011, 21:18
by kalianis
Romain thank you very much for the answer you provide me. Can you please explain me how chord rotations can be extracted in the case of having more than one elements per member? Moreover does Seismostruct have the option of dividing the element in 3 elements because in element subdivision option it can only subdivide a member in 2, 4, 5, and 6 elements. Lastly when subdividing a beam member do we need to reduce the number of integration sections?
Thank you
Re: DB and FB elements
Posted: 28 Mar 2011, 12:12
by Romain
Hi Kalianis,
Chord rotation is defined as the angle between the tangent to the axis of the (deformed) element and the chord connecting that end with the end of the shear span (point of contraflexure). You can find additional information and approximations in the following paper: "Mpampatsikos, V., Nascimbene, R. and Petrini, L. (2008) A Critical Review of the R.C. Frame Existing Building Assessment Procedure According to the Eurocode 8 and Italian Seismic Code, Journal of Earthquake Engineering, 12(1), 52–82".
You don't need to define exactly 3 elements. These are typically the minimum needed to account for the change of reinforcement pattern in beams. Plus, you can define the elements without using the subdivision option.
Regarding the number of IP's, if you choose to discretise the element then you should use less integration sections (2-3).
Cheers,
Romain
Re: DB and FB elements
Posted: 28 Mar 2011, 23:04
by seismosoft
Hi all,
Quick note on the number of integration sections to define in subdivided 'infrmFB' elements. Contrarily to what is currently suggested in the Help System (we will updated it in the next release), 3 or 4 integration points should be employed, instead of 2-3.
We take this opportunity to also re-emphasise that it is well within our future plans to introduce 'infrmFB' elements with multiple sections, so as to avoid the need for subdivision (and all the associated cumbersomeness). We have not done so yet simply because it requires a complete restructuring of the entire memory management system of the software.
Seismosoft Support