Displacement-based fiber elements and concrete models

[taneryilmaz]

Hi to everyone,

For my bridge modeling works; (http://opensees.berkeley.edu/community/ ... =2&t=60620) I've been dealing with some validation studies for bridge columns. So far I've tried to compare analytical and test results for two sections; one circular (the same column given in here http://opensees.berkeley.edu/wiki/image ... EvsDBE.pdf) and one rectangular.

1) I can only use displacement-based fiber elements, since force-based fiber elements fails in every time-history analyses and validation analyses I made. Do you have an idea why force-based fiber elements do not work?

2) Has anyone also experienced that Concrete07 gives stiff response? Is it due to its formulation or can it be because of using wrong values for the parameters needed. I can say that Concrete02 is more successful in terms of matching test results; but Concrete07 results in considerable faster run times in time-history analyses.

3) One interesting result I got from the "Lehman et al. 1998, 415" column validation is that increasing the number of elements did not result in better matches (I tried 5, 10 and 20 elements with 3, 5, 7 integration points). For example when Concrete02 is used, the responses of modeling with 5 or 10 elements are acceptable while using 20 elements caused distorted response. I've obtained a similar result when Concrete07 is applied as having 5 elements were observed to be much better than using 10 or 20 elements. Even I got a convergence error message (although I used the flag 5 in the test command) such as "Norm deltaR:1.#QNAN". What does that imply to?

To wrap up, I wonder if there is a limit of element size for using displacement-based fiber elements. Any comments on these concrete materials will be highly appreciated.

Thanks in advance,
Taner.

[fbeckwit]

Quick thoughts....

1) In general, the force-based beamColumn elements should work. If they don't, it's generally because of a problem with your section definition (I would check your fibers are being defined correctly). Since force-based elements use internal iterations to enforce compatibility, you might try to increase the number of iterations when defining those elements to see if that resolves the issue.

3) My general rule of thumb is that increasing the number of elements leads to a more accurate solution at the cost of poorer convergence. If you're seeing just the opposite, I would suspect that the analysis steps are leaving behind a large residual error that is getting compounded through the analysis.

Also, #QNAN stands for "Not-a-Number" (I don't know what the Q is for). It means a singularity was encountered during the analysis because it divided by zero somewhere.

[taneryilmaz]

@fbeckwit: Thanks for the precious comments.

[fmk]

for the force based elements you only want one element per column. you only need 1 element per column. it integrates the force along the member exactly. because the disp beam assumes linear curvature along the length in the integration, you need a few if this is not the case. increasing the number of elements does not lead to improved accuracy in the nonlinear analysis of columns .. as you increase the number of elements you are decreasing the size of the plastic hinge .. the results will converge to what you see in the experiment but then diverge.