The OpenSees Community

Is there a way to run OpenSees so that the header doesn't print to the stdout? I'm running a huge study and I think the writing to screen is bogging it down...a little, and every second counts.

Is there a way to do something like OpenSees -silent file.tcl ??

I just ran a fairly large model and it is using 3.9GB of memory, so I'm guessing it is 64-bit, whether it says it is or not...? Also, if anyone is interested, I built it using the new Windows 10 Ubuntu and it ran like a charm.

I built opensees using the instructions in the makefile.def, but the text when I run it says OpenSees blah blah (rev 6248) 32-Bit. I ran OpenSees and asked tcl what it's pointer size was and it was 8, so at least tcl is 64 bit. Did I miss something else?

Of course. I can compile OpenSees in general. What I'm asking is, which dependencies are needed in 64 bit. For instance, I know I need the 64 bit version of TCL8.5. Do I need a special BLAS or LAPACK or anything else?

I'm brand new to Linux. I'd like to install a 64 bit version of OpenSees, but I can't find a very clear instruction guide on how to do that with the latest version.

I know I need some dependencies, and some of those have to be 64-bit version. I know that I also need to modify the makefile.def. I'm not very confident I know how to do either one of those things correctly. Could someone give me guidance? I found the link for installing OpenSeesMP on Linux. Is it the same, except not the MP version?

Thanks

I've been using OpenSeesSP lately to speed up some large models. I'd like to do a big parametric study with models on the order of 170,000 dof. Has anyone had any success in running opensees on the GPU? I'd like to send asynchronous models to the GPU to run independently to save time.

I have been looking at the zerolengthinterface2D element to use for contact between beams. There are two example scripts on the wiki for these. However, when I try to make the seperate structures come apart, as opposed to coming into contact, there are major issues. Is this element not capable of seperation after contact is made? If not, is there another method I can use for surface-to-surface or node-to-surface contact in OpenSees?

The basic problem I have is similar to having two cantilever beams, one just above the other and I want them to contact if I push the top one down, but not if I push it up.

Thanks for your help.

Thank you, sir!

This isn't going to work. Kg alone does not cause interaction between the elongation DOF and the twisting DOFs. Right now, the only thing I can think of is to set up one of these:

Fo = K*delta_o

and use it as an effective force to get the structure to deform. I have problems with that though, one, what if I wanted, say, a horizontally curved beam with a fairly large curvature. These would be huge forces that would have to be equilibrated during analysis. It would be horrible if the material model was inelastic...my initial curvature would yield the beams and then the structure would never be in equilibrium. This would be a problem for post-buckling response as well.

I'd love some ideas....

The current corotational transformation for 3D beam elements does not properly account for the non-additive nature of angular velocity and acceleration vectors. However, I am not certain that it makes a difference if there are no rotational masses. In other words, I am certain that angular vel and accel are not properly calculated. If the angular velocities are used to, say, determine a rate-dependent material stiffness, then I can't see how this would be accurate.

Overall, I would urge caution in using corotational with dynamic analysis. PDelta is probably a better bet.

Also, if you know a professor or researcher who would be a good resource on this matter, their name would be appreciated.

We have been looking at how the -disp tag works with nodes for assigning initial nodal displacements. For the elements that are based in a basic (natural) frame, not all of the initial displacements are taken into consideration. PDelta and Corotational correctly take nodal translations into account when they form the initial rotation matrices, and in the case of corotational, the initial length. However, nodal rotations and any other DOFs (such as warping or local plate buckling) are not handled properly because the coordinate transformations only deal with rigid body effects. There is the possibility that the coordinate triads at node i and node j may have an effect, but I am having a hard time seeing it.

First, let's consider one of the force-based elements formulated in the natural frame (lacking rigid body modes). I believe I am correct in that it does not have any components that consider the Wagner effect. And, if the Wagner effect is not considered, a force-based element will not ever experience torsional buckling. There are some alternative elements called "mixed" elements in the literature, but I don't see any of those in OpenSees. Therefore, since the force-based elements do not have forces that interact with their displacement fields, I do not think initial rotations will ever affect them.

Next, let's consider a disp-based element. Suppose this element has both a linear portion of the stiffness and a geometric stiffness. K = Ke + Kg. There are formulations that include wagner effects in the Ke portion. However, since the system being solved is (K^-1)*Del_P = Del_u , in general, only the forces are affecting the first solution iteration (and the translational geometric effects from the rigid body considerations of the crdtransf). So, unless Kg includes initial displacement effects, I don't see how initial rotations or twist could affect the solution. Therefore, I am thinking of a solution, but I need some input from people smarter than me.

