Re: Ada vs Fortran for scientific applications

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Wed, 24 May 2006 12:56:29 +0000, J.F. Cornwall wrote:

> Dr. Adrian Wrigley wrote:
>> On Tue, 23 May 2006 17:07:06 +0000, Dan Nagle wrote:
>> 
>>> Hello,
>>>
>>> Dr. Adrian Wrigley wrote:
>>>
>>> <snip>
>>>
>>>> Isn't this a bit more like MPI?
>>> Well, it's like MPI minus the rubbish.
>>>
>>>> In Ada, these concurrency features are very robust and streamlined.
>>>> This is because tasking was a primary goal of the language design.
>>>>
>>>> For a typical Fortran application like weather forecasting, this
>>>                                                                ^^^^
>>>> is exactly the architecture you might choose.  It may be
>>>> hardcore numerical code.
>>> I'm not sure which antecedent "this" references,
>>> but the meteorological folks are one of the main
>>> forces behind co-arrays.
>> 
>> In a weather forecasting program you want to have data
>> acquisition (real-time), prediction (computation) and display
>> (real-time GUIs) running on a continuous, high uptime basis
>> across a network of machines.
>> 
>> If Fortran had strong multitasking, real-time and distributed
>> capabilities, these goals would be reasonable and achievable
>> within the language. Absence of these features means such
>> systems would often (I guess) be multi-language setups, with things
>> like Java, C++, Tcl/Tk, shell scripts, cron jobs etc. playing a part.
>> Has anyone here worked on a big meteorological system? Am I right?
>> 
> 
> In my US Air Force days, I worked at a large global weather-forecasting 
> facility.  We had multiple data input systems (a variety of comm links 
> talking to several Univac mainframes), multiple number-crunching systems 
> (a couple more Univacs and a Cray), and an cluster of 40 or so Vax 
> 11/780s for interactive tweaking of the forecasts.  The majority of the 
> software for the comm was in assembler, just about all of the remainder 
> was Fortran (IV and 77, this was back in the early 80's...).
> 
> We also used Fortran mixed with assembly code for a new comm front-end 
> machine that was implemented in '88.  Fortran was used for comm, utility 
> programs, forecasting models, database input/output/maintenance, and 
> just about everything else in that system.  Worked fine.

Interesting.

I *think* you are supporting my view that in practice, Fortran
requires additional support or coding outside of the language to tie
together the different parts of a complex system.
You speak of utility programs, forecasting programs, database I/O
programs.  Invoking these in the right order, at the right time,
on the right files at the right terminals is always done
outside of the pure Fortran application.  At the very least
it requires an OS command interpreter.  It probably involves
scripts to delete old files or do other housekeeping.

In Ada, the separate program components can form a *single*
running application program entity, with a single invocation - even
if the program is running across several loosely connected machines
and consists of many different executable files.  The program
execution is a network of cooperating processes and shared
data stores.  Parts of the program can even be recompiled as
it runs - without affecting the shared data stores or other
executing tasks.  In fact Ada supports persistent variables
with hold their values even if the program is stopped completely
and restarted later.  No mainstream language comes even close
to this program execution model.
--
Adrian