Fortran issues - Revision history

import>Jss43: /* Non-advancing io */

2008-10-13T08:44:09Z

Non-advancing io

← Older revision		Revision as of 08:44, 13 October 2008
Line 150:		Line 150:
	</pre>		</pre>

	This test program fails on the advance='no' statement with all versions of ifort prior to 10.1.017, with a variety of error messages which appear to be both platform and version specific and include hanging, streams of libc errors which force the terminal to be closed, memory errors (which is what we first saw and ~~was~~ "fun" to track down), segmentation faults and invalid statement errors.		This test program fails on the advance='no' statement with all versions of ifort prior to 10.1.017, with a variety of error messages which appear to be both platform and version specific and include hanging, streams of libc errors which force the terminal to be closed, memory errors (which is what we first saw and were "fun" to track down), segmentation faults and invalid statement errors.

	== Installing newer versions of gfortran ==		== Installing newer versions of gfortran ==

import>Jss43: /* Non-advancing io */

2008-10-13T08:43:41Z

Non-advancing io

← Older revision		Revision as of 08:43, 13 October 2008
Line 119:		Line 119:
	== Non-advancing io ==		== Non-advancing io ==

	Non-advancing input/ouput can be specified by using advance='no' in the read/write statement. This feature was implemented in Fortran 95, and is very useful in writing out arrays. Many compilers also allow the use of $ in the format string to do the same thing, but this is an extension and should not be relied upon (in particular, pathscale does not have this implemented).		Non-advancing input/ouput can be specified by using advance='no' in the read/write statement. This feature was implemented in Fortran 95, and is very useful in writing out arrays. Many compilers also allow the use of $ in the format string to do the same thing, but this is a non-standard extension and should not be relied upon (in particular, pathscale does not have this implemented).

	There is, however, a bug in the ifort compilers, which is shown by the following code:		There is, however, a bug in the ifort compilers, which is shown by the following code:

import>Jss43 at 08:43, 13 October 2008

2008-10-13T08:43:06Z

@@ Line 116: / Line 116: @@
  If this line gets printed, then s2 passed.
 </pre>
 == Installing newer versions of gfortran ==

import>Jss43: /* Installing newer versions of gfortran */

2008-10-10T20:18:51Z

Installing newer versions of gfortran

← Older revision		Revision as of 20:18, 10 October 2008
Line 121:		Line 121:
	gfortran is rather strict in some areas, and so is very useful for development and testing work. It is not particularly fast though: for production work it is almost certainly better to use one of the commercial compilers. gfortran is free (as in both beer and speech), so is also good for working away from the sector.		gfortran is rather strict in some areas, and so is very useful for development and testing work. It is not particularly fast though: for production work it is almost certainly better to use one of the commercial compilers. gfortran is free (as in both beer and speech), so is also good for working away from the sector.

	gfortran 4.1 is installed on the sector image (and is on the path: no modules are needed). Unfortunately 4.1 has some minor issues and couldn't compile our code, mainly due to a poor implementation of operator overloading. Later versions fix this and will be in the next sector image, but I'm not the most patient person. ;-) Fortunately it is incredibly easy to install a later version (I chose 4.2, as I already was using it on my laptop, but 4.3 and 4.4 (in development) are available) as GNU offer [http://gcc.gnu.org/wiki/GFortranBinaries precompiled binaries]. I'm not interested in speed, so didn't bother compiling my own.		gfortran 4.1 is installed on the sector 10.2 image (and is on the path: no modules are needed). Unfortunately 4.1 has some minor issues and couldn't compile our code, mainly due to a poor implementation of operator overloading. Later versions fix this and will be in the next sector image, but I'm not the most patient person. ;-) Fortunately it is incredibly easy to install a later version (I chose 4.2, as I already was using it on my laptop, but 4.3 and 4.4 (in development) are available) as GNU offer [http://gcc.gnu.org/wiki/GFortranBinaries precompiled binaries]. I'm not interested in speed, so didn't bother compiling my own.

	I did:		I did:
Line 133:		Line 133:
	* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation). Either way, barfing happens. We can use [[environment modules]] to help us.		* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation). Either way, barfing happens. We can use [[environment modules]] to help us.
	* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.		* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.

			The 10.3 image includes a later version of gfortran. These notes are still useful for later versions of gfortran, however.

	== Cascade compilation ==		== Cascade compilation ==

