I stumbled with a way to run in a child module a procedure of the father. I mean, the trick allow me to run a process in a upstream way, in relation with the dependencies tree of the modules. In concrete, here is the example:
module parent
procedure(likefoo),pointer :: to_foo
interface
subroutine likefoo
end subroutine likefoo
end interface
contains
subroutine run
call to_foo
end subroutine
end module
module child
use parent
contains
subroutine foo
print *, 'hola'
end subroutine foo
end module
program main
use parent
use child
to_foo => foo
call run
end program
This example was positive tested with ifort 13.0.0.
I wonder, This code is allowed by the standard or just it run ok because is a compiler dependence feature?.
Thanks for your help.
The approach is fine (using F2003 features), but make the interface for likefoo abstract. The requirement for a directed graph of module dependence is an orthogonal concept to the nesting of calls to procedures in those modules.
Related
Is it possible to have fortran execute code upon startup, without explicitly putting it into the main program?
Usecase
Consider e.g. a routine that reads data from a configuration file with keyword-value pairs, which is used in different modules.
For the sake of code locality it would be favorable for valid keywords, as well as error handling for invalid values, to be defined in the module that needs the data.
Right now the only pattern to implement such behaviour, that I can think of, would be writing a setup subroutine in said module, which is called by the main program.
This means that changing the logic of a module may require a change of the main program. This seems harder to maintain than e.g. in Python doing something like
# ------ ./project/module.py ------
from project.config import register_keyword
register_keyword("some_setting")
One way to do this would be to use derived type constructors:
module foo
implicit none
! only export the derived type, and not any of the
! helper procedures
private
public :: mytype
type :: mytype
! internals of type
end type
! Write an interface overloading 'mytype' allows us to
! overload the type constructor
interface mytype
procedure :: new_mytype
end interface mytype
contains
type(mytype) function new_mytype(setting)
! Some generic setting type
type(setting_type), intent(in) :: setting
! do something with setting
...
end function new_mytype
end module foo
program bar
use foo
implicit none
type(mytype) :: thing
type(setting_type) :: setting
! calls 'foo::new_mytype'
! all implementation details hidden away
thing = mytype(setting)
end program bar
As far as I've seen, this is not possible according to the Fortran (2003) standard.
A "static" function call like your register_keyword would have to be done in the specification-part of a module definition. By general definition this specification-part could contain a stmt-function-stmt, but this is then explicitly forbidden in C1105: "... shall not contain stmt-function-stmt, [...]". So you are basically left with calling intrinsic functions only.
If you really do not want to edit your main program, but you are fine with an additional C++ intermediate file, then the following PoC works:
prog.f03:
program main
end program
my_module.f03:
module my_mod
use, intrinsic :: iso_c_binding
contains
function foo() bind(C, name="foo")
integer(c_int) :: foo
write (*,*) "hello, world!"
foo = 10
end function
end module
my_module.cc:
extern "C" int foo();
int a = foo();
Compile and link as follows:
g++ -Wall -c my_module.cc -o my_module.o
gfortran -Wall -o prog prog.f03 my_module.f03 my_module.o
There will be an output, despite the Fortran program being empty:
hello, world!
I still would not recommend doing this, since it is likely not guaranteed that the Fortran RT environment is ready when the C/C++ global/static function call happens.
I have looked through all the posts on this topic I could find but they do not seem to solve my problem. I am thankful for any input/help/idea. So here it is:
I have my main program (main.f90):
program inv_main
use mod_communication
implicit none
include 'mpif.h'
...
call MPI_INIT(ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD,id,ierr)
call MPI_COMM_SIZE(MPI_COMM_WORLD,nproc,ierr)
...
call SENDRECEIVE(id, nproc, ierr, VVNP, VVN)
...
call MPI_FINALIZE(ierr)
end program inv_main
And here is the module that includes the subroutine (I am aware that allgather might be a better way to do the same but I could not figure it out yet for my 4D array):
Module mod_communication
implicit none
include 'mpif.h'
integer, dimension(MPI_STATUS_SIZE) :: STATUS ! MPI
CONTAINS
Subroutine SENDRECEIVE(id, nproc, ierr, INPUT, OUTPUT )
integer, intent (in) :: nproc, id, ierr
real (dp), intent(in) :: INPUT(n,m)
real (dp), intent(out) :: OUTPUT(n,m,nty,nty)
integer :: sndr
IF (id .eq. 0) THEN
OUTPUT(1:n,1:m,1,1)=INPUT
call MPI_RECV(INPUT,n*m,MPI_DOUBLE_PRECISION,MPI_ANY_SOURCE,MPI_ANY_TAG,MPI_COMM_WORLD,STATUS,ierr)
sndr=STATUS(MPI_SOURCE)
OUTPUT(1:n,1:m,int(sndr/nty)+1,sndr+1-nty*(int(sndr/nty))) = INPUT
END IF
IF (id .ne. 0) THEN
call MPI_SEND(INPUT,n*m,MPI_DOUBLE_PRECISION,0,id,MPI_COMM_WORLD,ierr)
ENDIF
call MPI_BARRIER(MPI_COMM_WORLD,ierr)
call MPI_BCAST(OUTPUT,n*m*nty*nty,MPI_DOUBLE_PRECISION,0,MPI_COMM_WORLD,ierr)
end Subroutine
end Module mod_communication
This is the error message I got when compiling:
use mod_communication
2
Error: Symbol 'mpi_displacement_current' at (1) conflicts with symbol from module 'mod_communication', use-associated at (2)
mpif-mpi-io.h:71.36:
Included at mpif-config.h:65:
Included at mpif-common.h:70:
Included at mpif.h:59:
Included at main.f90:27:
integer MPI_MAX_DATAREP_STRING
1
main.f90:21.6:
use mod_communication
2
Error: Symbol 'mpi_max_datarep_string' at (1) conflicts with symbol from module 'mod_communication', use-associated at (2)
mpif-mpi-io.h:73.32:
Included at mpif-config.h:65:
Included at mpif-common.h:70:
Included at mpif.h:59:
Included at main.f90:27:
parameter (MPI_FILE_NULL=0)
These are just the first two errors, it keeps going like that... And I cannot find my mistake. Also, I have to use "include 'mpif.h'" and not "use mpi" because of the machine I am ultimately going to run it on. If I compile it with use mpi however on my own computer it gives me a different error, which is the following:
mod_MPI.f90:93.41:
call MPI_BARRIER(MPI_COMM_WORLD,ierr)
1
Error: There is no specific subroutine for the generic 'mpi_barrier' at (1)
mod_MPI.f90:52.41:
Your main program probably gets (or rather tries to get) two copies of all the stuff in mpif.h. By include-ing it in the module you effectively make all its contents module things (variables, routines, parameters, what-nots). Then, in main you both use the module and, thereby, use-associate the module things, and try to include mpif.h and redeclare all those things again.
Do what #Jonathan Dursi suggests too.
I'm trying to debug some code in which members of a user defined object mysteriously change addresses, and while doing that I realized user defined objects do that as well. Here's a small example of querying object address from function that created it and then from its member function:
module foo_module
type foo_type
contains
procedure :: foo
end type foo_type
contains
subroutine foo(this)
class(foo_type) :: this
print *, 'Inside foo this is', loc(this)
end subroutine foo
end module foo_module
program trial
use foo_module
type(foo_type) :: object
print *, 'Object address', loc(object)
call object%foo()
end program trial
A sample output I get is:
Object address 4452052800
Inside foo this is 140734643354880
Why am I getting two different addresses for the same object? Am I doing something wrong? Or is there something with LOC that comes into play I don't understand?
I'm using ifort under osx.
LOC is an extension. Its behaviour is as specified by the compiler vendor.
What the behaviour intended by the vendor here isn't clear, but the difference that you are seeing is that in the main program you get the integer equivalent of the memory address of the non-polymorphic object (what you probably expect), while in the subroutine you get the integer equivalent of the memory address of the polymorphic descriptor for the object (maybe what you want, maybe not).
Using TRANSFER(C_LOC(xxx), 0_C_INTPTR_T) is a more portable way of getting the integer representation of the address of an object (where the C_* things are from the ISO_C_BINDING intrinsic module). C_LOC requires that its argument have the TARGET attribute and be non-polymorphic (use SELECT TYPE).
I'd recommend asking on the relevant Intel Forum if you want further clarification on the intended behaviour of the LOC extension.
I reported the bug to the developers our internal issue ID is DPD200253159. I found that the C_LOC function from ISO_C_BINDING works. For example:
subroutine foo(this)
use, intrinsic :: iso_c_binding
class(foo_type) :: this
print *, 'Inside foo this is', transfer(c_loc(this),0_C_INTPTR_T)
end subroutine foo
I wonder if there is a way of having a global variable in Fortran, which can be stated as some kind of 'protected'. I am thinking of a module A that contains a list of variables. Every other module or subroutine that uses A can use it's variables. If you know what the value of the variable is, you could use parameter to achieve that it can't be overwritten. But what if you have to run code first to determine the variables value? You could not state it as parameter since you need to change it. Is there a way to do something similar but at a specific point at runtime?
You could use the PROTECTEDattribute in a module. It has been introduced with the Fortran 2003 standard.
The procedures in the module can change PROTECTED objects, but not procedures in modules or programes that USE your module.
Example:
module m_test
integer, protected :: a
contains
subroutine init(val)
integer val
a = val
end subroutine
end module m_test
program test
use m_test
call init(5)
print *, a
! if you uncomment these lines, the compiler should flag an error
!a = 10
!print *, a
call init(10)
print *, a
end program
my program is as follows:
module x
use mpi !x includes mpi module
implicit none
...
contains
subroutine do_something_with_mpicommworld
!use mpi !uncommenting this makes a difference (****)
call MPI_...(MPI_COMM_WORLD,...,ierr)
end subroutine
...
end module x
program main
use mpi
use x
MPI_INIT(...)
call do_something_with_mpicommworld
end program main
This program fails with the following error: MPI_Cart_create(199): Invalid communicator, unless
the line marked with (**) is uncommented.
Now, maybe my knowledge of Fortran 90 is incomplete, but i thought if you have a use clause in the module definition (see my module x), whichever global variable exists in the included module (in case of x : MPI_COMM_WORLD from include module mpi) will have the same value in any of the contained subroutines ( do_something_with_mpicommworld ) even when those subroutines do not explicitly include the module (e.g. when (**) is commented out). Or, to put it simply, if you include a module within another module, the subroutines contained in the second module will have access to the globals in the included module without a special use statement.
When I ran my programme, I saw a different behaviour. The sub contained in x was creating errors unless it had the 'use mpi' statement.
So what is the problem, do I have a wrong idea about Fortran 90, or is there something special about MPI module which induces such behaviour?
Its annoyingly hard to find exact details about what should and shouldn't happen in these cases, and my expectation was the same as yours -- the `use mpi' should work as above. So I tried the following:
module hellompi
use mpi
implicit none
contains
subroutine hello
integer :: ierr, nprocs, rank
call MPI_INIT(ierr)
call MPI_COMM_SIZE(MPI_COMM_WORLD, nprocs, ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr)
print *, 'Hello world, from ', rank, ' of ', nprocs
print *, MPI_COMM_WORLD
call MPI_FINALIZE(ierr)
return
end subroutine hello
end module hellompi
and it works fine under both gfortran and ifort with OpenMPI. Adding a cart_create doesn't change anything.
What strikes me as weird with your case is that it isn't complaining that MPI_COMM_WORLD isn't defined -- so obviously some of the relevant information is being propagated to the subroutine. Can you post a simpler full example which still fails to work?
Thank you Johnatan for your answer. The problem was really, really simple. I added the subroutine in question after the "end module"
:-D, 'implicit none' did not apply to now external sub and compiler happily initialised a brand new variable MPI_COMM_WORLD to whatever it thought suitable following the standard implicit rules.
This is just a lesson to me to enforce 'implicit none' not only by keywords, but also via the compiler flag. Evil lurks after every end statement.
I'm sorry you went trough the trouble of making the test example, I'd buy you a beer if I could :-)