Is it at all possible to have dynamic 1d/2d arrays in fortran 77 common
blocks?  I have figured out how to make dynamic 1d/2d arrays mixing c and
fortran but I cannot seem to get these to work in a common block.  Is
there ANY way to do this?  I would gladly use f90 modules and
'allocatable' declarations but there isn't a free f90 compiler for my OS
so I'm a bit stuck :(

An example would be greatly appreciated!

Thanks in advance,
Jamie

Jamie <jamiedotwheeleratoxacuk@dummy.com> writes:

> Is it at all possible to have dynamic 1d/2d arrays in fortran 77 common
> blocks?...

Fortran 77 has no dynamic arrays period, in common or otherwise.
(It has adjustable dummy arrays, but those aren't really dynamic).

That is one of the major new things introduced in f90.

There are various compiler-dependent hacks, different with
different compilers, to fake up something.  But there are all
kinds of caveats, complications, and limitations.  The cost
of working with them is higher than the cost of just buying a
compiler.

Or more specifically, my consulting fee for figuring out how
to make them work out for your situation would be higher than
the cost of a compiler.  :-)

Btw, even in f90, allocatables and COMMON don't mix.  COMMON is about
static memory layout and is fundamentally incompatable with dynamic
allocation.  You can put F90 pointers in COMMON, but they aren't
compatible with C pointers, so that won't get where you want to be.
C/Fortran interaction of dynamically allocated storage remains a bit
tricky unless you can get by with passing the dynamically allocated
array as an argument instead of through common (with all the
dynamic bits done on the calling side).

P.S. To elaborate on the smiley.  No, I don't actually do consulting
for money.  And if I did, I sure wouldn't be advertising it from a
government account.  The money I'd make wouldn't be enough to pay
a lawyer to keep me out of jail, or at least from being fired.  :-(

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Jamie"  wrote
> Is it at all possible to have dynamic 1d/2d arrays in fortran 77 common
> blocks?

A package of subroutines to do this, after a fashion, is included in the
PORT optimization package (based on NL2SOL) and can be downloaded from
netlib.

>"Jamie"  wrote
>> Is it at all possible to have dynamic 1d/2d arrays in fortran 77 common
>> blocks?

As Richard Maine pointed out, Fortran77 doesn't have dynamic memory of any
sort.   And common blocks are a static form of storage, which don't fit in
with dynamic arrays at all well, so the combination you ask for really
doesn't exist.

You really ought to get a Fortran95 compiler, but if you are only prepared
to get a free one, then consider F, but it doesn't support obsolete
constructs such as common blocks.

Other free alternatives with some dynamic storage facilities:

g77 supports automatic arrays - dynamic arrays which persist only within a
subprogram while it is executing.  Can be run on just about all operating
systems.

OpenWatcom supports allocatable arrays.  Can be run on Windows only, as
far as I know.

In neither case can you combine dynamic arrays with common blocks.


-- 
Clive Page

Jamie wrote:
> Is it at all possible to have dynamic 1d/2d arrays in fortran 77
> common blocks?  I have figured out how to make dynamic 1d/2d arrays
> mixing c and fortran but I cannot seem to get these to work in a
> common block.  Is there ANY way to do this?

I obviously don't want to contradict the other replies. BUT, depending
on quite what the OP meant by "ANY", there is the possible basic
approach that I am sure has been implemented many times. Simply
declare a single large 1-D array of fixed size, large enough to cover
the expected range of cases but small enough to fit into any system
contraints. Then locate all the small variable-size arrays within this
by computing starting addresses within the large array for each small
array. Then, either implement this by computing addresses or the
required elements directly, or work using subroutines or functions
where you use the element of the large array at the location of the
start of the required small array as the actual argument of the
subroutine or functions, but in the subroutine or function you declare
the array as being of the required rank and dimension so that most of
the element-addressing can be done in relatively simple fortran or C.
The large array (or arrays for separate integer, real, character
things) can then be put in a common block, as can the lists of
starting-addresses.

David Jones

"David Jones"wrote:.

> Simply declare a single large 1-D array of fixed size, large enough to
cover
> the expected range of cases but small enough to fit into any system
> contraints.

And because of the fixed relationship between integer, single, and double
variable size in classical fortran, all these types can be equivalenced into
the same common block and used as needed.  Perhaps a programmer would not
call this "dynamic", but it looks like the same thing to an engineer.

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> "David Jones"wrote:.

>> Simply declare a single large 1-D array of fixed size, large enough
>> to cover the expected range of cases but small enough to fit into
>> any system contraints.

> And because of the fixed relationship between integer, single, and double
> variable size in classical fortran, all these types can be equivalenced into
> the same common block and used as needed...

Yes, you can.  And if you are doing really dynamic stuff, where things
might be allocated and deallocated multiple times, possibly with
different sizes, during a single run, before long this method of
doing it "simply" turns pretty complicated.  I've seen f77 (and f66)
programs that had utility libraries to do this kind of thing....
where the utility library alone was larger than what many people
would call a big program.  And code throughout the whole application
was majorly affected by the interface to the utility library.

If you are doing something small and simple, it can work.  If you
are doing something big, then this is exactly one of the kinds of thing
I was thinking about when I mentioned that it would cost you more
than a new compiler (probably by multiple orders of magnitude).

Not too many years ago, I had to trace through some of that style code
in order to find a bug in an old program that suddenly stopped
working.  It wasn't fun.  Turned out to be a trivial bug once I found
it, but took a while to find.  And it was a y2k bug.  (A date was
written into a character form...well, actually a Hollerith, this being
from pretty old code.  That got asterisks when it overflowed the
field, which ended up stored in one of those dynamic areas.  The
problem didn't surface until elsewhere in the code, when something
reading the field got an error on the asterisks.  The hard part of
the debugging was in working through the dynamic storage stuff to
find what code had written the field that the read was failing on).

It was for a local Dryden user, but if I did paid cunsulting and this
had it been done on such a basis, the fee would have been in 5 digits
(dollars or Euros - take your pick, but not Yen.  :-)) for this one
trivial bug fix.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

