Distributed simulation architecture and Modelica API

1
Distributed simulation architecture and Modelica
API

• by Vadim Engelson, PELAB
• See under http//www.ida.liu.se/pelab/modelica,
• User mod, password mod

2
Modelica API a history of efforts

• Some API exists in Dymola implementation, and
  it covers some of major user needs.
• API discussed without particular proposal until
  September 1999
• Thilo,Tommy,Clemens and Michael made first
  proposal
• Sept 2000 Michael made an IDL (standard for
  C-like class declarations, used also for CORBA)
  definition
• Feb 2001 a need DLR wants to run distributed
  simulations -gt discussion activated
• Vadim made RSH/RSHD proposal, got critique
• Vadim made IDL proposal

3
Why it goes so slowly ?

• We had no clear spectrum of applications for API
• Dymola has implementations for some application
  cases already
• Not clear whether it is language issue or tool
  issue. How to make it abstract from the tool if
  just one tool for running simulations (dymosim)
  is available?
• API is written on C/C level, but users often
  want it on Matlab or Mathematica level
• However, not too hard to implement any API and
  any adjustments to it. But lets make a design
  before implementing ?

4
How we proceed now

• Short overview of Michaels proposal
• 7 applications, more ?
• 6 sub-APIs. Different APIs mention similar
  objects/artifacts, but actually apply to
  different things.
• For some sub-APIs there are existing access
  solutions and proposals for future
• Go in distributed simulation sub-API with more
  details.

5
Michaels proposal (1 of 3)

• Modeling Tool
• Open/parse a model, Exposing model structure
• Number of equations and unknowns
• Configuration before start
• change parameters between analyses
• Solver configuration
• Numerical tolerances, solver flags
• Integration parameters

6
Michaels proposal (2 of 3)

• Simulation control, including
• Simple control start, stop, pause, resume, etc
• Provide facilities which allow for co-simulation
  ?
• Ability to process results as they become
  available
• Save and restore model state (state variables,
  not simulation state)
• Provide interpolation over (last?) solution
  interval Undo last step? (can be very hard)

7
Michaels proposal (3 of 3)

• Reflective capabilities (access to class
  structure, equation structure?, Jacobians?)
• Proposal if written in IDL, and can be used in
  many ways
• Linking to a library
• SOAP
• CORBA
• Automatically generated HTML documentation

8
Applications and related sub-APIs

• Simulation in the loop (optimization, hardware
  communication before/after simulation, varying
  parameters)
• need indata and outdata API

9
Pre-processing (indata)

• Currently accessed via Dymola GUI, MathModelica
  GUI, mos-scripts, Mathematica, Matlab and DDE.
•  Status There is an IDL from M.Tiller.
• Future Can be even implemented as a linked
  library or in CORBA based on this IDL. Can be
  implemented in SOAP, since it is not
  time-critical.
•  Work   Should be done by Dynasim, it is their
  format.  

10
Post-processing (post-mortem trace)

• API for data post-processing apply to a binary
  file (such as dsres.mat).
• Currently accessed via MatLab,  MathModelica and
  C-based API to library.
• Status There is (almost) an IDL from M.Tiller.
• Future Can be even implemented in CORBA based on
  this IDL.
• Work   Can be done by anybody, e.g. Vadim or
  Dynasim.

11
Code generating sub-API

• for building customized Modelica models via GUI
  may be for checking code correctness.Also for
  debugging and incremental compilation. Reflecion
  of parameters is useful for Matlab users.
•  Currently Modelica source code is just written
  out, or created by CAD plug-ins, or created 
  using Dymola/MathModelica GUI.
• Status There is somewhat like reflection API
  in   IDL from M.Tiller.
• Future Investigate whether it is
  feasible. Work   Dynasim or MathCore who have
  tool to check Modelica code correctness.

12
Two related API-s to running simulations

• Output during simulations
• Visualization/monitoring during simulations
• Stepping through simulation
• Input during simulations
• Hardware in the loop
• Human input in the loop
• Co-simulation
• Tiller The management of simulation data is not
  a trivial issue.  In fact, I would say it is the
  single biggest issue discussed among people I
  know inindustry.

13
I/O during simulation API

• push, get any variables from/to running
  simulation
• hard to define semantics for push ?
• stepping until what ? (next iteration of the
  solver?)
• Currently accessed via DDE and/or external
  functions.
• Status  There is an IDL proposal from M.Tiller.
  But we need more requirements from applications.
• Future Can be even implemented in CORBA based on
  this IDL.
• Work   Should be done by   Dynasim, it is their
  source code.

14
Compiling API

• For starting Modelica translator and similar
  tasks. (may be models can be simulated without
  special translation step, however)
• Applies to Modelica development environment.
• Currently accessed via MOS-scripts and DDE.
• Status There is an IDL proposal from M.Tiller.
• Work   Should be done by   Dynasim, it is their
  source code.

15
Distributed simulation API (1)

• Just one application up to now optimization in a
  cluster of computers. Starting remote runs and
  Organizing a task queue.
• Cluster of NTs, client is in MatLab
• Should we make an API for that ? Yes !
• It is Modelica-independent.
• Currently cannot be automated in Dymola.

16
Distributed simulation API (2)

• Status  There is one non-IDL and one IDL
  proposal from Vadim.
• Future Can be implemented in RSH/RSHD, sockets,
  CORBA
• Work   can be done by Vadim if approved by
  RealSim

17
Using RSH/RSHD

• Simple command interface
• Send over data and exe files between any
  computers (Win32, Unix) Start exe files or batch
  files
• Call rsh directly from C, C, MatLab, Mma
• Very easy to install
• -- Can be hard to automate analysis response from
  commands (e.g. German DOS messages) not robust
  no enough security
• -- We cannot use calls of other API (e.g.
  monitoring)
• -- Delays (3-10 sec per command)
• -- RSHD is not from MicroSoft.
• -- Tiller I can almost promise you it will not
  be very robust and scalable

18
RSH/RSHD commands

• rcp file computer/file
• rcp computer/file file
• When files are there
• rsh computer exefile parameters
• rsh computer batchfile parameters
• All answers to requests are returned as files.
• RSH doesnt care if somebody is logged in on the
  computer.
• SSH/SSHD slightly safer

19
Queue controller sub-API

• Add tasks to the queue and it distributes to a
  cluster of currently not-occupied computers
  (other people are not working with
  processor-intensive applications or are logged
  out)
• A Matlab/Mma session can monitor queue status and
  get result files as soon as these are ready
  (Michael concerned here danger with shared
  files)
• Is queue needed at all ?
• CONDOR non interactive and no API to it.

20
Other solutions to interprocess communication

• (!) All other solutions do not care about
  starting a process. They setup communication
  according to a protocol, between processes
  running on same or different computers
• Sockets
• CORBA
• SOAP

21
TCP/IP Sockets

• establish channel using IP-numer and port number
• write(channel,string,length)
• read(channel,string,length)
• Portable, fast
• -- Up to you how to choose ports and handshaking
  procedure, who starts first.
• -- Strings only. Up to you to encode. There are
  libraries for that however.
• -- Can be difficult to diagnoze failures

22
CORBA

• Server
• class A
• int z
• int foo(int x,y) return xyz
• Client
• Aaget_from_server()
• print(a-gtfoo(5,7)) .

23
IDL used for CORBA

• interface A
• int foo(int x,y)

24
CORBA Pluses

• CORBA cares about converting to/from strings
• very efficient conversion
• has some diagnostics in cases of failure
• has C and Java bindings
• a standard
• use all other Modelica APIs between processes
• I tried OmniORB (free for commercial use!),
  works well

25
CORBA minuses

• -- is somewhat heavy requires a particular
  compiler, adds a DLL or makes big binaries
• -- Two different CORBA implementations are
  compatible. Same CORBA implementation on
  different platforms is compatible.
• -- many wrappers to write

26
CORBA details

• -- You need RSHD to start a server
• -- Handshaking is tricky to make it very safe,
  there are 2 variants
• Server writes a unique file, client reads it and
  knows from it how to establish connection.
• Naming service (a resident process) knows about
  all servers.

27
SOAP

• Server behaves as a HTTP server, client as HTTP
  client.
• Calls and return values are encoded as XML files.
• Emerging standard makes industry glad
• -- Bad for huge amounts of floating point data
  (encoding to char strings, or may be not
  ?-unclear)
• -- C binding for MSVC6.0 on WinNT.SP6Win2K
  only. Hard to install for client.
• -- Nice for languages with reflection,like
  VBasic,C etc. C people are not satisfied.