Ideas...
Michael Tiller
(since that is a topic I'm very interested in).
I'd be very interested to see additional discussion in this group
about Modelica. By adopting such a standard many more possibilities
will emerge. I know of at least three implementations that are either
free or open source (with various levels of capability) and numerous
commercial implementations as well. If anybody is interested in
having such a discussion, I am at your disposal.
Another thing I would suggest would be to setup a Trac site (either
hosted or on your own machines). While Google groups provides
reasonably good communication facilities (email, archiving, basic file
sharing), tools like Trac provide a greater degree of collaboration
(ticket system, wiki+attachments, web interface to version control
repository, timeline, roadmap, etc).
As to the topic of a more elaborate editor for your models (XML based
or otherwise), I would add a note of caution. I realize that coming
from an outsider this may not be particularly welcome. My objective
is not to point fingers or be critical, but I would add that I see a
real risk of taking on a greater and greater support burden (for the
editor, for the runtime environment, for the simulation engine) by
using "in house" technologies. I do realize that it is non-trivial to
migrate but it seems like Jiri has some intentions of doing that
anyway (i.e. moving to Modelica) and from my perspective that seems
like something worth looking at very carefully.
Michael Tiller, Ph.D.
Vice-President of Modeling Research and Development
Emmeskay, Inc.
Secretary of the Modelica Association
Tom Coleman
I'm familiar with Modelica and there are two factors here that are very important.
1) The (good) commercial versions of Modelica are rather expensive. We are trying to develop an environment for the biomedical community that is very inclusive and costly software works against our basic aims.
2) The Modelica free software is not worth a shit.
All evaluations of Modelica at this point in time should (in my opinion) give a balanced analysis of the pros and cons.
Further progress in this area hinges on a carefully reasoned analysis of cost vs. benefit.
Best wishes, Tom Coleman
Michael Tiller
> Michael,
>
> ...
> All evaluations of Modelica at this point in time should (in my opinion)
> give a balanced analysis of the pros and cons.
>
> Further progress in this area hinges on a carefully reasoned analysis of
> cost vs. benefit.
I completely understand that you would not want to depend on
commercial software for your work. Furthermore, I agree that the
commercial implementations are really quite far ahead of what is
freely available. My hope is that the quality of the free
implementations will improve significantly. For example, I know that
the OpenModelica group just got a significant grant to improve their
implementation and INRIA seems to be working quite hard on theirs as
well. I know of a third that is in the works but I don't think it is
public knowledge and I don't know enough about the implementation to
say how it compares to existing commercial implementations.
One thing I'm curious about is what your requirements are for such a
tool. Obviously, the ability to simulate Modelica models is the most
important aspect but I assume that is not what you found lacking in
you assessment of existing free tools. Are you concerned about having
a graphical user interface? I assume you want certain capabilities
from the underlying simulation engine? What kinds of post-processing
capabilities do you expect? etc. Would it be possible for you to
elaborate on these issues a bit?
You raised the issues of "pros" and "cons". From my perspective,
here is what I would see as the pros and cons:
Pros:
* Leveraging an existing modeling language for which there is a
complete specification and for which textbooks exist.
* Specific features of the language:
* Expressive initialization capabilities (to initialize systems,
for example, in quiescent states)
* Sophisticated configuration management capabilities (ability to
express inheritance and redeclarations between models)
* Support for hybrid DAEs.
* Semantics designed to protect for extensive symbolic
manipulation (leading to faster simulation times)
* Open metadata system allows inclusion of arbitrary information
like validation data, sources, documentation, etc)
* Ability to express clearly the delineation between "interface"
and "implementation" for a model.
* Leveraging capabilities from existing tools:
* Model editing capabilities
* Post-processing capabilities
* Implementation, maintenance and improvement of underlying
simulation engine (solvers)
* Constantly improving model compilation techniques (e.g. index
reduction, tearing, state selection)
* Ability to leverage existing work both in the specification of the
language and implementation of tools.
The last one, although a single bullet item, is quite significant
because what it means is many of the mundane aspects of developing a
tool (user interface, editor, post-processing, etc) could be
"offloaded" and more focus put on authoring models. I don't know what
your grant processes are like but I would imagine that one of the
things they would look for would be to see that the majority of the
research represented novel capabilities. I would think such focus on
model authoring would help in that regard (but again, I don't know).
Cons:
* Migration time and effort
* Risks associated with using non-"in house" tools:
* Lack of needed functionality
* Poor support from tool supplier
Although I wouldn't list it as a "con" exactly, there seems to be a
design pattern in QHP with respect to how information about the state
of the "human" is conveyed around the system that would probably end
up being slightly more complicated in Modelica. I'd need to
understand QHP a bit more before I could really comment on exactly how
this could be addressed in Modelica. I would add that one of the nice
things about the Modelica design process being an open one (~6 design
meetings a year, anybody can attend) is that such issues are often
discussed in these meetings and solutions are often quickly
identified.
I'm not sure if this is what you had in mind for such a discussion?
I'd be interested in seeing whether you have the same view of the pros
and cons or if you feel there are things I've left out.
--
Mike
Jiří Kofránek
I have been firmly convinced, that selection of Modelica as implementation language for developing large physiological models will pay off.
Our experience - way from Simulink to Modelica:
We have many years used Matlab/Simulink platform as a main simulation tools. In Simulink we have developed an extensive physiolibrary (http://patf-biokyb.lf1.cuni.cz/wiki/projekty/physiolibrary) and model that is in the core of our Golem simulator (its first version is described here http://cmbi.bjmu.edu.cn/news/report/2001/medinfo_2001/Papers/Ch12/919_Kofranek.pdf ). We have been interested in using simulation in biomedical education for explaining complex physiological regulations – see http://www.physiome.cz/atlas/info/00EN/index.htm. We are designing a special Atlas of physiology and pathophysiology www.physiome.cz/atlas see paper: http://patf-biokyb.lf1.cuni.cz/wiki/_media/clanky/atlas_of_physiology_and_pathophysiology.pdf?id=wiki%3Auser%3Aseznam_publikaci&cache=cache
The Atlas is a combination of two main domains. One is multimedia presentations and the second are simulators or simulation games. The aim is to combine theoretical knowledge with a simulated experience. At this time, most of the Atlas is not translated to English, but it is a matter of time (and, we hope, cooperation with others). We sought the tools for design and implementations of mathematical models (Simulink/Matlab and nowadays Modelica) and the tools for designing e-learning tools and educational simulators (Adobe Flash, .NET tools like Microsoft Visual Studio or special tools for visualization of Industrial measurement and control systems – e.g. Control Web ). In connection with it we needed the tools for easy conversion of verified simulation models (e.g. written in Simulink) into core of educational simulators (e.g. written in C#). We have designed a special wizzards that help us to solve this problem – see http://patf-biokyb.lf1.cuni.cz/wiki/_media/clanky/development_of_web_accessible_medical_simulators.pdf?id=wiki%3Auser%3Aseznam_publikaci&cache=cache.
Year ago we have switch to Modelica. Unlike block oriented approach in Simulink, Modelica offers describing a model using net of equations. It is more clear then complicated block schemes in Siumulink.
Especially in the large physiological models Modelica is the tool that bring more understandable notation of model, than others simulation tools. E.g. – it may be demonstrated to comparison of implementation of old Guyton model in Simulink (http://dsp.vscht.cz/konference_matlab/MATLAB07/prispevky/kofranek_rusz/kofranek_rusz.pdf ) and in Modelica.
Modelica is standardized programming language, so we can write models that can be solved using commercial (Dymola or MathModelica) or noncommercial (Open Modelica) tools.
Now we have concentrated into one platform for designing of simulation models and educational simulators – Modelica and .NET environment.
Our aim in this area is to translate the mentioned QHP model and our physiolibrary into Modelica. Both are originally written in a "block oriented way" and it is a challenge for us to show the unique properties of Modelica language when properly modeling in physical manner.
Side by side with the translation of the QHP model and physiolibrary into Modelica, we want to develop a Physiological Modelica Library and give it open source to the Modelica community.
Modelica .NET open source project
- There is a long tradition in our lab with .NET as the target platform for simulation applications. Nowadays it seems even more interesting because of new bits like WPF and Silverlight that are a great graphical frameworks/platforms that can be used for graphically rich simulation games for education. Namely Silverlight will be used for simulators embedded into web pages. This will significantly simplify deployment, usability and portability (Silverlight runs on Win/Mac and its clone Moonlight runs on Linux). However, the ability to run in-browser has a non-trivial downside because all the code has to be managed due to security reasons (we used to run our Simulink models natively/unmanaged with full .NET previously, but this is not possible since the browser security sand-boxing). We have decided to sacrifice some performance penalty and the troubles connected with full managed .NET targeting in favour of the advantages of portability and usability.
-We have done some successful tests with retargeting the OMC to C# with some simple models (e.g. simple ODE model of blood circulation) and it gave us a real hope to be able write a model in Modelica and get its runnable representation in .NET. Our working copy of OMC was tweaked to produce C# simulation code. At this time, it works only for models without events and there is a limited support for functions, but it is good enough to get a model simulation code to .NET in a semi-manual manner.
Then, we have started to leverage the new .NET language F#, that is a perfect match for our .NET coding needs. To try it out properly, the IDA solver from SUNDIALS was translated to F# that will be the main part of our .NET simulation runtime for more complex models or just as an equivalent to DASSL solver to enable future whole .NET Modelica modelling (the F# IDA is not yet fully tested now, but coming soon).
As our passion for Modelica and the new graphical capabilities of .NET continued, we realized that it would be a great challenge to develop a Modelica graphical editor that can be run in-browser (Silverlight).
It will have a client/server architecture that will enable, for example, on-line collaborative modelling in Modelica. Models and libraries will be stored on the server in an SVN repository.
This project was already launched at the Charles University in Prague, Faculty of Mathematics and Physics as a master degree student's project (four students, http://www.codeplex.com/ModelicaEditor).
http://patf-biokyb.lf1.cuni.cz/wiki/modelica.net
Our Goals for next year:
1. Implement the large physiological models in Modelica – especially QHP. We will be use Dymola implementation of Modelica. The results of our work we will shared in this Modeling Workshop Group
2. Develop the Modelica .NET environment (as open source, as a part of Open Modelica project) – and tested this tool using our Modelica models designed by means of commercial Dymola and developed multimedia in-browser educationals simulators using Silverlight and .NET.
Michael Tiller
Thank you for posting such a thorough discussions of your plans.
You mention .NET but it sounds like your work on the .NET platform is
mainly supporting the simulation side...is that correct? Do you
intend to continue leverage the OMC for the parsing, semantic analysis
and flattening?
I find your approach to graphical front ends to be quite in line
with my own thinking. I am impressed that you are looking so closely
at integration with technologies like Flash and Silverlight. Have you
considered how you might use the annotation system in Modelica to help
you to closely couple the visualization aspects of the models with the
models themselves?
Have you been in contact with anybody from the OpenModelica group or
the Modelica Association? I don't recall seeing any publications by
your group at the last Modelica conference. I certainly hope you will
contribute some papers to the next Modelica conference (which will be
in Italy, BTW).
What isn't clear to me is your status in translating the QHP models
into Modelica. Do you have examples of this translation? I'd be
interested in seeing how you addressed some fo the issues I pointed
out in my previous emails.
--
Mike
Tom Coleman
This is exactly what I had in mind.
If we can get a Modelica implementation that is free and
distributable, then we (I or others) will immediately translate our
modeling library to Modelica and post it on the Web.
Doing QHP in Modelica is a longer term objective and Jiri will have a say in this (I hope). There will be some problems but that is what makes it exciting.
Snarky note. Modelica must support the easy models first (in my opinion), and then the more difficult models come later.
Best, T.C.
Michael Tiller
> Michael,
>
> This is exactly what I had in mind.
>
> If we can get a Modelica implementation that is free and
> distributable, then we (I or others) will immediately translate our
> modeling library to Modelica and post it on the Web.
Now would be an excellent time to write down your requirements.
OpenModelica is already "free" and "distributable" so, as I mentioned
before, I assume your requirements (understandably) run deeper than
that. The reason I say it is an excellent time is that ITEA2 (in
Europe) just approved $11 million Euros in funding for a project that
has OpenModelica as a foundational piece of technology. As such,
development of of OpenModelica is going to (hopefully) become a much
more serious affair. The key is going to be to interact with that
group and make sure that your needs are being addressed.
> Doing QHP in Modelica is a longer term objective and Jiri will have a say in
> this (I hope). There will be some problems but that is what makes it
> exciting.
> Snarky note. Modelica must support the easy models first (in my opinion),
> and then the more difficult models come later.
provide some assistance here. Do you or Jiri have some models in mind
to consider first? I'd like to keep the ball rolling on this so
perhaps we could actually work out some specific goals here? Ideally,
it would be great to carve out a small subset of models and issues
that capture all the "design" difficulties but without having to
exhaustively implement all the models. As a guess (not knowing much
about QHP), I would imagine that the following issues would be pretty
important:
* Sharing information about "global" (body wide) state through out
the system.
* Easy handling of "tables" (expressing x=f(y) or x=f(y,z) where "f"
is known from data).
* Representation of environmental conditions (sitting vs. standing,
ambient temperature, exercise level, etc)
* Proper design pattern so that one model can properly impact
another model (how infarction affects heart behavior)
* Representation of chemical control volumes/concentrations of
various compounds.
* Computing material properties (viscosity, density, etc).
* Capturing reference data (this should be pretty easy I think).
* Proper architecture to allow multiple implementations for various
subsystems.
Am I even close?!? Every modeling project always has its own quirks
and you would know far better than me what the real challenges are.
I'm just speculating.
My point is to first identify what you think the key "design patterns"
are in QHP and then see if there is a relatively small (and
verifiable) system model that requires all those to be implemented.
Is there such a system?
> Best, T.C.
--
Mike