"G. Booker" <[log in to unmask]> writes:

> I need help proving (or disproving) why Ada is or isn't well suited
> for a particular application.

Ok.

> I've been an Ada fan for over a decade, and I'm faced with a
> possible application I haven't seen before. 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). 

Sounds interesting.

> So my question is: Is Ada's concurrency capability well suited to
> this type of problem? 

Yes. Ada's concurrency is certainly better than any other language's
concurrency. Mostly because it is actually in the language.

But it depends a lot on how you intend to use concurrency. One task
per cell won't work.

I'd start with one task. It runs a simulation clock that ticks at the
fastest rate you need (every millisecond, apparently). Every tick, it
computes whatever models should run at that time. So most ticks, it
runs the cell models. Every 1000 ticks, it runs the visual model. etc.

Only if you discover that other things should happen asynchronously
from that clock do you need another task. A user GUI would need
another task, for example.

There is no point in wasting CPU cycles scheduling tasks. 

I'm assuming this is not attempting to run in real-time; that might
make a difference.

> Has it been done before in Ada? 

Not exactly this, but I build real-time simulators that simulate
spacecraft; processes from 40 millisecond up to tens of seconds. I use
the task structure I described above.

-- 
-- Stephe