The OpenSees Community

I am running some large models with large node numbers. The problem I am running into is with the "print" command. If I run the command "print model.txt" the model.txt file contains:

Node: 2.0101e+006
Coordinates : 10.8 156
...
Node: 2.0101e+006
Coordinates : 180 156
...
so there is no distinction between the two nodes (2010100 and 2010101).

Could you ensure that the node number is formatted as an integer and not in scientific notation?

I believe it's a simple change in line 1741 in Node.cpp. I'm running these models on windows so making the change myself and recompiling OpenSees is not an easy road to take. I have a workaround for my purposes, but I think this would be an easy and useful change to make for the next build.

EDIT: The same thing happens with the element tags.

Upon further investigation, it seems that if you want the "sharpness" in the initial stiffness, you also need the sharpness in the higher displacement cycles.

http://imgur.com/a/402Ac

The above image has the same parameters listed in the paper with the exception of the alpha+ (alpha_T) value which was changed from 0.6 to 10.0. The initial stiffness is well represented, but the higher displacement tension cycles are not as realistic. Maybe the behavior I am looking for is not possible with this material, but if anyone knows otherwise please let me know.

The initial stiffness of the SteelBRB material seems to be incorrect. See image here:

http://imgur.com/a/7FDdQ

The black is from the curve published in "Elastoplastic model for steel buckling restrained braces" (Alessandro Zona, Andrea Dall'Asta, 2012) and the red is the OpenSees output with the parameters from the paper. It matches well everywhere except the initial cycle where the tangent stiffness is not equal to E. I was curious if anyone else has experienced a similar behavior when using this material.

For Windows a decent program for tcl editing is Notepad++ (https://notepad-plus-plus.org/). It's almost certainly not as sophisticated as the application you used for C++, but it does have syntax highlighting that will help you interpret your code better or see where you made mistakes.

vesna wrote:
> If specified, mass density will be used to calculate translational lumped
> masses at the element ends. However, this option is not working properly at
> the moment. I would suggest you not to use it until the problem is
> resolved. Specify masses directly using mass command.

Was this issue with the mass density ever resolved? Currently, it seems that the mass from the element density is taken into account for an eigen analysis, but not for a transient analysis.

Is there a reason that the 2-norm is default over another type of norm?

Unfortunately, my model is fairly complex and does have EqualDOF constraints...

Based on the wiki page for NormUnbalance, the convergance test is comparing the norm of the "right hand side of the matrix equation" which "Usually, though not always, it is equal to the unbalanced forces in the system" to the specified tolerance, $tol. Based on this information, it seems to me that the norm would be the maximum force unbalance across all of the DOF's, so $tol would be the upper limit on the force unbalance at all nodes?

Please let me know if this is the correct logic.

PS - for the "though not always" case, it seems that this is affected by the the integrator and constraint handler. For reference, I am using:
integrator Newmark 0.5 0.25
constraints Plain

EDIT: Basically, I am not concerned about the actual unbalance at each node as long as the unbalance is limited to some quantifiable amount (related to $tol).

Thanks for the reply.

Is there a way to check the unbalance at a node (while employing modal damping)? Or is it just assumed that using an unbalance test (i.e. NormUnbalance) will result in no unwanted force unbalance? I did come across the 'unbalance' option for the node recorder, but I can't find any documentation on it. From the models I have run with base excitation, it seems to output:

('unbalance' recorder output) = (Applied Load) - (nodal mass) * (ground acceleration)

which I don't think helps me very much in determining the force "unbalance" that I am looking for here. Do you have any methods to find the force unbalance you mentioned could be quite large when using NormDispIncr?

[EDIT: removed comments about the 'unbalance' recorder that I realized were wrong]

Upon further investigation, it appears that the discrepancy is equal to the base acceleration times the mass at the node. I will give a brief explanation of what I think is going on, and if someone could confirm this or tell me where I am mistaken that would be great.

Considering the equation of motion from Dynamics of Structures 3rd Edition (Chopra) eqn 1.7.4:

m*a + c*v + k*x = -m*(a_g)

Where:
m = nodal mass
a = relative acceleration (between the node and the ground)
c*v = Fd = damping force
k*x = Fs = static force
(a_g) = ground acceleration

Substituting and rearranging I get

Fs + m*(a_g) = - m*a - Fd

And based on the model output I see that this is equal to the reaction force, R, meaning

[eqn 1]: Fs + m*(a_g) = - m*a - Fd = R

Ultimately I am looking to obtain the forces due to modal damping (unfortunately there seems to be no "modalForces" argument similar to "rayleighForces" arguement for the Node recorder). It seems as though I could just rearrange [eqn 1] and get the modal damping forces at each analysis step as

(Fd_i) = -(R_i) - m*(a_i)

where
Fd_i = the damping force at analysis step i
R_i = the node reaction at analysis step i (output from "recorder Node ... reaction")
a_i = the node relative acceleration at step i (output from "recorder Node ... accel")

Again, any insight would be appreciated.

I was using the 2D cantilever example (Ex1a.Canti2D.EQ.modif.tcl with A10000.tcl ground-motion file) to investigate the node reaction recorder and I can't figure out what the recorder is outputting for the top node.

Looking through the forum, my understanding is that the node reaction is the sum of the end forces of all elements framing into the node. However, when I use the example 2D cantilever and do nothing but add the following recorder to get the top node reaction

recorder Node -file Data/RTop.out -time -node 2 -dof 1 2 3 reaction

I seem to get an unexpected result. I expect the reaction in the X direction would be equal to the beam end force from the recorder "recorder Element -file Data/FCol.out -time -ele 1 force" (already included in the example), but it is not.

What is causing the discrepancy between the element end force and node reaction at the top of the cantilever? (there is no discrepancy at the bottom node reaction)

Any insight would be appreciated.

I'm not sure if this is the right board to post this question to, but anyway... I'm having trouble understanding what exactly the integration weights represent in Force-Based Beam-Column Elements. If I use

"Lobatto $secTag $numIntgrPts"

with numIntgrPts = 3, the following locations and weights are assigned to each section (from the source code)

Location:
xi[0] = -1.0;
xi[1] = 0.0;
xi[2] = 1.0;

Weight:
wt[0] = 0.333333333333333;
wt[1] = 1.333333333333333;
wt[2] = 0.333333333333333;

My understanding from a mathematical point of view is that some function will be evaluated at each location and then the evaluation will be weighted by the corresponding wt value. The weighted values are then added to evaluate the integral.

From an engineering point of view, I have a couple questions:
1) What are the integrals being evaluated over the element?
2) Is the weight indicative of the length of the member that the section is "representing"? For example, consider a member that is 6m long with numIntgrPts=3. Would the end sections "represent" the end 1m on each side (1m = 0.333 * 6m / 2) and the center section the remaining 4m (4m = 1.333 * 6m / 2) of the element?

