Hello,
I have done some software experiments in support of some upcoming test we are doing at Illinois and had some recommendations for your node recorders. All of these recommendations are designed to make the results available to other software while OpenSees is running.
Text file format recording: Running OpenSees with the "-file" argument is not useful for monitoring the simulation because the recorder output seems to be buffered and not written to the file until the simulation is over. I can understand that this was probably done for performance reasons. However, it would be useful if the Tcl "flush" command could be extended to include the node recorders (i.e. flush <recorder channel number>). In this way the simulation script could dictate when intermediate results are available.
Binary file format recording: Running OpenSees with the -binary argument provided more immediate results. The problem here is that the output file could not be deleted after it was read by the external monitoring application. It seems that OpenSees opens the output file at the beginning of the simulation and then re-uses this handle for subsequent recorder outputs. With this arrangement, the monitoring application is forced to maintain a pointer to the last read byte of the file. A colleague of mine got around this problem by pointing the recorder to a named pipe rather than a file. Unfortunately this solution is not available to Windows users.
node recorder changes to enable simulation monitoring
Moderators: silvia, selimgunay, Moderators
Re: node recorder changes to enable simulation monitoring
TCP format recording: Running OpenSees with the -tcp recorder option provided the best solution for us. The documentation provided here: http://opensees.berkeley.edu/community/ ... hp?t=20688 allowed us to figure out a solution. We noted an additional double value at the start of the simulation that was sent before the first number-of-values number. The performance of this recorder option is fast enough for our purposes. However, there are a few things that would make this format more usable.
1. Have each recorder in a OpenSees script use the same port. Currently every recorder in a script needs a separate port. TCP allows these ports to be re-used for any number of links. The recorders could share a port if every message were prepended with the recorder channel number in addition to the number of values.
2. Little\Big Endian issues. Using double values to send data across the internet becomes an issue when the data is received on a different endian machine. See here: http://www.rapidtables.com/prog/endianess.htm for an explanation of endians. Intel systems are little endian. Internet specifications for network byte order specifies big endian. Internet languages such as Java expect doubles to be in big endian even on intel systems. It would be better to express header info such as the number of values in the TCP message as an unsigned int rather than a double to avoid endian issues with the header. The rapidtables.com link shows how to do the endian conversions. Here is a java snippet for swapping from little to big endian for those who want to use this method.
/**
* Convert endian of a double to network order.
* @param number
* bytes of the number to be converted.
* @return The resulting double.
*/
private double little2BigEndian(final byte[] number) {
final int numberOfBytesInDouble = 8;
ByteBuffer bnum = ByteBuffer.allocate(numberOfBytesInDouble);
bnum.order(ByteOrder.LITTLE_ENDIAN);
bnum.put(number);
bnum.flip();
return bnum.getDouble();
}
1. Have each recorder in a OpenSees script use the same port. Currently every recorder in a script needs a separate port. TCP allows these ports to be re-used for any number of links. The recorders could share a port if every message were prepended with the recorder channel number in addition to the number of values.
2. Little\Big Endian issues. Using double values to send data across the internet becomes an issue when the data is received on a different endian machine. See here: http://www.rapidtables.com/prog/endianess.htm for an explanation of endians. Intel systems are little endian. Internet specifications for network byte order specifies big endian. Internet languages such as Java expect doubles to be in big endian even on intel systems. It would be better to express header info such as the number of values in the TCP message as an unsigned int rather than a double to avoid endian issues with the header. The rapidtables.com link shows how to do the endian conversions. Here is a java snippet for swapping from little to big endian for those who want to use this method.
/**
* Convert endian of a double to network order.
* @param number
* bytes of the number to be converted.
* @return The resulting double.
*/
private double little2BigEndian(final byte[] number) {
final int numberOfBytesInDouble = 8;
ByteBuffer bnum = ByteBuffer.allocate(numberOfBytesInDouble);
bnum.order(ByteOrder.LITTLE_ENDIAN);
bnum.put(number);
bnum.flip();
return bnum.getDouble();
}