"Jamie"  wrote

> Is it at all possible to have dynamic 1d/2d arrays in fortran 77 common
> blocks?

I suppose you know about the automatic arrays in g77, which are an extension
to the f77 standard.

Richard Maine wrote:
> ... if I did paid cunsulting and this
> had it been done on such a basis, the fee would have been in 5 digits
> (dollars or Euros - take your pick, but not Yen.  :-)) for this one
> trivial bug fix.

Ah, but your client could take comfort in the fact that he avoided paying
a couple hundred bucks to some greedy corporation for a modern programming
tool.  ;)

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Richard Maine <nospam@see.signature> wrote:
> 
> Yes, you can.  And if you are doing really dynamic stuff, where things
> might be allocated and deallocated multiple times, possibly with
> different sizes, during a single run, before long this method of
> doing it "simply" turns pretty complicated.  I've seen f77 (and f66)
> programs that had utility libraries to do this kind of thing....
> where the utility library alone was larger than what many people
> would call a big program.  And code throughout the whole application
> was majorly affected by the interface to the utility library.
> 
> If you are doing something small and simple, it can work.  If you
> are doing something big, then this is exactly one of the kinds of thing
> I was thinking about when I mentioned that it would cost you more
> than a new compiler (probably by multiple orders of magnitude).
> 
> Not too many years ago, I had to trace through some of that style code
> in order to find a bug in an old program that suddenly stopped
> working.  It wasn't fun.  Turned out to be a trivial bug once I found
> it, but took a while to find.  And it was a y2k bug.  (A date was
> written into a character form...well, actually a Hollerith, this being
> from pretty old code.  That got asterisks when it overflowed the
> field, which ended up stored in one of those dynamic areas.  The
> problem didn't surface until elsewhere in the code, when something
> reading the field got an error on the asterisks.  The hard part of
> the debugging was in working through the dynamic storage stuff to
> find what code had written the field that the read was failing on).
> 

This style is (or was) common in particle physics. These libraries
(BOS, HYDRA, ZEBRA, ...) were developed in the 70s. There was a need
for dynamic storage handling and Fortran at the time didn't provide
any support for that. I am the maintainer of a big software package
based on such a library. Yes, debugging can be pretty hard.

Fortran 77 programming in this style for modifications of existing
software is still a big activity, but new code in the field is written
in C++. At the time when that was decided, Fortran 90 (it may still
have been called Fortran 88 then) was not yet widely available.


-- 
Klaus Wacker              wacker@Physik.Uni-Dortmund.DE
Experimentelle Physik V   http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund     Tel.: +49 231 755 3587
D-44221 Dortmund          Fax:  +49 231 755 4547

"Walter Spector" wrote i
> Ah, but your client could take comfort in the fact that he avoided paying
> a couple hundred bucks to some greedy corporation for a modern programming
> tool.  ;)

1) Some of us don't have clients, but use fortran as a personal productivity
tool and pay for it from our own pockets.  A couple of hundred dollars would
be OK, if it were really that cheap, if no add-ons were required and if you
didn't have to buy an upgrade every time Bill Gates sneezes.  Even a couple
of hundred dollars a year would be OK if it really handled the running and
debugging of netlib-based code as well as a mature f77 compiler.

2) Some of us work in departments where everyone else uses C, and don't want
to abandon the bridge provided by f2c.

3) Some of us usually solve new problems simply by modifying old code, and
believe it counterproductive to mix programming styles.

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> 3) Some of us usually solve new problems simply by modifying old code, and
> believe it counterproductive to mix programming styles.

Yep.  Understand that.  The code I was talking about was an old one
still being used (for the same problems, not even new ones - just needed
the code to stay working after y2k).  Painful as dealing with the code
was, I didn't even think about recommending that they rewrite it.  The
cost/benefit wasn't even close to being there.  I just fixed the old
code and they are still using it today.

But I wouldn't think of writing new code like that.

And I probably wouldn't add new functionality by modifying the old
code either, because it would just be too much work for the code in
question.  If they ever need new functionality, it is going to be
expensive no matter what.  Big job to rewrite.  Probably about the
same size job, if not bigger, to figure out the existing code well
enough to add something.

Of course, if it is an old code that you (or anyway someone you
can contract with) are already familiar with, that changes the
tradeoff point substantially.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain