One advantage of Ada is that it provides high-level synchronization
mechanisms that are operating system independent. Keeping the different
models synchronized so that multiple simulation runs with identical initial
conditions produce the same results is one of the major challenges of
simulations of that type, and one of the requirements for demonstrating that
the model works correctly. Low-level synchronization devices such as
semaphores only work if everyone uses them correctly, and using them for
high-level synchronization results in an abstraction inversion. It's much
easier to build the synchronization "rules" into interfaces using Ada than
with other languages.

In addition to facilities for concurrency, in which Ada is without peer, it
also has numerous other advantages.

For example, if your models are passing messages, it's much easier to build
the "grammar" of a correct message into the data structures using Ada's
strong typing and variant records than with other languages. The consistency
requirements can be built right into the data structures rather than having
to be put into code and maintained there.

Also, Ada's stream facilities are very good for efficiently handling
information that has to be serialized for passing over a network as well. If
your model is distributed (and if it isn't now, it probably will be in the
future,) and the content of your information changes, rather than your
having to change code for reading and writing the composite information,
streams will handle it automatically. Unlike C++, the default format for
streams is binary rather than ASCII. This makes things much more efficient
for a homogeneous execution environment. If different parts of your model
run on different machines (endianness, floating point format, default
integer size, etc.) you can override the read and write attributes for the
types which comprise the messages and pass data in ASCII or some other
well-defined execution environment independent format.)

If the components of your model are already in multiple languages, (and here
again, if they aren't they probably will be in the future) Ada provides more
facilities for interfacing to other languages than any other language of
which I am aware.

Having taken some bioengineering courses during my undergraduate and
graduate work, your topic sounds like a very interesting combination of
bioengineering and software engineering. I wish you the best of success, and
hope you have found my comments helpful.

Bob 

-----Original Message-----
From: Team Ada: Ada Programming Language Advocacy (83 & 95)
[mailto:[log in to unmask]] On Behalf Of Jeffrey Carter
Sent: Tuesday, September 12, 2006 5:53 PM
To: [log in to unmask]
Subject: Re: Ada for system biology modeling

G. Booker wrote:

> I'm a PhD student in biomedical engineering.  A major part of my
> dissertation will involve getting various mathematical models, of how
> parts of the body work, to interact with each other.  The challenge
> is that the models are working on different physical scale levels
> (from sub-cellular to the whole body), and on many different time
> scales (millisecond-duration processes to ones that take months or
> years).

> So my question is:  Is Ada's concurrency capability well suited to
> this type of problem?  Why or why not?  Has it been done before in
> Ada?

I'm not sure how concurrency will help you in such a project. You want 
to apply the mathematical models to appropriate data. You may invoke 
some models many times for each invocation of another model.

I would think that you would do this in a similar manner in Ada as in 
any other language. Ada would be suitable, and would have the same 
advantages of detecting errors early as it does in other domains.

You might also want to post in comp.lang.ada, especially if you have 
more detailed questions.

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06