I have an existing Fortran code using MPI for parallel work.
I am interested in adding some of the PETSc solvers (KSP specifically), however when including the relevant .h or .h90 files (petsc, petscsys, petscksp, etc...) I get a problem with variables that share the same name as the MPI ones.
i.e.:
error #6405: The same named entity from different modules and/or program units cannot be referenced. [MPI_DOUBLE_PRECISION]
error #6405: The same named entity from different modules and/or program units cannot be referenced. [MPI_SUM]
error #6405: The same named entity from different modules and/or program units cannot be referenced. [MPI_COMM_WORLD]
and so on.
(using ics/composer_xe_2011_sp1.6.233 and ics/impi/4.0.3.008 and petsc 3.6.0, also tried older petsc version 3.5.4)
All of these are defined equally in both MPI and PETSc - is there a way to resolve this conflict and use both?
I'll point out that I DO NOT WANT to replace MPI calls with PETSc calls, as the code should have an option to run independent of PETSc.
As for minimal code, cleaning up the huge code is an issue apparently, so I've made the following simple example which includes the relevant parts:
program mpitest
implicit none
use mpi
! Try any of the following:
!!!#include "petsc.h"
!!!#include "petsc.h90"
!!!#include "petscsys.h"
! etc'
integer :: ierr, error
integer :: ni=256, nj=192, nk=256
integer :: i,j,k
real, allocatable :: phi(:,:,:)
integer :: mp_rank, mp_size
real :: sum_phi,max_div,max_div_final,sum_div_final,sum_div
call mpi_init(ierr)
call mpi_comm_rank(mpi_comm_world,mp_rank,ierr)
call mpi_comm_size(mpi_comm_world,mp_size,ierr)
allocate(phi(nj,nk,0:ni/mp_size+1))
sum_phi = 0.0
do i=1,ni/mp_size
do k=1,nk
do j=1,nj
sum_phi = sum_phi + phi(j,k,i)
enddo
enddo
enddo
sum_phi = sum_phi / real(ni/mp_size*nk*nj)
call mpi_allreduce(sum_div,sum_div_final,1,mpi_double_precision,mpi_sum, &
mpi_comm_world,ierr)
call mpi_allreduce(max_div,max_div_final,1,mpi_double_precision,mpi_max, &
mpi_comm_world,ierr)
call mpi_finalize(error)
deallocate(phi)
WRITE(*,*) 'Done'
end program mpitest
This happens directly when PETSc headers are included and vanishes when the include is removed.
Alright, so the answer has been found:
PETSc does not favor Fortran much and, therefore, does not function the same way as it does with C/C++ and uses different definitions.
For C/C++ one would use the headers in /include/petscXXX.h and everything will be fine, moreover the hierarchical structure already includes dependent .h files (i.e. including petscksp.h will include petscsys.h, petscvec.h and so on).
NOT IN FORTRAN.
First and foremost,for FORTRAN one needs to include headers in /include/petsc/finclude/petscXXXdef.h (or .h90 if PETSc is compiles with that flag). Note that the files are located in a different include folder and are petscxxxdef.h.
Then 'use petscXXX' will work along with MPI without conflicting.
Related
I have a large source code where subroutines in modules are defined outside the module ... end module statement (ie. not inside a contains statement). I've included a simplified module below:
module core
implicit none
type :: disc_status
sequence
real*8 :: alpha1, alpha2, alpha3
end type disc_status
end module core
subroutine tester(input)
use core
type(disc_status), intent(in) :: input
print *, input%alpha1, input%alpha2, input%alpha3
end subroutine tester
Here's an example program using the module and subroutine:
program flyingDiscSimulator
use core
implicit none
type(disc_status) :: disc
disc%alpha1 = 1.1D0
disc%alpha2 = 1.2D0
disc%alpha3 = 1.3D0
call tester(disc)
print *, 'it works'
end program flyingDiscSimulator
Normally, I end up seeing subroutines use the contains statement within a module:
module core
implicit none
type :: disc_status
sequence
real*8 :: alpha1, alpha2, alpha3
end type disc_status
contains
subroutine tester(input)
type(disc_status), intent(in) :: input
print *, input%alpha1, input%alpha2, input%alpha3
end subroutine tester
end module core
However, the program file referenced above doesn't require any changes to use either way of including a subroutine in a module (using gfortran anyways). Thus, there appears to be no difference in the usage of the module or it's subroutine between the two solutions. Are there any "under the hood" differences between the two styles?
The versions
module m
contains
subroutine s()
end subroutine s
end module m
and
module m
end module m
subroutine s()
end subroutine s
say completely different things, but in the case of the question the end results are much the same.
The first version here creates a module procedure s with host m; the second version has an external procedure s with no host.
Although the example of the question has the external procedure using the module, there is more generally a difference: the module procedure has access to all entities in the module (except when made inaccessible through an import statement or by being obscured by local names; the external procedure using the module has access only to those public entities.
However, come the main program the effects are different. The external subroutine and its name are global entities. Going to my second version, then
program main
call s
end program
is a valid program which calls the external subroutine s. This subroutine reference is valid because the implicit interface for s in the main program suffices. If the external subroutine s were such than an explicit interface were required then main program here would not be allowed. It is acceptable, but not required, to have an external s statement in the main program to reinforce to the reader that the subroutine is an external one (with implicit interface). (implicit none external would make external s necessary.)
The example of the question is such that an explicit interface is not required.
A module procedure always has an explicit interface available when accessible. However, a module procedure is not a global entity and its name is not a global identifier.
Under the hood, there are implementation differences (stemming from the above): most notably compilers will often "name mangle" module procedures.
In summary, there are differences between the two approaches of the question, but they won't be noticed by the programmer in this case.
The procedure inside the module will have an explicit interface (aka the compiler knows about the arguments' characteristics).
Whereas the procedure outside of the module will have an implicit interface (aka the compiler must make assumptions about the arguments).
Explicit interfaces help the compiler to find programming errors and are therefore favourable.
For a more indepth discussion of advantages see for example this answer.
I am not even sure if it is valid Fortran to call tester inside the program when it is defined outside of core?
The line use core should just make the module's public objects known and the tester procedure needs its own external tester line.
I'm trying to teach myself Fortran, and have been messing around with linking multiple files together. Following examples, I have been writing programs in one file, functions in another, and using interface blocks in my main program to refer to the external function.
I was testing how much information was needed in the interface block and realised that I can remove it entirely.
My program:
program test
implicit none
real :: x, y, func
x = 3
y = func(x)
print *, y
end program test
And the function file:
function func(x)
implicit none
real :: x, func
func = x**3
end function func
I then compile it using gfortran -o test test.f90 func.f90 and the code works as expected. My question is, why do I not need to include an interface block in my program file? Is it simply a matter of good practice, or does defining func as a real variable serve as shorthand? I am on Windows, having installed gfortran through minGW.
As an aside/related question, if I instead use a subroutine:
subroutine func(x,y)
implicit none
real :: x,y
y = x**3
end subroutine func
And change the line y = func(x) to call func(x,y) then the code will work fine without any interface block or declaration. Why is this?
The declaration real :: func in the main program here declares func to be a function with (default) real result. This function has an interface in the main program as a result, so it is legitimate to reference that function with y = func(x).
The interface in this case is implicit. In this way, the main program knows exactly three things about func:
it is a function (with that name);
it has the external attribute;
it has real result.
The reference to the function is compatible with that knowledge. Further, how you reference the function matches precisely the properties of the function itself.
Equally, in the case of the subroutine, a call func(x,y) tells the main program exactly three things, again with the implicit interface:
it is a subroutine (with that name);
it has the external attribute;
it takes two real arguments.
Those three things again match the subroutine's definition, so things are fine.
Loosely, then, you don't need an interface block in these cases because the implicit interfaces are good enough.
There are times when an explicit interface is required and in most (nearly all) cases an explicit interface is better. As you can see in other questions and answers, there are usually better ways to provide an explicit interface than using an interface block.
Why do I not need to include an interface block in my program file?
Since Fortran 90, the recommended way to define reusable functions and subroutines is to use modules.
module func_m
contains
function func(x)
implicit none
real :: x, func
func = x**3
end function func
end module func_m
Then write use func_m in the main program, before implicit none: gfortran -c func_m.f90, gfortran -c test.f90 and gfortran -o test test.o func_m.o.
When you use modules, the compiler will check the type of the arguments of the functions. You also do not need to declare real :: func as the declarations are taken from the module.
When you compile as a "simple" object file, the compiler will simply call whatever function is named func without verification, as long as such a function is given in an object file.
The interface block is a kind of "in between". In your case, you could add one in the program file. This would force you to follow that declaration in the program. But it will not prevent linking to wrong functions at link time: there is no guarantee that the interface is right. It is mostly useful if you need to call C or FORTRAN 77 code from someone else, for which you couldn't use modules.
And change the line y = func(x) to call func(x,y) then the code will
work fine without any interface block or declaration. Why is this?
The interface issue is orthogonal to the function vs subroutine issue.
There are some cases where interface blocks are needed. For example if the called subroutine uses a pointer, allocatable or assumed shape arrays (this list is not complete, see the standard for more):
integer, pointer :: x(:,:) ! pointer attribute
integer, allocatable :: x(:,:) ! pointer attribute
integer :: a(:,:) ! assumed shape array
The pointer/allocatable have the advantage that the called subroutine can allocate it for the calling function. Assumed shape arrays automatically transfer the dimensions to the called subroutine.
If you use any of this your program will crash without explicit interface. Easiest solution is like said in the other answer: use modules to have the interface automtically correct. We use a perl script automatically extracting interfaces to have interface check without rewriting the code to modules (and avoid long compile times until all compilers reliably support Fortran 2008 submodules...)
My understanding of programming is very limited so I hope I am making sense.
I made a change to a fixed variable in a program (the program is called NAFnoise; I was using the .exe but it came with the source code and I made the change there). The program is written in Fortran and is in multiple files. I am using gfortran to compile it and most of the files works without a problem. One file, however, is giving me trouble. And I didn't even make changes to it. It is giving error messages that is like this:
error: 'x' argument pf 'dtime' intrinsic at <1> must be of kind 4
The same message appears for etime. The only times those (I am guessing they are) functions and variables inside them are referenced as shown below:
IMPLICIT NONE
! Local variables.
INTEGER(4) :: klo,khi,i,n_in,nvar,nj,j1,j2,ivar,nok,nbad
REAL(DbKi) :: kk2, Isumwell, Isum, Itot,eps,h1,hmin
REAL(DbKi) :: ys1,ys2,poverall,phipot
REAL(DbKi) :: bigben(2),bigben2(2),dtime,etime
REAL(DbKi) :: phif(10)
COMPLEX(DbKi) :: value,dval1,dval2,dval11,dval12,dval22
COMPLEX(DbKi) :: btrans,btrans1,btrans2,btrans11,btrans12,btrans22
COMPLEX(DbKi) :: bbb,bbb1,bbb2
and
write(*,*) etime(bigben2),dtime(bigben)
and
write(*,*) etime(bigben2),dtime(bigben)
I am guessing the program was found when the author included it in the source folder, so I am not sure what went wrong. The variable I change should have nothing to do with this. Does it have something to do with the compiler? How can it be fixed?
DTIME is a non-standard GNU function described in the manual https://gcc.gnu.org/onlinedocs/gfortran/DTIME.html. It requires an argument to be of kind 4. That is the single precision under the default settingd for gfortran.
Probably, DbKi means double precision instead for you. Change
REAL(DbKi) :: bigben(2),bigben2(2),dtime,etime
to
REAL :: bigben(2),bigben2(2)
(or real(4)) if you use the GNU intrinsic extension.
If you actually want to call some your own external dtime, you must declare an interface block for it.
The same holds for etime from https://gcc.gnu.org/onlinedocs/gfortran/ETIME.html
Is it possible in modern versions of Fortran to pass a kind parameter to a subprogram and to use this to 'cast' variables to this kind? As an example, in the following code I am trying to convert an default integer to an 16-bit integer before printing it.
program mwe
! Could use iso_fortran_env definition of int16, but I am stuck with
! old versions of ifort and gfortran.
! use, intrinsic :: iso_fortran_env, only : int16
implicit none
! 16-bit (short) integer kind.
integer, parameter :: int16 = selected_int_kind(15)
call convert_print(123, int16)
contains
subroutine convert_print(i, ikind)
implicit none
integer, intent(in) :: i
integer, intent(in) :: ikind
print*, int(i, ikind)
end subroutine convert_print
end program mwe
With this example code the Intel Fortran compiler complains that
mwe.f(24): error #6238: An integer constant expression is required in this context. [IKIND]
...
mwe.f(24): error #6683: A kind type parameter must be a compile-time constant [IKIND]
and gfortran complains
'kind' argument of 'int' intrinsic at (1) must be a constant
Using print*, int(i, int16) in place of print*, int(i, ikind) would of course work fine in this case. However, if convert_print were defined in a a module which does not define int16 then this would be useless.
Is there a way of passing a kind parameter as a constant to subprograms?
I have the same problem. I find extremely inconvenient that it is not allowed to pass the kind datatype as an argument to a procedures. In my case, I am writing write a subroutine to just read a matrix from a file and get the object in the data type that I want to. I had to write four different subroutines: ReadMatrix_int8(…), ReadMatrix_int16(…), ReadMatrix_int32(…) and ReadMatrix_int64(…) which are nothing but the same code with one single line different:
integer(kind=xxxx), allocatable, intent(out) :: matrix(:,:)
It would make sense to write only one subroutine and pass xxxx as an argument. If I find any solution I will let you know. But I am afraid that there is no better solution than writing the four subroutines and then writing an interface to create a generic procedure like:
interface ReadMatrix
module procedure ReadMatrix_int8
module procedure ReadMatrix_int16
module procedure ReadMatrix_int32
module procedure ReadMatrix_int64
end interface
As far as I can work out, what I am trying to do is expressly forbidden by the Fortran 2003 standard (PDF, 4.5 MB):
5.1.2.10 PARAMETER attribute
A named constant shall not be referenced unless it has been defined previously in the same statement, defined in a prior statement, or made accessible by use or host association.
Therefore is seems that I need to define a function for each conversion I wish to do, for example:
subroutine print_byte(i)
implicit none
integer, intent(in) :: i
print*, int(i, int8)
end subroutine print_byte
subroutine print_short(i)
implicit none
integer, intent(in) :: i
print*, int(i, int16)
end subroutine print_short
subroutine print_long(i)
implicit none
integer, intent(in) :: i
print*, int(i, int32)
end subroutine print_long
Obviously all of the above will have to be overloaded to accept different kinds of the input argument. This seems like a lot of work to get around not being able to pass a constant, so if someone has a better solution I am keen to see it.
This Intel expert gives an explanation and an elegant solution. I couldn't explain it better. A full cite follows:
"One day while I was wandering the aisles of my local grocery store, a woman beckoned me over to a table and asked if I would like to "try some imported chocolate?" Neatly arrayed on the table were packages of Lindt, Toblerone, and... Ghiradelli? I asked the woman if California had seceded from the Union, as Ghiradelli, despite its Italian name, hails from San Francisco. I suppose that from the vantage point of New Hampshire, California might as well be another country, much as depicted in that famous Saul Steinberg 1976 cover for The New Yorker, "View of the World from 9th Avenue".
(I've been warned that my blogs don't have enough arbitrary links - this should hold 'em for a while.)
Similarly, in Fortran (I'll bet you were wondering when I'd get to that), something can be so near yet seem so far away. A short time ago, I was writing a new module for Intel Visual Fortran to provide declarations for the Win32 Process Status API. This would contain declarations of types and constants as well as interface blocks for the API routines, some of which take arguments of the new type. The natural inclination is to write something like this:
MODULE psapi
TYPE sometype
some component
END TYPE sometype
INTERFACE
FUNCTION newroutine (arg)
INTEGER :: newroutine
TYPE (sometype) :: arg
END FUNCTION newroutine
END INTERFACE
END MODULE psapi
If you did and compiled it, you'd get an error that type sometype is undefined in the declaration of arg. "What? It's not undeclared, I can see it right above in the same module!" Well, yes and no. Yes, it's declared in the module and could be used anywhere in the module, except.. Except in interface blocks!
The problem is that interface blocks are a "window into the external routine" - they essentially duplicate the declarations you would see in the actual external routine, assuming that routine were written in Fortran. As such, they do not "host associate" any symbols from the enclosing scoping unit (the module in this case.)
In Fortran 90 and Fortran 95, the typical solution for this was to create a separate module, say, "psapi_types", containing all of the types and constants to be used, You'd then add a USE statement inside each function, just as you would have to in the hypothetical external routine written in Fortran. (If it were written in Fortran, the Doctor would slap your wrist with a wet punchcard and tell you to make the routine a module procedure, and then you wouldn't need to worry about this nonsense.) So you would end up with something like this:
MODULE psapi
USE psapi_types ! This is for the benefit of users of module psapi
INTERFACE
FUNCTION newroutine (arg)
USE psapi_types
INTEGER :: newroutine
TYPE (sometype) :: arg
...
Those of you who use Intel Visual Fortran know that in fact there's a giant module IFWINTY for this purpose, containing all of the types and constants for the other Win32 APIs. It's messy and inelegant, but that's what you have to do. Until now...
Fortran 2003 attempts to restore some elegance to this sorry situation, but to preserve compatibility with older sources, it couldn't just declare that interface blocks participate in host association. Instead, a new statement was created, IMPORT. IMPORT is allowed to appear in interface blocks only and it tells the compiler to import names visible in the host scope.
IMPORT is placed following any USE statements but before any IMPLICIT statements in an interface body (the FUNCTION or SUBROUTINE declaration). IMPORT can have an optional import-name-list, much like USE. Without one, all entities accessible in the host become visible inside the interface body. With a list, only the named entities are visible.
With IMPORT, my PSAPI module can look like the first example with the following change:
...
FUNCTION newroutine (arg)
IMPORT
INTEGER :: newroutine
TYPE(sometype) :: arg
...
I could, if I wanted to, use:
IMPORT :: sometype
to say that I wanted only that one name imported. Nice and neat and all in one module!
"But why are you telling me this?", you might ask, "That's a Fortran 2003 feature and Intel Fortran doesn't yet do all of Fortran 2003." True enough, but we keep adding more and more F2003 features to the compiler and IMPORT made it in back in August! So if you are keeping reasonbly current, you can now IMPORT to your heart's content and do away with the mess of a separate module for your types and constants.
If you want to know what other F2003 goodies are available to you, just check the Release Notes for each update. A full list of supported F2003 features is in each issue. Collect 'em all!"
can I declare intent variable in fortran module?
I want to make common module which can be called other subroutine
module fmod
real b
integer n, i
integer, dimension(6), intent(inout) :: indata1
real, dimension(7,8), intent(inout) :: indata2
end module fmod
subroutine temp_f(indata1, indata2)
use fmod
do i=1,8
print *, indata4(i)
end do
end
No, intent is for subroutine arguments, not module variables. Module variables are normally available to any entity that "use"s them. You can declare them to be "private" which will block their visibility outside of the module. Perhaps you are thinking of a module as an include file, which copies source code lines for compilation where they are copied. That is not the concept of a module ... it is an independent source code entity.
Although it is outside of the language standard, many Fortran compilers support the use of include files via "#include" starting in the first column. With some compilers use a filetype "F90" (upper-case). With others you have to use a compiler option to run the C-style pre-processor. There is a small risk that this usage will make your code less portable.