On Dec 26, 2005, at 2:00 PM, Aleksandar Donev wrote:

> Ben Blackwell wrote:
>> Is there a way to spawn jobs (run finite element code) from within
>> the F90 optimization code?
> You should probably not use "spawn" unless you are talking about
> parallel programming (spawning threads or such).

I'm not sure why not. I've never particularly associated the word 
"spawn" with parallel programing, and I don't think it historically has 
such an association. If I recall correctly, the VAX intrinsic for 
running a program was something like LIB$SPAWN, so the general 
(nonparallel) usage has a long history.

> It will be part of the next revision of Fortran,

A slight clarification about what is meant here by "the next revision". 
Perhaps it is clear to most people, as I think this is perfectly 
correct, but my initial reaction was to note that the feature had been 
rejected for f2003. But then I realized that you were probably talking 
about the revision after f2003, as f2003 is the current one.... even 
though nobody has compilers for it yet. So although you are correct (I 
presume), I just wanted to make sure that nobody misunderstood and 
expected to find a standardized version of this in the next revision of 
the standard that they see a compiler for, as opposed to the next 
revision of the standard that is published.

To the OP: One of the other responses alluded to it, but I thought I'd 
push a little about thinking of what the implications are of using a 
subroutine versus a separate program. At a sufficiently high level of 
abstraction, the two concepts are the same. Furthermore, turning a 
program into a subroutine or vise versa is possible. Just because 
happen to have a program, that doesn't necessarily mean that is the 
only way to keep it, although that can certainly be an influence. I see 
a few big issues to consider.

1. How does the communication of data work? With a subroutine this is 
relatively straightforward; the data is normally communicated via 
arguments, although all the other methods are possible. WIth a separate 
program, communication by arguments is not typically available, so you 
are forced to do something else - most commonly involving writing data 
out to a temporary file, although in some environments things like 
shared memory can be used (but that's more complicated). The issues of 
communication are a big reason to go with a subroutine.

2. Will a program work correctly when turned into a subroutine? In 
general, this need not be a big deal. But some programming practices 
can cause problems. In particular, initialization can be an issue. 
Things that are initialized at the beginning of the program, but then 
changed during execution, might need to be initialized at the beginning 
of each invocation of the subroutine. Depending on the code, this can 
be a significant pain, or no problem at all. The worst problem is with 
nonstandard codes that just assume initialization of memory; those 
codes give you little hint of where to look. Of course, such codes are 
sometimes problems in other situations also - I consider that to be a 
poor programming practice.

Smaller issues relate to possible global conflicts such as procedure 
names or unit numbers. This isn't usually a big deal, but is something 
that might need addressing.

If it takes a lot of work to get a program working as a subroutine, 
then that can be a significant argument for not doing it.

3. Maintenance issues. If you have reasons for not wanting to touch the 
code of the program, than that can be an overriding issue. Perhaps the 
most extreme case is when you don't even have source code for the 
program. But it can be almost as bad if you have the source code, but 
it is too large and complicated to want to deal with. Another variant 
is that you need to avoid modifications to the code because you 
anticipate regular updates being made to it and you don't want to have 
to continually merge those updates with your forked version. Or perhaps 
if there are other configuration control issues.

Anyway, the message here is to think seriously about the tradeoffs of 
turning the program into a subroutine or not. Don't dismiss the 
possibility out of hand just because the code happens to be in the form 
of a program right now. Admittedly, the factors mentioned in item 3 
above can make even a serious consideration pretty short, but it isn't 
clear from the original post whether this is the case or not.

-- 
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain