Possible minor bug in fiber coordinates

[m12s12sa]

A few observations on fiber coordinates reported in a -xml recorder file. The alleged bug is minor in the sense that it does not influence the results, but it can confuse a user who checks his model at fiber level.
To get to the point rapidly here is an example script (I used some example from the wiki to be more concise):

# #####################################################################################################
# this script will require you to source the following:

# 1. Ex9c.build.RCSection.RectUnconfinedSymm3D.tcl
# 2. LibUnits.tcl
# 3. Ex9.analyze.MomentCurvature3D.tcl
# 4. MomentCurvature3D.tcl

# You can find these scripts at:
# http://opensees.berkeley.edu/wiki/index ... on_Example

# ----------------------------------------------------------------------------------------------------

# build 3D section
source Ex9c.build.RCSection.RectUnconfinedSymm3D.tcl

# Fiber recorders

# record the most tensioned steel fiber
set steelFib1 [expr {$nfY*$nfZ}]
set steelFib2 [expr {$nfY*$nfZ+1}]
set steelFib3 [expr {$nfY*$nfZ+2}]
set steelFib4 [expr {$nfY*$nfZ+3}]
set steelFib5 [expr {$nfY*$nfZ+4}]
set steelFib6 [expr {$nfY*$nfZ+5}]
set steelFib7 [expr {$nfY*$nfZ+6}]
set steelFib8 [expr {$nfY*$nfZ+7}]
recorder Element -xml data/conc1.xml -time -ele 2001 section fiber 0 stressStrain
recorder Element -xml data/conc2.xml -time -ele 2001 section fiber 1 stressStrain
recorder Element -xml data/conc3.xml -time -ele 2001 section fiber 2 stressStrain
recorder Element -xml data/conc4.xml -time -ele 2001 section fiber 3 stressStrain
recorder Element -xml data/conc63.xml -time -ele 2001 section fiber 63 stressStrain
recorder Element -xml data/steel${steelFib1}.xml -time -ele 2001 section fiber $steelFib1 stressStrain
recorder Element -xml data/steel${steelFib2}.xml -time -ele 2001 section fiber $steelFib2 stressStrain
recorder Element -xml data/steel${steelFib3}.xml -time -ele 2001 section fiber $steelFib3 stressStrain
recorder Element -xml data/steel${steelFib4}.xml -time -ele 2001 section fiber $steelFib4 stressStrain
recorder Element -xml data/steel${steelFib5}.xml -time -ele 2001 section fiber $steelFib5 stressStrain
recorder Element -xml data/steel${steelFib6}.xml -time -ele 2001 section fiber $steelFib6 stressStrain
recorder Element -xml data/steel${steelFib7}.xml -time -ele 2001 section fiber $steelFib7 stressStrain
recorder Element -xml data/steel${steelFib8}.xml -time -ele 2001 section fiber $steelFib8 stressStrain

source Ex9.analyze.MomentCurvature3D.tcl

wipe

# #####################################################################################################

Observation 1 (not related to the bug).
As I pointed out in a previous topic (http://opensees.berkeley.edu/community/ ... put#p85478 ), to get correct fiber recorder output in an ZeroLenghtSection element is a bit tricky, since - section specification has to be followed by nothing, and not "1", as one would reasonably assume. With "-section 1", all fiber coordinates are completely wrong. I think it would be useful to point this out in the wiki, since it is notably different from other elements; I would gladly edit the article myself, but I am not an editor on OpenSees wiki.

Possible minor bug.
Note that local and global system are coincident by default in this example since the ZeroLenght has not been oriented.
If you look at the local y-coordinates reported in the -xml file you will see they have wrong sign. For example:
- conc1 fiber has been created with negative Y (and therefore y) coordinate; we expect it to have positive stresses and strains, because of the positive moment/rotation around the z-axis (pattern Plain 3002 "Linear" { load 1002 0.0 0.0 0.0 0.0 0.0 1.0 }). Indeed stresses and strains are as we expect, but the local y coordinate is positive: <FiberOutput yLoc="28.125" zLoc="13.5" area="33.75">
- the same applies with conc2 conc3 conc4 -xml recorders.
- in conc63 (last concrete fiber, created with positive Y coordinates) we would expect a positive y coordinate and negative stresses and strains. We get the latter, but y coordinate is negative: <FiberOutput yLoc="-28.125" zLoc="-13.5" area="33.75">.
- in the steel fibers, the same happens: steel1 fiber is the first of top layer, with positive Y coordinate, and should be compressed. The recorder shows it ha negative stress and strain output, but the local y coordinate is negative: <FiberOutput yLoc="-25" zLoc="13" area="1">
- the same applies with other steel -xml recorders.

So there is no error in the analysis, but probably there is something wrong in the FiberOutput command; I found this bug also in other fiber elements (FBE, DBE).
I'm not so familiar with OpenSees source code, so it would take me days to find it out myself. Maybe Frank, or Vesna or Michael can look at this.
Finally, I hope this is not me mixing it all up! Please correct me if that's the case!

Thank you,
Francesco

[SongFei]

I have find the same problem when i used Displacement-Based Beam-Column Element and Fiber Section, and my Version was 2.4.4.

[m12s12sa]

To date, with OpenSees version 2.4.5, this issue (bug) is still persistent.
I had forgotten this post and, getting the same problem in a new script, I found the "answer" through this old question of mine, after more than 1.5 years! (Unfortunately I spent three hours drawing my patch quadr fibers on paper before coming to the message board -.-)