Travel Report
Taiwan (NCREE) April 22-29, 2006
Paul Hubbard
Purpose of Trip
While I was at the NEES World Forum meeting (San Francisco, March 2006)
Keh-Chyuan (K.C.) Tsai of NCREE
invited me to
visit their facility, primarily to discuss their hybrid simulation
software. We first discovered
their software in February while researching the state of the art
in hybrid simulation. Because they've solved many of the problems NEES
is facing, I had emailed them in February to ask if they'd share code.
At the time, they were not ready to share code due to its being tightly
coupled to their local setup.
I was therefore quite happy
to accept the invitation to visit their facility and exchange ideas.
K.C. kindly offered to provide partial support for my visit and
suggested dates when the primary author of NSEP (Kung-Juin Wang) would
be available for extended discussions and tutorials. Kung-Juin had not
attended the March or April meetings, making this my first chance to
meet him.
After attending Yuen-Sen Yang's talk at 8NCEE, it was clear that their
software (ISEE,
either database approach or PNSE)
was currently not designed to hit the 75Hz rates required
in NEES. There are still interesting ideas in the protocol (NSEP) and
after discussion with Jon Lea, Lelli van den Einde, and Cliff Roblee, I
decided that it was still worthwhile to go and visit. The goals changed
a bit, from 'can we adopt PNSE in NEES' to 'Learn about PNSE/NSEP, and
show NCREE the capabilities of NEES.'
Direct feedback and general comments
K.C. started out with a general presentation about their lab, software
and hardware. Their streaming data is 50Hz, and their integration
timestamps are usually 0.02 to 0.005sec (5-200Hz) (in analytical time,
not wall-clock time). NCREE and its network experimental software focus
on slow speed hybrid tests.
Their research has already produced results in codes and construction -
they showed pictures of their improved brace design in place at Chi-Mei
chip fab #5.
K.C. mentioned that they had a summer student, Bryan Lin, and that he'd
be available for working on the NEES-NCREE collaboration if we can
think of an appropriate project. I've started a discussion with Shannon
on this.
Yuan-Sen (Vincent) Yang presented about ISEE, their video subsystem and
the 'database approach'. (PNSE uses TCP/IP for communications between
the server and the clients. The PNSE server can
optionally upload all non-critical data to an MS SQL database.)
Their video system is
similar to flexTPS - it uses the Microsoft WMV video encoder, streams
are defined by IT personnel, and access is via a web page with the URLs
on it.
NSEP in the database configuration runs about 3 seconds per step
depending on the configuration and network. One of the limitations of
this design is that the various clients have to poll the database for
new data, which limits the rate and introduces load on the DB server.
On the positive side, using the DB as a data store and state table has
benefits as well - all data is always available, the DB provides
consistency and durability, and the interface is well defined. (SQL).
Over the course of three days, I demonstrated pretty much every
software product in NEES: RDV, Central, flexTPS, PNNL ELN, NEES ELN,
high-res imaging via DAV/HTTP, the HTTP/PNGplugin demo, the DAQ code,
NTCP client/server/benchmarks, SingleShot, JNLP/RDV, the NEES
telepresence system (NJZTPM), NEESforge and the new HTTP data turbine
demo. It was particularly useful to have along an accelerometer,
network camera and digital camera, as this enabled a hands-on demo with
Yuan-Sen running RDV from his laptop via JNLP, while I ran data turbine
from my laptop. It seems like demos are much more compelling when you
show them JNLP and how easy it is to run the code themself on their own
hardware. Here's a screenshot of RDV in action:
The hacked-up code that I wrote for high-res imaging at 8NCEE was of
interest - they have a similar capability in their current system. As
with UMN, higher resolution is useful for seeing small cracks and fine
details on the test specimens. We discussed the demo (which uses
Automator and the data turbine DAV interface) and a bit about jcamera.
They're a Windows shop, so the demo won't work there (Automator is OSX
only), so we discussed other ways of achieving the same effect (Nikon
Capture 4, PSremote).
The demo of SingleShot was interesting - they have a tool with similar
capabilities and purpose, though their data model differs. They're
working with the SAMCO consortium on a data model, and also with an
engineering company VCE from Austria. (I'm not sure if http://www.samco.org/ is this same
group or not.)
Here's my sketch of their data model, as presented by Wen-Hsiang Tu:
This is from hand-drawn notes, so I may have made mistakes.
Their previous model looked like this:
The same caveats apply here; this is from my lab notebook.
We talked about the NEES data model, how it continues to evolve in
Central, and that more of Kincho's work would be incorporated as
development proceeded. Ironically, Kincho Law himself arrived late in
the week for a visit on an unrelated project, and he and I had a brief
discussion of data models.
The NCREE streaming data solution uses the database (as noted above),
with a locally-written program to fetch data and plot it. Plots (e.g.
'X displacement versus time') are defined ahead of time by the PI,
researcher or grad student. The configuration is an XML file on the
server. They were interested to know whether or not RDV had similar
functionality. (I talked about save/restore setup and the JNLP command
line, which is a rough equivalent.) They can also do overlaid XY plots
that RDV presently can't do, for example predicted stress-strain and
measured.
They liked the HTTP interface, where data could be shown without a
local client or download. Since they run 3 seconds/step, an HTTP
auto-refresh would suffice to keep the data current. They are also
interested in real in-web-page data turbine clients, so I talked about
the ORST code and the better UMN thin client.
K.C. had arranged a visit to National
Center for High-performance Computing (NCHC)
in Hsinchu science park. There, we met and talked with Hsiu-Mei Chou.
She had googled me, figured out that I worked with turbine, read up on
it and had questions about how she could use it there. I gave her an
impromptu demo of DT and RDV, and we discussed her using DT for stereo
video feeds.
Kung-Juin Wang is the primary architect on PNSE. He's a PhD student,
two years in, working on hybrid sim. He gave an in-depth presentation
on the PNSE protocol NSEP. One consequence of their design is that
there's no explicit error code returned; errors show up as new events
that propagate afterwards. This leads to a very complicated state
machine and some difficult-to-fix bugs. He and I discussed whether
adding error codes to NSEP was the right thing to do, how NTCP did it,
and the tradeoffs in both designs. (Implicit error returns are faster,
since there's one fewer message reply.) NSEP uses a binary protocol,
using 4-byte floats for all data. We talked about the need for double
precision (8 bytes per) and other data types. His protocol allows a
vector of floats as a parameter, so I told him that our researchers had
asked for the ability to send any
data as a parameter - floats, ints, doubles, strings, vectors,
matrices, even composite C-type structures. NSEP is pretty fast - 0.8
milliseconds/step in a LAN test. However, their code is mostly
hardwired and not ready to share; refactoring is high on Kung-Juin's
task list.
NSEP sends all experiment/test metadata to a client right after login,
which is a clever idea. They also separate critical data from
non-critical data, which is something we can borrow for our hybrid
solution. For example, non-critical data could be streamed to the
turbine as time permits, and dropped if the server gets too busy. It's
a cute idea.
NSEP also has two kinds of quit - a full stop and a pause. Basically,
one is a 'please wait while I fix this error' and the other is 'Give
up, all is lost' - another useful concept.
They have a separate protocol (NMTP) between PNSE and the DAQ for data
and triggering; it sounds similar to the NEES
DAQ protocol except that we use NTCP for triggering.
NCREE wants some sort of e-notebook, so I demo'd the NEES (Nestor)
notebook using Nestor's site.
For the PNNL E-notebook, I had to use video from the PNNL site
which worked out better since it showed all features of their software.
One idea I had was that, if you use the NEES notebook, you could use a
PDA with WiFi to take notes while on the lab floor. This is quite a bit
cheaper than a full tablet PC. While demoing the notebook, we also came
up with the idea that you could have an ELN function to snapshot plots
into the notebook by using the Creare PNG plugin and HTTP interface;
very easy.
Since NCREE is interested, I have subsequently been in contact with
Nestor and Jim Myers about their software, it's status and future
plans. I also asked Nestor how hard it'd be to separate the ELN from
his video code, since they only need the ELN functionality.
We spent quite a bit of time discussing how to add turbine support to
their systems. Their DAQ used for hybrid tests is static, which is a
problem, but K.C. would
very much like the live streams that RDV presents. (They also have a
200Hz DAQ on their shake table, which has not been used for networked
hybrid tests. We didn't have a chance to talk about that.) We
brainstormed
several approaches, and they are going to start working on this. K.C.
also asked me to find out what's required for an MOU between NEES and
NCREE - does he need to talk to the NEES president or NEESinc? I've
started inquiries on this.
One possible contribution I suggested they could investigate is their
3D visualization program, GISA3D. I suggested that this could become an
RDV plugin, which would be of great benefit to other NEES users as
well. I know that UMN has something similar that they wrote, and Davis
as well, so an RDV add-on would be welcome.
Similarly, KJ was talking about writing a plot program to show live
data from the MTS controllers; I explained that he could run a local
turbine on the same machine and then use RDV. He's going to look into
the idea.
I demo'd neesforge, which we discussed as a mechanism of collaboration
between NCREE and NEES. It seems a good fit, though we may need an RDV
project page or perhaps just a plugin project.
Pictures from the
trip are posted as well.