import>Jss43: /* gfortran */

2008-07-24T11:28:54Z

gfortran

← Older revision		Revision as of 11:28, 24 July 2008
Line 117:		Line 117:
	</pre>		</pre>

	== gfortran ==		== Installing newer versions of gfortran ==

	gfortran is rather strict in some areas, and so is very useful for development and testing work. It is not particularly fast though: for production work it is almost certainly better to use one of the commercial compilers. gfortran is free (as in both beer and speech), so is also good for working away from the sector.		gfortran is rather strict in some areas, and so is very useful for development and testing work. It is not particularly fast though: for production work it is almost certainly better to use one of the commercial compilers. gfortran is free (as in both beer and speech), so is also good for working away from the sector.

import>Jss43 at 00:58, 6 July 2008

2008-07-06T00:58:38Z

← Older revision		Revision as of 00:58, 6 July 2008
Line 133:		Line 133:
	* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation). Either way, barfing happens. We can use [[environment modules]] to help us.		* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation). Either way, barfing happens. We can use [[environment modules]] to help us.
	* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.		* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.

			== Cascade compilation ==

			Cascade compilation is an absolute pain. If you change:
			<pre>
			module m
			contains
			subroutine s(a)
			integer :: a
			write (6,*) a
			end subroutine s
			end module m
			</pre>
			to:
			<pre>
			module m
			contains
			subroutine s(a)
			integer :: a
			write (6,) a*2
			end subroutine s
			end module m
			</pre>
			then a standard makefile will recompile all source files USEing m, even though the interface has not changed (which is all the dependencies care about). If you change the guts of a "root" module that is USEd throughout your code, the recompilation can take some time (for us, it could amount to essentially a clean build). Happily, someone else has done the hard work to solve this: [http://www.nicdan.id.au/computers/compiling/recompile.html]. The Alavi Group settled on option 2.

import>Jss43: /* gfortran */

2008-07-06T00:26:04Z

gfortran

← Older revision		Revision as of 00:26, 6 July 2008
Line 131:		Line 131:

	There are a few gotchas however:		There are a few gotchas however:
	* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation~~, is used instead~~). Either way, barfing happens. We can use [[environment modules]] to help us.		* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation). Either way, barfing happens. We can use [[environment modules]] to help us.
	* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.		* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.

import>Jss43 at 14:59, 5 July 2008

2008-07-05T14:59:57Z

← Older revision		Revision as of 14:59, 5 July 2008
Line 116:		Line 116:
	If this line gets printed, then s2 passed.		If this line gets printed, then s2 passed.
	</pre>		</pre>

			== gfortran ==

			gfortran is rather strict in some areas, and so is very useful for development and testing work. It is not particularly fast though: for production work it is almost certainly better to use one of the commercial compilers. gfortran is free (as in both beer and speech), so is also good for working away from the sector.

			gfortran 4.1 is installed on the sector image (and is on the path: no modules are needed). Unfortunately 4.1 has some minor issues and couldn't compile our code, mainly due to a poor implementation of operator overloading. Later versions fix this and will be in the next sector image, but I'm not the most patient person. ;-) Fortunately it is incredibly easy to install a later version (I chose 4.2, as I already was using it on my laptop, but 4.3 and 4.4 (in development) are available) as GNU offer [http://gcc.gnu.org/wiki/GFortranBinaries precompiled binaries]. I'm not interested in speed, so didn't bother compiling my own.

			I did:
			<pre>
			jss43@keiko:~/src/> wget -O - http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-4.2-x86_64.tar.gz \| tar xvzf -
			</pre>

			This downloads the gcc-4.2 suite (for a 64-bit machines) and extracts it to ~/src/gcc-4.2, which contains the binary and library subdirectories. We are now good to go! The gfortran binary lives in ~/src/gcc-4.2/bin/gfortran.

			There are a few gotchas however:
			* Use either -static or set an appropriate LD_LIBRARY_PATH as otherwise the gfortran.so library is not found at runtime (or the wrong library is used, e.g. the system installation, is used instead). Either way, barfing happens. We can use [[environment modules]] to help us.
			* The acml library provided by the module doesn't work: the gcc people changed some interfaces and you get undefined references. The provided atlas modules don't work on all machines (e.g. my workstation). [[Lapack compilation]] is pretty straightforward though.

import>Jss43: /* Real intrinsic */

2008-07-02T09:13:49Z

Real intrinsic

← Older revision		Revision as of 09:13, 2 July 2008
Line 3:		Line 3:
	== Real intrinsic ==		== Real intrinsic ==

	Care needs to be taken with using REAL(X), which is quite common in older codes. The default behaviour for REAL differs if X is complex rather than integer or real. ~~Some googling reveals this~~ is an oddity, but it is the specification. I have found that DREAL isn't always portable (some compilers have issues when the argument to DREAL is the value of a derived type, e.g. DREAL(X%v) fails at compile time but REAL(X%v) doesn't).		Care needs to be taken with using REAL(X), which is quite common in older codes. The default behaviour for REAL differs if X is complex rather than integer or real. This is an oddity compared to other intrinsic functions, which usually return the same kind as the argument, but it is the specification. I have found that DREAL isn't always portable (some compilers have issues when the argument to DREAL is the value of a derived type, e.g. DREAL(X%v) fails at compile time but REAL(X%v) doesn't).

	<pre>		<pre>
