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 -> 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 let’s 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. Michael’s 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 doesn’t 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 x+y+z;} } • Client A*a=get_from_server(…) print(a->foo(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 MSVC++6.0 on WinNT.SP6+Win2K only. Hard to install for client. -- Nice for languages with reflection,like VBasic,C# etc. C++ people are not satisfied.