Any insight would be appreciated.

It seems to be a compiling issue with Arch Linux. I compiled it on a CentOS machine (using the exact same files) and it works fine. I don't know how to explain it, but now that I have a working version I am no longer going to spend time troubleshooting the Arch Linux issue. Thank you for your time and suggestions.

Thanks for the reply, fmk. Unfortunately, I have tried that and it is still not working. Could somebody with a working version of the ElasticPPcpp.so please enter the following command to see if the library contains undefined symbols like mine?

$ nm -D ElasticPPcpp.so

The link to my results (as posted above) is here: http://pastebin.com/xBEmz7a1
The U indicates that the symbol is undefined (which a lot of the symbols are for me) but I am not sure if it supposed to be like this or not.

Thanks in advance.

Yes, right now I'm working with rev 6248. OpenSees builds successfully and runs models which make use of only standard features, but will not load the shared library (compiled for the same revision). I've experienced the same problem with any previous revisions that I've built as well.

Arch Linux, x86_64 with 32 and 64 bit gcc and libraries

The specific error that seems to be preventing the library from loading is:

dlerror() = /tmp/ElasticPPcpp.so: undefined symbol: _ZN16UniaxialMaterial11setResponseEPPKciR10OPS_Stream

Doing $ nm -D ElasticPPcpp.so shows that there are a lot of undefined objects in the .so file, so maybe something is wrong with making the .so file. I've tried with different rev. numbers (and recompiling OpenSees for that rev.) and that doesn't seem to work either.

Here is a link to the result of $ nm -D ElasticPPcpp.so
http://pastebin.com/xBEmz7a1