Hi all,
I need help, I’ve a code and it run perfectly on a cluster compiled with ifort. Now I move the code on a PC with gfortran and caf compiler, but I’ve the error in the title…
230 | type(Sbathy) function bat_constructor(fcu,dname,ig) result(res)
| 1
Error: Function result ‘res’ at (1) shall not be a coarray or have a coarray component
bathy.f90:4:5:
If i comment the function, both the compiler work great!
Where is the problem??
Thanks
@sverdrup, welcome to the forum! Your question is clear enough, but to really answer it, we will need to see the code, especially the definition of the derived type Sbathy.
type Sbathy
type(Gridinfo) :: gemo, gmed
type(Halo)::halo
contains
procedure, pass(self) :: get_inner
procedure,pass(self) :: halo_ex
procedure, pass(self) :: find_neighbor
procedure, pass(self) ::init
end type Sbathy
and here I’ve the problem:
type(Sbathy) function bat_constructor(fcu,dname,ig) result(res)
character(len=*), intent(in)::dname,fcu
integer, intent (in) ::ig
type(Gridinfo) :: gem, gme
integer ::status, i,j
gem=Gridinfo(dname,ig)
gme=Gridinfo(fcu,0)
res%gemo=gem
res%gmed=gme
call res%halo_ex()
sync all
!print *,'exit from halo'
call res%init()
!%res%gmed=gme
end function bat_constructor
If I comment the function and the call in the main, the compilation (gfortran) terminate without errors.
The strange thing is if I compile the same code with ifortran compiler on the cluster i don’t have the error.
So, it might be the “sync all” statement that is causing this. The compiler erroneously interprets this as a coarray component in the result. Just a hunch, but could you instead turn the function into a subroutine that sets argument res? Maybe that way the compiler is no longer confused.
Ok I’ve triied to reconfigure all the system, I’ve used ubuntu 18.04 docker with libnetcdf, opencoarray and all other the stuff… But the problem remane the same, when I try to compile the code I’ve this result:
root@c977ddc8aae3:/home/data# caf mod_bathy_field.f90 bathy.f90 `nf-config --fflags --flibs` -o pippon
mod_bathy_field.f90:230:63:
type(Sbathy) function bat_constructor(fcu,dname,ig) result(res)
1
Error: Function result 'res' at (1) shall not be a coarray or have a coarray component
bathy.f90:4:4:
use mod_bathy_field
1
Fatal Error: Can't open module file 'mod_bathy_field.mod' for reading at (1): No such file or directory
compilation terminated.
Error: comand:
`/usr/bin/mpifort -I/usr/include/OpenCoarrays-2.0.0-rc1_GNU-7.3.0 -fcoarray=lib mod_bathy_field.f90 bathy.f90 -I/usr/include -L/usr/lib -lnetcdff -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -lnetcdf -lnetcdf -o pippon /usr/lib/x86_64-linux-gnu/libcaf_mpi.a`
failed to compile.
Hm, do you have a small(ish) reproducer? So far we have only parts of the program and that makes us guess as to what is going on. It would greatly help if you can provide a complete program of very moderate size that we can try to compile ourselves.
I used these source files for some experimentation. When I changed the function to a subroutine and added an intent(out) to the new “res” argument, both Intel Fortran and gfortran complained. Something along these lines:
error #8391: An entity with the INTENT(OUT) attribute must not be an allocatable coarray or have a subobject that is an allocatable coarray. [RES]
which does make sense in a way, as coarrays require synchronisation. Not sure how to solve this problem.
Ok, I managed to compile the code using the oneAPI Intel compiler, but now when I run the code I’ve the follow error:
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 0 PID 117 RUNNING AT 686bff36a2cc
= KILLED BY SIGNAL: 11 (Segmentation fault)
===================================================================================
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 1 PID 118 RUNNING AT 686bff36a2cc
= KILLED BY SIGNAL: 11 (Segmentation fault)
===================================================================================
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 2 PID 119 RUNNING AT 686bff36a2cc
= KILLED BY SIGNAL: 11 (Segmentation fault)
===================================================================================
Does anyone have any idea regarding the meaning of the error?
thank’s in advance
Segmentation fault indicates an illegal memory access. One cause of that is accessing an out of bounds array element. Check that any allocatable arrays or pointers are properly allocated. Also check that you don’t access elements less than the lower bound (typically 1), or greater than the upper bound. Another cause is exceeding the stack size. Most systems come with a default maximum stack size that can be reset using a shell command often to an unlimited value. Mac OSX has a maximum maximum stack size of 64 Mb. Check also that you do not have an infinite recursion in your code that will result in you always exceeding the maximum stack size. I haven’t used co-arrays and using them may provide another way of illegally accessing a memory location.
Thank you wclodius, the problem is the code run perfectly on mac with oneapi intel compiler with netcdf, running on 6 core. I think my problem is due to my work environment, I’ve compile zlib, hdf5, netcdf-c and netcdf-fortran with oneapi c and fortran compiler, but I have the same error with different code running in parallel with coarray.
that we can try to compile ourselves.