Which standards are supported?
The general rule is that anything that passes verification on our certified test platforms can go into the Molcas source code.
Some compilers implement newer Fortran standards gradually, so it is not always easy to know if some language feature you want to use will be accepted into the Molcas source code. This page is intended to give some guidelines about things that are safe to use, and what you should avoid.
All compilers on the test machines support at least the Fortran 95 standard, but they all include some form of support of Fortran 2003 and Fortran 2008.
An overview of compilers used for verification testing:
- GCC 4.4.7 (bestla)
- GCC 4.8.3 (byleistr)
- GCC 4.9.2 (angrboda)
- Intel 13.0.1 composer_xe_2013.1.117 (borr)
- Intel 14.0.2 composer_xe_2013_sp1.2.144 (bestla)
- PGI 14.7 (bronze)
- NAG 6.0 (borr)
- Sun Studio 12 (bestla)
- G95 0.93 (byleistr)
An overview of where you can find Fortran documentation for a variety of compilers:
- GNU Fortran Compiler 4.4.7
- GNU Fortran Compiler 4.8.3
- GNU Fortran Compiler 4.9.2
- Intel Fortran Compiler 14
- Intel Fortran Compiler 14
- Intel Fortran Compiler 15
- NAG Fortran Compiler 5.2
- NAG Fortran Compiler 5.3
- NAG Fortran Compiler 6.0
- PGI Fortran Compiler (PDF)
- XL Fortran for Linux
Deleted and obsolescent features
As the Fortran standards progress, certain features are marked as deleted. Some features that might be deleted in the future are marked as obsolescent. You should avoid any of these when writing new source code. The previous links give you an overview of all deleted/obsolescent features, here we only list the most relevant:
dotermination, use multiple
- statement functions, use procedures instead (should get inlined anyway)
Fixed source form is also marked as obsolescent, but might still be required to be able to include Fortran header files (as these are in fixed source form in Molcas, see section on Source code layout).
Source code layout
Molcas uses the following convention for Fortran source code:
- file extension
.fmeans the file contains fixed format source code
- file extension
.f90means the file contains free-form source code (not that it is Fortran 90!!)
We do not use
.F90, as all Fortran source is preprocessed by default.
In principle, you are free to choose which format you adhere to, but there is an important catch. As Molcas was originally all fixed format, all header files are fixed format. This can create problems if you include such header files in free-form source code. So, the advice is to stick to fixed format source code for interoperability reasons, and you have to provide Fortran header files (
.fh) in fixed format source form.
!!!WARNING!!! -- Only use Fortran modules locally within a program or utility subdirectory -- !!!WARNING!!!
Molcas supports the use of Fortran modules, but there is again an important catch. You should not expect modules to work across utilities or programs. The reason is that if you want to use a module from outside the current subdirectory, the module should have been created first. This needs a specification of explicit dependencies between utilities and this is not available in Molcas. All utilities should be able to compile independently. Therefore, modules should only be used locally within a utility or program subdirectory, where the dependencies are explicitly created between the source files.
With the traditional build system, one could in principle use modules from utilities in programs, as the former are created first before any program is compiled. This is tricky however, since someone could inadvertently use the module in another utility, and the dependency problem might go unnoticed depending on the order in which the utilities are compiled. Furthermore, this would not work with the current CMake implementation, as in that case programs are also compiled separately from utilities, with the only dependency on utilities being a link-time dependency.
Note that the dependency resolver is relatively simple, so please use one module per file as a general guideline.
Supported by memory manager
There are several ways to allocate memory in Fortran, but we only support certain wrappers because we need to keep track of available/used memory in Molcas. The most common way in Molcas was to use
getmem, but recently we added the
mma_deallocate wrappers around the standard Fortran allocate functionality. The advantage of the latter is that it avoids use of the Work array, ultimately allowing for e.g. bounds checking on arrays. If you do not know which to use, please use the second method.
getmem The standard way to allocate memory is to use the
getmem subroutine, which returns an index that can be used with the
Work array. Usage is tracked by the memory manager. For this routine you need to include the
include 'WrkSpc.inc' integer laddr, nsize nsize = ... call getmem('name','allo','real',laddr,nsize) work(laddr) ... work(laddr+nsize-1) call mysub(work(laddr),...) call getmem('name','free','real',laddr,nsize)
stdalloc A set of wrappers
mma_deallocate that use the standard Fortran allocate functionality. The wrappers check against the available Molcas memory and register the allocated memory with the memory manager. For these routines to work you need to include the
include 'stdalloc.inc' integer :: m, n real*8, allocatable :: buffer(:,:) m = ... n = ... call mma_allocate(buffer,m,n) buffer(1,1) ... buffer(m,n) call mysub(buffer,...) call mma_deallocate(buffer)
Failing to release memory with
mma_deallocate will result in the memory manager aborting at the end of a program run.
Not supported by memory manager
The following ways of allocating memory are supported by the compilers on the certified test platform, but should not be used since they bypass the Molcas memory management, resulting in unpredictable behaviour when the system runs low on memory. Use
getmem or the
mma_deallocate wrappers provided by the
stdalloc.inc header instead.
allocate/deallocate This is the standard way of dealing with dynamic memory allocation since Fortran 90. However, this will obscure the amount of memory used from the memory manager in Molcas. The wrappers from
stdalloc.inc accomplish exactly the same thing, but register the memory used this way with the memory manager.
automatic arrays These are local arrays where the dimensions are variables and are allocated automatically. They usually go onto the stack (depending on size, compiler options). Their usage will also circumvent the memory manager and can also cause other problems if they are large (e.g. stack overflow). You should absolutely avoid using this, except maybe for really small arrays (but in that case you can probably also use fixed-size arrays).
So, do NOT use things like the following (
auto is an automatic array of size
subroutine my_sub(dummy1,dummy2,m,n) implicit none real*8 dummy1(m),dummy2(n) real*8 auto(m,n) ... end subroutine
temporary arrays These are arrays that can be created when passing slices of arrays to subroutines. The compiler then needs to copy the data to a temporary contiguous storage. This can impact performance a lot. Therefore, you should avoid using any kind of array slicing.
The following example shows a problematic code where a non-contiguous array is passed to a subroutine where the array is contiguous, in which case a temporary copy will be created:
... call my_sub(array(1:m:2,1:n:4)) ... subroutine my_sub(array) real*8 array(*) ... end subroutine