Line 54:		Line 54:

	Or you can just avoid REAL. ;-)		Or you can just avoid REAL. ;-)

			In a similar vein, the following declarations are not equivalent:
			<pre>
			real(kind(0.d0)), parameter :: PI=3.1415926535897931
			real(kind(0.d0)), parameter :: PI=3.1415926535897931_8
			</pre>
			I have found some legacy code which used the former, but meant the latter...

	== ifort and automatic arrays ==		== ifort and automatic arrays ==

import>Jss43: /* ifort and automatic arrays */

2008-07-01T00:48:46Z

ifort and automatic arrays

← Older revision		Revision as of 00:48, 1 July 2008
Line 59:		Line 59:
	This information cost me 3 days of my life. How I cursed ifort... ;-) --[[User:jss43\|james]] 13:07, 30 June 2008 (BST)		This information cost me 3 days of my life. How I cursed ifort... ;-) --[[User:jss43\|james]] 13:07, 30 June 2008 (BST)

	Automatic arrays (where the limits are explicitly provided in the declaration, e.g. X(10,10,10)) are allocated differently in ifort than dynamic arrays using allocatable. The former are allocated on the stack, the latter on the heap [http://ee.hawaii.edu/~tep/EE160/Book/chap14/subsection2.1.1.8.html ~~difference~~]. This also differs from how most other compilers work (see note below). The gotchas are that the default stack on linux is quite small (~8MB) and the allocation on the stack is cumulative: a automatic array is only deallocated once the routine goes out of scope (i.e. has been exited). Once the program goes over the limit, it will just segfault on stepping into a routine, even if the memory allocation for that routine is very small (1kb over the stack limit is enough!). This means that a code can segfault in seemingly random places for no reason, and is rather hard to track down.		Automatic arrays (where the limits are explicitly provided in the declaration, e.g. X(10,10,10)) are allocated differently in ifort than dynamic arrays using allocatable. The former are allocated on the stack, the latter on the heap ([http://ee.hawaii.edu/~tep/EE160/Book/chap14/subsection2.1.1.8.html differences]). This also differs from how most other compilers work (see note below). The gotchas are that the default stack on linux is quite small (~8MB) and the allocation on the stack is cumulative: a automatic array is only deallocated once the routine goes out of scope (i.e. has been exited) in a LIFO fashion. Once the program goes over the limit, it will just segfault on stepping into a routine, even if the memory allocation for that routine is very small (1kb over the stack limit is enough!). This means that a code can segfault in seemingly random places for no reason, and is rather hard to track down.

	So, how can we avoid this? There are a few possible workarounds:		So, how can we avoid this? There are a few possible workarounds: