Integration Point in DB-Element

[bassking]

Hello, in the case of infrmDB how many integration sections the program takes in count? i can't find this information on the help of the program

[Stelios_Antoniou]

There are two integration section in infrmDB

[seismosoft]

This information is indeed available in the Help System, in chapter 'Theoretical background.../Material Inelasticity'.

Seismosoft Support

[TUC]

Hello,

In this help topic it also mentioned that the 2 integration points are not placed at the 2 ends of the element ([-0.577 0.577]*L/2). If it is so, we are not able to model plasticity at the end of a DB element(?)

[seismosoft]

It depends on what you mean with "end of element". On this issue, we strongly suggest you to read some of the bibliography suggested in the Help System, in particular the publication by Calabrese et al (2010).

Seismosoft Support

[TUC]

Hi,

The integration points are placed at the "end of an element" when their coordinates are [-1 1] or if there are three [-1 0 1] etc. This happens when the I.P's are >= 4, why it's not the same for two or three?
I mean, why the Gauss-Lobato rule is not used in case of two or three I.P's and it's used only when the number of I.P are >=4?

[TUC]

The answer is that when only few control integration sections are used along an element (i.e 2 or 3) then the Gauss (-Legendre) integration rule is preferable instead of the (Gauss-) Lobatto because the later yields a further overestimation of the element stiffness, which sums up to the intrinsic one due to the displacement formulation.

I think that the above explanation could be added in SeismoStruct¢s help system, it would be helpful for the user.

Thank you.

[jpacheco]

Hi TUC,

Your answer is not really correct, in a straightforward way here's how things work:

- Displacement-based (infrmDB) element: it corresponds to the classical finite element (first in chronological order), wherein certain displacement functions define the displacement along the element. This feature constrains inelasticity to spread artificially along the infrmDB element, and as a consequence it turns out that there are no practical advantages in using an integration scheme other than Gauss(-Legendre) with two integration points (IPs), which is what SeismoStruct employs. That is also the underlying reason for the need to subdivide each structural member in a number of infrmDB elements. Using (Gauss-)Lobatto and/or increasing the number of IPs produces, in general, no noticeable improvement in the results of infrmDB (and greatly augments computational time).

- Force-based (infrmFB) element: it is a more recent creation, wherein inelasticity is not constrained by any artificial features of the finite element development. E.g., moment, shear, or axial force diagrams inside the infrmFB element are just as you expect them to be (i.e., the ones you would trace by hand; note that the same does not apply to infrmDB!). The only approximation lies in the computation of the integrals required to obtain displacements and stiffness (as a matter of fact, flexibility) matrices, which have to be assembled from sampled contributions at a few IPs. Since inelasticity can be particularly relevant at the extremities, using (Gauss-)Lobatto quadrature is the adequate choice (once again, such reasoning does not apply to infrmDB, due to its particular features). The latter requires the use of a minimum number of 3 IPs (so that at least the linear elastic response can be obtained), but a larger number of IPs will in general be required to acceptably characterize the distribution of inelasticity along the member, as one could expect. I would say that at least 4 IPs should be used, but typically 5-7 IPs can be considered.

There are other issues that can interfere with the choice of the number of IPs, namely localization, but that is a different story.

I know that a new version of SeismoStruct will be coming out soon (with very exciting new features!), and I believe force-based elements will be using only (Gauss-)Lobatto integration, starting at 3 IPs (for the reasons pointed out above). We are all very much looking forward to this release!

Hoped this helped, João

[TUC]

Hi jpacheco,

Thank you for your description, all what you say is interesting, but I think that it's not the exact answer to what i was really asking.

Please take a look at a related to this issue article (in §4.1) and you will see what i was meaning with my last reply.
http://www.lamc.ing.unibo.it/aimeta2011 ... -126-0.pdf

Regards.

[jpacheco]

Hi again TUC,

Thanks for your reply and interest in this subject, the curiosity of people like you help fostering discussion and spreading knowledge among researchers and practitioners. I appreciate you forwarding me this paper, which I read with pleasure. Here are my comments:

1) First off, observe that only displacement-based (DB) element formulations were used in that study. In other words, their conclusions are not applicable to force-based (FB) approaches (which are much superior to displacement-based ones)! Please keep this in mind.