Kg is a function of the total internal forces. Initial displacements are stress-free, so they are not included when calculating the internal forces for Kg. This is why twist won't cause buckling. Here is my strategy. What if a set of effective initial forces are determined by the following. At initialization, take the total nodal displacements, including initial, and send those to the section and ask for the corresponding forces, given the initial section stiffness. These could be used to formulate a Kg2 which is an initial geometric stiffness matrix that takes into account the effects from the initial displacements. This matrix would stay constant throughout all analyses and the total tangent stiffness would become K = Ke + Kg + Kg2, where only Ke and Kg are updated using incremental displacements and the total real forces. That means for the initial iteration, Ke is still the initial linear stiffness and Kg is (assuming no initial stresses are present). This seems like it would work, except for one problem.

For elements with material nonlinearity, does my solution hold? It feels like superposition a little bit. And, superposition doesn't hold for nonlinear systems. Does anyone have any thoughts on this? We have a real need to be able to model initial twist to show that our element can experience torsional buckling that agrees with the theoretical solution. As of now, we cannot do this because we need to be able to impose an initial twist without applying an initial twisting force.

I was considering how to build an eigen-solver for buckling problems. One big problem is that the elements do not necessarily have separate linear and nonlinear (geometric) stiffness matrices. Therefore, an approach must be developed to extract the geometric stiffness from the global tangent stiffness.

ELASTIC
For instance, let's say we have a linear elastic structure with a geometrically nonlinear transformation used (PDelta or Corotational). The stiffness matrix is: K = Ke + Kg, where K is the global tangent stiffness matrix, Ke is the global linear stiffness matrix, and Kg is the global geometric stiffness matrix. Kg is often (always?) a linear function of the internal load effects (N, Mz, My, T,...). Therefore Kg will be 0 initially. Let's say we have 2 fully assembled global stiffness matrices, one at load=0 (initial stiffness), K0, and one at a reference load condition, K2. K0 = Ke and K2 = Ke + a*Kg, where a is some scaling factor for the Kg resulting from the applied load vector. Subtracting the 2nd equation from the first, we get:

Delta_K = a*Kg

This allows the extraction of the geometric stiffness matrix, Kg = Delta_K / a; where Delta_K = K2 - K0.

Once we have Ke = K0, available at Load = 0, and Kg from equation above, we can set up an eigen problem and perhaps, to a large degree, utilize the existing eigen solver class?

[ Ke ] Phi = lamda [ -Kg ] Phi

INELASTIC
If we expand this to a structure with material nonlinearity, the eigen problem now becomes:
[Ka + lamda*Kg] Phi = 0; where Ka and Kg are both nonlinear functions of the loading. Therefore, once a load vector, P, is set, it can be scaled uniformly to produce a set of incremental eigen buckling problems. The trick is to figure out how much they should be incremented. In looking at this, it appears as though all the nuances of a nonlinear load-displacement analysis would have to be considered and controlled to perform this analysis correctly. Therefore, I think it is not worth including an inelastic critical buckling load solver in opensees, as the same answer can be reached using load-displacement. Although, I suppose the same could be said about the linear case as well. I do think the linear case is valuable, especially for approaches such as the Direct Analysis Method from AISC, and seems simple enough to add.

I am interested in thoughts on value, approach, and feasibility.

No apologies necessary. I'm glad to help contribute any way I can. The node.cpp revertToStart() may not be a problem, depending on what classes use initial displacements. The 3d coordinate transformations all grab initial displacements and store them as variables. The transformation revertToStart() methods do not clear those initialdisplacement variables, so I think they are retained. However, it probably would be cleaner to make sure the node retains them as well.

initialize - sets up system of equations but doesn't solve
remove timeSeries $tag
nodeReaction $nodeTag <$dof> - returns a tcl list of node reactions at the "time" when this command is called
nodeResponse - like the eleResponse command, but for nodes
eleForce $eleTag <$dof> - returns a tcl list of element forces at the "time" when this command is called, looks to be specialized type of eleResponse command
eleNodes $eleTag - returns a tcl list of the nodes attached to a given element
nodeMass $nodeTag $DOF - returns the mass for the given node and DOF. To my knowledge, this is currently the most direct way to build the mass matrix.
quit - same as exit
version - returns string of version of opensees

There are a few more, but these are some I found interesting.