I am using IMSL with Intel Virtual Fortran with MKL. I tried to use a routine from IMSL. It was compiled fine, but when I try to execute the file it came up with an error saying:
MKL ERROR: Parameter 7 was incorrect on entry to SGEEVX
*** TERMINAL ERROR 2 from EVCRG. The required storage cannot be allocated.
*** The specified N may be too large, where N = 1064682127.
The following is the code I am using:
PROGRAM test_evcrg
include 'link_fnl_static.h'
!DEC$ OBJCOMMENT lib:'libiomp5mt.lib'
IMPLICIT NONE
REAL, Dimension(2,2) :: p,vr
REAL, Dimension(2) :: w
p = RESHAPE([0.7, 0.3, 0.5,0.5],[2,2])
CALL EVCRG (p,w,vr)
WRITE (*,*), w
WRITE (*,*)
WRITE (*,*), vr
END PROGRAM test_evcrg
How can I fix this problem?
AFTER I ADDED
USE EVCRG_INT
IT GIVES THE ERROR INFOMATION:
test_evcrg.f90(14): error #6285: There is no matching specific subroutine for this generic subroutine call. [EVCRG]
CALL EVCRG(p,w,vr)
---------^
compilation aborted for test_evcrg.f90 (code 1)
THANKS.
In the IMSL USER'S GUIDE, it says:
FORTRAN 90 Interface
Generic: CALL EVCRG (A, EVAL, EVEC [,…])
Specific: The specific interface names are S_EVCRG and D_EVCRG.
I don't know IMSL enough, but I think there is a mismatch of interfaces. Because you do not use any IMSL module, you are not using the Fortran 90 interface, but the Fortran 77 interface, which requires more arguments. See IMSL manual. Either use the module, or change the call to something like CALL EVCRG (2, p, 2,w, vr, 2).
The use statement you can use is probably USE numerical_libraries.
---- EDIT ----
It means, that adding the use was the good thing. Now it exposes, that there really was an error in the call. The arguments are wrong. Arguments 2 and 3, i.e. EVAL and EVEC must be COMPLEX!
Related
I am connecting a purely-F90 cosmological library to a python code in order to make some plots by writing interconnection functions in F90, which uses several functions in the library mentioned above by, e.g.,
USE cosmology_functions
where cosmology_functions is a module including some functions with underscores like 'init_cosmology'. I successfully compiled this interconnection but when I try to import it within my python script I found this issue:
ImportError: $PATH$/Interconnection.cpython-38-x86_64-linux-gnu.so: undefined symbol: __cosmology_functions_MOD_init_cosmology
What is weird that several functions are called before 'init_cosmology' and I received no error reported. So I doubted whether the function itself has caused the error is used with f2py. The input and output of this function is simply like:
subroutine init_cosmology(cosm)
TYPE(cosmology), INTENT(INOUT) :: cosm
where parameters are added to cosm inside this function, makes the input dimension and output dimension different with each other. Is this an intrinsic issue of f2py? Or have I made a wrong guess?
The compiler is GNU fortran 9.3.0 and the python version is 3.8.5.
Many Thanks in advance.
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...)
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.
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
Well, this is the issue I've today...
I'm writing a module procedure that has, as an argument, a function. This module looks something like this:
module Integ
implicit none
<variables declaration>
contains
function Integral(a,b,f) result(res)
real, intent(in) ::a, b
real ::res
interface
pure function f(x)
real, intent(in) :: x
real :: f
endfunction
endinterface
<more code of function Integral>
endfunction Integral
endmodule Integ
Well, up to here, everything is great. The issue appears when I try to use this function with a Fortran intrinsic function. I.e., in this code:
program main
use Integ
implicit none
real ::res,a,b
a=3.0; b=4.0
res=Integral(a,b,sin) !<- This line does not work
!res=Integral(a,b,sen) !<- This line does work
contains
function sen(x)
real, intent(in) :: x
real :: sen
sen=sin(x)
endfunction
endprogram
The first line does not work, giving the error message:
main.f90(17): error #6404: This name does not have a type, and must have an explicit type. [SIN]
r=Int1DMonteCarlo(0.0,1.0,sin,10000)
--------------------------^
main.f90(17): error #6637: This actual argument must be the name of an external user function or the name of an intrinsic function. [SIN]
r=Int1DMonteCarlo(0.0,1.0,sin,10000)
--------------------------^
But the second line (comented in the snipplet) does.
Those errors are quite disorienting for me, because sin is a Fortran intrinsic function (thing that contradicts error nr 2), and in consequence explicit in every scope (thing that contradicts the error nr 1).
Obviously I'm doing something wrong but I don't know what.
So I would like to ask:
It is possible to call a module procedure with an intrinsic function as an actual argument?
I'm loosing something aside from declaring the interface inside the procedure?
If you are interested this is the complete source of the module and this is the source of the main
Sorry if I'm asking a stupid question. I think I am doing things the way the books I'm reading now (Metcalf, Numerical recipes for Fortran V:II) are telling me.
Thank you for your time!
Use an intrinsic statement in the main program to declare that the actual argument sin is the intrinsic. This requirement is spelled out in the description of the intrinsic attribute in the Fortran standard.
With an eye to the future, you may be better off writing your own wrapper function around the intrinsic - create a function mysin that simply calls sin.