cray-fortran cft77

[Gernot Heiser]

In article <8911031050.AA02617 at reason.psc.edu> ZRTA at DS0RUS1I.BITNET (Bernhard Bauer) writes:
}
} On our site at stuttgart university we have a cray2 running unicos.
} Yesterday, 11.02.89 we switched from unicos 4.0. to unicos 5.0.7
}and we did also a compiler switch from cft77.3.0 to cft77.3.1.
}It was our second try.
}A user, who had the following peace of fortran code which
}was running well with cft77.3.0 [ ... ]

already professionally addressed by another poster.

} Another Problem:
}Another user has an INPUT file which contains 10 records.
[ ... ]
} Are there more cray users who have observed such I/O problems?

As above. Except I might add that I experienced a few problems with I/O on the
Cray-2 even with cft77 version 3.0. I haven't had the time yet to try with
version 3.1 yet, but in general I/O on the Cray-2 seems to be a bit flaky to
say the least. (I never had any problems on the X-MP, nor on a Y I tested
recently in the US. Needless to say, the code runs without problems on various
smaller sytems.)

} A third problem I wish to notice is the following:
}A recursive subroutine is called by a main program. It ran very well
}with the compiler version cft77 3.0.0.14. In fact in ran properly
}even with the 2.0 compiler version. But now it results in an error.
}This kind of code is very usefull in the case of developing
}multi-grid programs. In fact a multigrid program will not work
}any longer.
} I have been told that this program is not standard fortran
}(I know it) and that I am using dynamical field allocation which
}is not allowed in standard fortran. However, if I can not program
}in this manner, I have do change the language!

Well put! The only reasonable thing to do with FORTRASH under all circumstances.

} Here is the fortran code.
}
}      program tst
}      parameter (nmax=5,ndim=33)
}      integer ifeld(nmax)
}      real    a(ndim)
 ...
}      call up(n,ifeld,a)
}c
}      stop
}      end
}c
}      recursive subroutine up(n,ifeld,a)
}      integer ifeld(n)
}      real a(ifeld(n))
}      real b(ifeld(n-1))

this is most certainly not FORTRAN. Firstly, the parameter declaration is
wrong. To quote ANSI X3.9-1978, section 5.1.1.1:
"A dimension bound expression must not contain a function or array element
reference."

the proper way to do this would be:
	CALL UP (N, NDIM, IFELD, A)
...
	RECURSIVE SUBROUTINE UP (N, NDIM, IFELD, A)
	INTEGER N, NDIM, IFELD(N)
	REAL A(NDIM)

The dynamic allocation is an absoulte no-no in standard F. What you can do is
managing your own little heap:

	INTEGER HUGE
	PARAMETER (HUGE=10000)
c 	   ... or whatever may be required
	REAL HEAP (HUGE)
...
	CALL UP (N, NDIM, IFELD, A, HEAP)
...
	RECURSIVE SUBROUTINE UP (N, NDIM, IFELD, A, HEAP)
	INTEGER N, NDIM, IFELD(N)
	REAL A(NDIM), HEAP(*)
...
	CALL UP (N, NDIM, IFELD, A, HEAP(NDIM+1))
...

Yes, it's awful, but that is what FORTRAN is all about. 

Alternatively, if you don't care about portability, you can hack around with
Cray-FORTRAN pointers. Or (as I do) write an interface to the C memory
managment routines (malloc(3) & Co), which is at least portable throughout the
UNIX world.

>>> BEGIN FLAME

And people keep telling "we have to use FORTRAN because of all our running
codes...". If you see how expensive FORTRAN programming is due to the
insufficient and error-prone language features, rewriting in a programming
language would certainly be cheaper in the long run in almost all these cases.

>>> END FLAME

}Bernhard Bauer
}systems programmer
}at the university of stuttgart
}germany
}Acknowledge-To: <ZRTA at DS0RUS1I>


-- 
Gernot Heiser                   Phone:       +41 1/256 23 48
Integrated Systems Laboratory   CSNET/ARPA:  heiser%iis.ethz.ch at relay.cs.net
ETH Zuerich                     UUCP (new):  heiser at iis.uucp
CH-8092 Zuerich, Switzerland    UUCP (old):  {uunet,mcvax,...}!iis!heiser