英特尔Fortran到GNU Fortran的转换 [英] Intel Fortran to GNU Fortran Conversion

问题描述

我正在研究用Fortran 90和MPI编写的自定义CFD求解器.该代码包含15个以上的模块，最初设计为与Intel Fortran编译器一起使用.现在，由于我无权访问Intel编译器，因此需要使用GNU Fortran编译器使其工作.

I am working on a custom CFD Solver written in Fortran 90 and MPI. The code contain 15+ Modules and was initially designed to work with the Intel Fortran compiler. Now since i do not have access to the Intel compiler I need to make it work using the GNU Fortran Compiler.

我在Makefile中进行了更改，这些更改最初具有适用于ifort的标志.我在带有GNU Fortran和Openmpi的Ubuntu上使用它

I made changes in the Makefile that initially had flags suitable for the ifort. I am using it on Ubuntu with GNU Fortran and Openmpi

很抱歉，由于我所在大学的IP限制，我无法从代码结构或终端输出中输入任何内容.尽管如此，我会尽力描述问题

所以现在当我编译代码时，我遇到了一些奇怪的问题.

So now when I compile the code I am having some strange issues.

1. GNU Fortran无法读取过长的行，并且在编译过程中出现错误.结果，我必须使用&"将其分成多行符号

1. The GNU Fortran is not able to read lines that are too long and I get errors during compilation. As a result I have to break it into multiple lines using the '&' symbol

模块D.f90包含所有声明的全局变量.但是，现在我在编译过程中在模块B.F90中遇到错误.我得到的错误是未分类的语句错误"，通过再次在本地声明变量，我可以在某些子例程和函数中对其进行修复.

A module D.f90 contains all the Global variables declared. However, now I during compilation i get error is in module B.F90. The error I get is 'Unclassified Statement Error', I was able to fix it in some subroutines and functions by locally declaring the variables again.

我不是Fortran中经验最丰富的人，但是我认为编译器的更改不应成为新发现语法错误的原因.

I am not the most experienced person in Fortran, but I thought that the change in compiler should not be a reason for new found syntax errors.

到目前为止，可以纠正上述错误，但是考虑到代码的广泛扩展，这是不切实际的.

The errors described above so far could be remedied but considering the expanse of the code it is impractical.

我希望有人能就此事发表意见并提供如何解决的指导.

I was hoping if anyone could share views on this matter and provide guidance on how to tackle it.

推荐答案

您应该开始阅读三篇文档:

You should start reading three pieces of documentation:

• Fortran 90标准(或者，其他版本)，它告诉您什么是合法的，标准的Fortran，什么不是合法的.每当发现错误时，请查看您的代码，并检查您所执行的操作是否合法，标准的Fortran.有可能的是，所讨论的代码要么完全是非标准的(例如 REAL * 8 ，尽管该扩展名已被很好地理解)，要么依赖于Intel Fortran和GFortran以不同方式解释的未指定行为.
• 您所用版本的 GFortran手册，它告诉您GFortran如何确定此类未说明的情况，哪些内在函数可用，如何更改某些选项/标志等.这将告诉您，通过添加 -ffree-line-length-none 可以解决行长​​的问题.
• 适用于您的版本的Intel Fortran手册，在出现非标准或未指定行为的情况下，可让您知道正在编写的代码是做什么的，例如您期望的行为.特别是，它将允许您解释当前正在使用的编译器标志的含义.他们可能需要翻译为GFortran，也可能不需要，例如/Qsave 将需要变为 -f-no-automatic .

• The Fortran 90 standard (alternatively, other versions), which tells you what is legal, standard Fortran and what is not. Whenever you find some error, look at your code and check if what you are doing is legal, standard Fortran. Likely, the code in question will either be completely nonstandard (e.g. REAL*8, although that extension is fairly well understood) or rely on unspecified behaviour that Intel Fortran and GFortran are interpreting in different ways.
• The GFortran manual for your version, which tells you how GFortran decides such unspecified cases, what intrinsic functions are available, how to change some options/flags, etc. This would tell you that your problem with the line lengths would be solved by adding -ffree-line-length-none.
• The Intel Fortran manual for your version, which in cases of non-standard or unspecified behaviour, will allow you to know what the code you are reading was written to do, e.g. the behaviour that you would expect. In particular, it will allow you to decipher what the compiler flags that are currently being used mean. They may or may not need translation to GFortran, e.g. /Qsave will need to become -f-no-automatic.

允许的范围内解释差异的具体示例为标准:在Fortran 2003之前，未指定随机访问记录文件中记录长度"的单位.英特尔Fortran使用一个机器字"(x86中为4个字节)，而GFortran使用了1个字节.两者都符合标准字母，但不兼容.

A concrete example of interpretative differences within the range allowed be the standard: until Fortran 2003, the units for the "record length" in random access record files were left unspecified. Intel Fortran used "one machine word" (4 bytes in x86) while GFortran used 1 byte. Both were compliant with the standard letter, but incompatible.

此外，即使编译器按标准"编码，如果编译器未实现Fnn标准的一部分或存在错误，也可能会遇到麻烦.恰当的例子:Intel Fortran 12.0(旧的，但我使用的是它)没有实现多态的 x 的 ALLOCATE(y，SOURCE = x)构造(克隆分配").另一方面，GFortran尚未完全实现 FINAL 类型绑定过程(析构函数).

Furthermore, even when coding "to standard", you may hit a wall if the compiler does not implement part of the Fnn standard, or it is buggy. Case in point: Intel Fortran 12.0 (old, but it's what I work with) does not the implement the ALLOCATE(y, SOURCE=x) construct for polymorphic x (the "clone allocation"). On the other hand, GFortran has not completely implemented FINAL type-bound procedures (destructors).

在两种情况下，您都需要找到解决方法.例如，对于第一个问题，您可以使用INQUIRE语句的特殊形式(@haraldkl的别名).在其他情况下，解决方法甚至可能涉及使用某种功能检测(请参见autoconf，CMake等)，并将结果作为 PARAMETER 变量存储在 config.f90 中您的代码中包含的文件.然后，您的代码将基于该代码做出决策，如:

In both cases, you will need to find workarounds. For example, for the first issue you can use a special form of the INQUIRE statement (kudos to @haraldkl). In other cases, the workaround might even involve using some kind of feature detection (see autoconf, CMake, etc.) and storing the results as PARAMETER variables in a config.f90 file that is included by your code. Your code would then take decisions based on it, as in:

! config.f90.in (things in @x@ would get subtituted by automake, for example)
INTEGER, PARAMETER :: RECORD_LEN_BYTES = @RECORD_LEN_BYTES@

! Some other file which opens a file
INCLUDE "config.f90"
!...
OPEN(u, FILE='DE430.BIN', ACCESS='direct', FORM='unformatted', RECL=56 / RECORD_LEN_BYTES)

这篇关于英特尔Fortran到GNU Fortran的转换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！