Now, if you scroll to the beginning of this forum post, you can see that the first reply of Stelios Antoniou (of 30 June 2012 : 22:44:52), confirmed by that of SeismoSoft Support (of 03 July 2012 : 17:27:06), unequivocally indicated that SeismoStruct DB element uses 2 IPs (and Gauss integration).

The latter responses obviously implied that the subsequent discussion regarding SeismoStruct element integration schemes with more than 2 IPs were necessarily referring to FB elements. So would (could) your own question-and-answer posts (of 31 October 2012 : 07:15:38, and 01 November 2012 : 20:08:34) be interpreted, by any reader of this forum. In this context, one of the aims of my previous comments was to caution an inadvertent reader that your preceding remarks are NOT applicable to FB elements.

2) Even in the case of DB elements, I do not agree with your comments, or with their source (the conclusions of the study that you forwarded). This may seem strange if I tell you that all the simple numerical results presented in section 4.1 are just as I would expect. Additionally, I agree with the authors in that Gauss integration should be used for DB elements (with 2 IPs, as I wrote in my previous post). Nevertheless, I frontally disagree with the arguments advanced to advocate the use of this very same Gauss integration.

The heart of the problem is a simple one (well, actually it is not that simple if sectional softening behaviour is considered, but let us neglect that issue for the sake of the present discussion): the computation of 1D integrals to evaluate the element internal forces and stiffness. Since in general analytical integration cannot be carried out, one has to assess the value of the integrand at different IPs and assemble them to yield an estimate of the exact value of those integrals (as summarised in the paper). We are looking for a numerical method that provides the most accurate response for the minimum number of IPs along the element. The accuracy of the response should be measured both at the global level (as the authors did, at least approximately), and at the local level (e.g., in terms of moment-curvature curves, which was not addressed).

The authors do a good job in explaining the reasons for the "overestimation" of the element stiffness due to the Lobatto quadrature with few IPs, and the analogous "underestimation" of the element stiffness caused by the Gauss integration (in approximately equal amounts, as shown by the mirrored behaviour of the curves in Figure 4). However, both cases correspond to an incorrect evaluation of the integrals, which "as you again can see from Figure 4" are only acceptably estimated for at least 4/5 IPs. In short, this is a numerical error.

On the other hand, it is a known fact that DB approaches are intrinsically stiff, which is the reason for the need to subdivide the structural member into a number of DB elements.

My case is that one should not try to compensate an inadequate model (DB) with a numerical error "which is the authors" suggestion. The reasons are threefold: (i) such kind of approach rarely comes without a (sometimes hidden) cost; (ii) further, numerical errors are difficult to estimate and control, for they depend on the particular case at hand; (iii) finally, and more importantly (in my viewpoint anyway), I believe that in science this is not a virtuous or commendable solution to try to balance things out.

For what regards the (hidden) cost: look, for instance, at Figure 4. One could be led to think that, for the present case-study, the use of 8 elements with 2 Gauss IPs could be the appropriate modelling option (after all, this option seems to be apparently as accurate as using 16 elements). However, such indication proves very misleading once you plunge into the evaluation of the (important) local response, which has not been analysed in the paper. If it had been carried out, some very surprising results would then be found. I do not have the space and time to expand much further on this issue - you can investigate it yourself or search in relevant literature, but I hope that the core of my message is now clear.

3) The results with 2 Lobatto IPs were included in the comparison. However, they should have been straightway removed from the outset of the study since they are not capable of modelling a simple linear elastic response (!). Please derive the corresponding stiffness matrix to understand what I mean; Bottom line, what is the point of using an element for nonlinear analysis if it is not even capable of simulating the basic linear elastic response?

4) All the discussion above diverts attention from the most crucial conclusions (their exemplary demonstration can be found in Figure 3, and most especially in Figure 4): (i) in order to obtain an acceptable modelling of the nonlinear response with DB elements, the structural member has to be subdivided into a (relatively large) number of elements (otherwise you will get errors of the order of 15-50%); (ii) increasing the number of IPs per element does not bring any practical advantage, as the error does not appreciably diminishes; (iii) for a large number of elements, the use of 2 Gauss IPs appears as a suitable option. The above observations confirm my past recommendation.

5) If you want instead a very brief guidance on the number of IPs for FB elements, please check my previous post. Lobatto integration is close-to-mandatory for FB formulations due to the fact that equilibrium is strictly verified in the finite element (monitoring its extremities becomes fundamental).

I hope this time round my explanations more closely corresponded to the exact answer to what you were really asking.

Best,

Joao Almeida