The OpenSees Community

To bump a 6 year old thread, I finally got back around to addressing this.

For those of you interested in using the code Frank posted, it requires some other OpenSees framework. It is available in its entirety in SRC/handler. 'make test' will produce a binary that can be used.

When the socket is opened, 8 bytes are sent representing the number of values for each step. Then for each step, this value is repeated, followed by 8 bytes for each piece of data for the recorder. The data is sent little-endian.

Python3 implementation to receive recorder socket:

[code]
#!/usr/bin/env python

import socket
import struct
import binascii

serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.bind(('', 4117))

serversocket.listen(5)
unpacker = struct.Struct('<d')
(clientsocket, address) = serversocket.accept()
print('Connected!')

#Get data size
raw = clientsocket.recv(unpacker.size)
DataSize = unpacker.unpack(raw)[0]

print('Data Size == {0}'.format(DataSize))

#Loop over each step
SizeReceived = 0
Data = []
while 1:
raw = clientsocket.recv(unpacker.size)

#Socket done
if not raw:
break

#Do not record first value
if SizeReceived > 0:
Data.append(unpacker.unpack(raw)[0])

#All data received
if SizeReceived == DataSize:
SizeReceived = 0
print(Data)
Data = []
else:
SizeReceived += 1

clientsocket.close()

[/code]

I now have access to the machine. Two of us are going to tackle compiling this weekend. Our cluster compiling skills are a little weak. If you have any helpful pointers, we would appreciate it.

I was considering starting with Makefile.def.LINUX_Redhat_EL5, since Lonestar is CentOS 5.5. If you think a different Makefile.def is a better starting point, please let us know.

Thank you for your offer to help.

When I get access to Lonestar I will pursue this. I was a little bit hesitant of the MAKES directory, since most of the Makefiles.def haven't been updated in 1000s of days. For example, Makefile.def.LONESTAR is significantly older than the cluster (perhaps it was for a previous incarnation).

Unfortunately, as a user (and not a developer) of OpenSees, debugging compiling errors is beyond my expertise. For example, what libraries are required in the environment file.

That is why I was hoping to find precompiled binaries. I will give compiling a shot in the near future.

Thanks,
Dan

Lonestar seems to be the new Intel-Linux cluster on the block. It seems perfectly suited for OpenSees. Has anybody compiled a binary on Lonestar?

What Teragrid resources have OpenSees binaries available for them? This week NCSA Abe will be shutting down, forcing me to find a new home. I have access to LONI Queen Bee and NCSA Abe. Compiling OpenSees seems to be a complicated procedure.

Any help is appreciated.

Thanks,
Dan

I would like to second this request.

It is common to "wrap" another program like MATLAB around OpenSees (i.e., generate input, run OpenSees, analyze output). It would be useful to pass errors (such as convergence issues) and state information back upstream without having to analyze the console text.

Dan

An up to date Makefile.def would probably suffice. The one in the source code does not seem to be recent (references tcl 8.4). The one from 2.2.0 would probably work.

I have tried to compile it with Makefile.def.ABE without any luck. I changed the home directory, removed MUMPS and set it to sequential and am bombing out with tcl errors. I have done my best to debug them.

Thanks,
Dan

/u/ac/dborello/OpenSees/SRC/tcl/TclV1deoPlayer.o(.text+0xc43): In function `TclV1deoPlaye
r::TclV1deoPlayer(char const*, char const*, char const*, Tcl_Interp*, char const*, double
)':
: undefined reference to `PlainMap::PlainMap()'
gmake[1]: *** [tk] Error 1
gmake[1]: Leaving directory `/u/ac/dborello/OpenSees/SRC/modelbuilder/tcl'

Frank,

I unfortunately am running into a bug in version 2.2.0 that was fixed in version 2.2.2. However, the binaries in your home direction on Abe are still version 2.2.0.

Would it be possible to get a build of the current version on Abe?

(If it is simple and I am just being stupid, you can just tell me to go do it myself; perhaps with a nudge in the right direction).

Greatly appreciated. Thanks,
Dan

I found the region command, that seems to work well.

I can appreciate maintaining backwards compatibility. I doubt many users double check their results are still valid when upgrading.

Perhaps it can be added to a list of items to be fixed for a release not guaranteeing backwards compatibility (3.0?). I know the inconsistencies have tripped up several people.

Thanks,
Dan

Currently different elements default to Rayleigh damping on or off. For example, truss elements by default will be excluded from Rayleigh damping while elastic beam columns will be included.

It would likely reducing modeling error if all elements defaulted to the same behavior (perhaps off by default). Furthermore, it would be extremely useful to provide a doRayleigh flag for all elements.

My motivation for this comes from modeling beam depths using stiff elastic beam columns. From the documentation, it is not obvious that they are included in Rayleigh damping. However, they can not be excluded from damping calculations.

Thanks,
Dan

Frank,

Sounds perfect, thanks.

Dan

It would be nice if the recorders could be set to only record every "n steps".

If OpenSees does not have an internal step counter, providing an option to base it on time would be a good options as well.

Thanks,
Dan

I used the code below to read the xml output in MATLAB. It reads displacements, reactions and element forces from the xml recorders. It also regenerates node locations and element connectivity. The output should be obvious....

It requires xml_read (mathworks.com/matlabcentral/fileexchange/12907-xmliotools).

I used the following recorders:
recorder Node -xml $DataDir/NodeDisplacements.txt -time -nodeRange 1 $NNodes -dof 1 2 disp;
recorder Node -xml $DataDir/Reactions.txt -time -node 1 $NNodes -dof 1 2 reaction;
recorder Element -xml $DataDir/Elements.txt -time -eleRange 1 $NElements globalForce;

It turns out that it is actually really slow, so I haven't used it in over a year. Therefore you are on your own for debugging.

[code]
function [Nodes, Elements, Time] = ReadOpenSees(path)

%% Read node data
Pref.Str2Num = 'always';
xml_Struct = xml_read([path '/NodeDisplacements.txt'],Pref);

%...Is there time?
if isfield(xml_Struct.OpenSeesOutput,'TimeOutput')
Time = xml_Struct.OpenSeesOutput.Data(:,1);
offset = 1;
else
offset = 0;
end

%...Number of DOFs
ndof = length(xml_Struct.OpenSeesOutput.NodeOutput(1).ResponseType);

%...Place coordinates and displacements in Nodes structure
for i = 1:length(xml_Struct.OpenSeesOutput.NodeOutput)
Nodes(xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.nodeTag,:).cord...
= [xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.coord1 xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.coord2];
Nodes(xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.nodeTag,:).u...
= xml_Struct.OpenSeesOutput.Data(:,offset+i*ndof-(ndof-1):offset+i*ndof);
end


%% Read reactions
Pref.Str2Num = 'always';
xml_Struct = xml_read([path '/Reactions.txt'],Pref);

%...Is there time?
if isfield(xml_Struct.OpenSeesOutput,'TimeOutput')
Time = xml_Struct.OpenSeesOutput.Data(:,1);
offset = 1;
else
offset = 0;
end

%...Number of DOFs
ndof = length(xml_Struct.OpenSeesOutput.NodeOutput(1).ResponseType);

%...Place reactions in Nodes structure
for i = 1:length(xml_Struct.OpenSeesOutput.NodeOutput)
Nodes(xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.nodeTag,:).cord...
= [xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.coord1 xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.coord2];
Nodes(xml_Struct.OpenSeesOutput.NodeOutput(i).ATTRIBUTE.nodeTag,:).F...
= xml_Struct.OpenSeesOutput.Data(:,offset+i*ndof-(ndof-1):offset+i*ndof);
end

%% Read Elements
Pref.Str2Num = 'always';
xml_Struct = xml_read([path '/Elements.txt'],Pref);

%...Is there time?
if isfield(xml_Struct.OpenSeesOutput,'TimeOutput')
Time = xml_Struct.OpenSeesOutput.Data(:,1);
offset = 1;
else
offset = 0;
end

%...Number of fields
nfields = length(xml_Struct.OpenSeesOutput.ElementOutput(1).ResponseType);

%...Place element connectivity and forces in Elements structure
for i = 1:length(xml_Struct.OpenSeesOutput.ElementOutput)
Elements(xml_Struct.OpenSeesOutput.ElementOutput(i).ATTRIBUTE.eleTag,:).con...
= [xml_Struct.OpenSeesOutput.ElementOutput(i).ATTRIBUTE.node1 xml_Struct.OpenSeesOutput.ElementOutput(i).ATTRIBUTE.node2];
Elements(xml_Struct.OpenSeesOutput.ElementOutput(i).ATTRIBUTE.eleTag,:).F...
= xml_Struct.OpenSeesOutput.Data(:,offset+i*nfields-(nfields-1):offset+i*nfields);
end
end
[/code]

It would be useful if sections had the ability to report their stiffness to the element recorder. I am particularly interested in the fiber section.

The motivation for this request is to identify when a plastic hinge has developed. Obviously there are several methods, but noting when the section stiffness has dropped below a threshold seems like a good one.

I realize that this would require multiple outputs, but that is not unusual.

It appears easy to implement (just add a setResponse to return ks?). I would attempt to do this myself, but would spend more time setting up the development environment than actual coding.

Thanks,
Dan

I noticed that version 2.2.1 added support for sending recorder output over a tcp connection.

This is very interesting and could alleviate having to dump output to disk. It has a lot of potential and is exciting.

I am giving it a shot with a simple model (below). I am using this program to listen to the socket (www.rjlsoftware.com/software/utility/portlistener/). I have connected to it and verified that it reports the activity on the port.

For short analyses (just a couple of steps), the client connects and then disconnects. For large analyses (500 steps), the client connects, sends some garbage (non plain text) and then disconnects.

What is the expected behavior of this function? Any information is appreciated.

Thanks,
Dan

[code]
wipe;
model BasicBuilder -ndm 2 -ndf 3;

node 1 -120 0;
node 2 -120 144;

fix 1 1 1 1;

uniaxialMaterial ElasticPP 1 29000 0.001724;

section Fiber 1 {
patch quad 1 30 30 -5 -9 5 -9 5 9 -5 9;
}

geomTransf Corotational 1;

element nonlinearBeamColumn 1 1 2 2 1 1;


pattern Plain 1 Linear {
load 2 1.0 0.0 0.0
}

recorder Node -file Out.txt -time -node 2 -dof 1 disp;
recorder Node -file Reaction.txt -time -node 1 -dof 3 reaction;

recorder Node -tcp 127.0.0.1 4114 -time -node 2 -dof 1 disp;

constraints Plain;
numberer Plain;
system BandGeneral;
test NormUnbalance 1e-3 50 2;
algorithm Newton;
integrator DisplacementControl 2 1 0.1
analysis Static;

analyze 10;
[/code]