I seem to have hit a wall while coding these past few days. from what i can gather, it is possible to make arrays of arrays in fortran ala Fortran array of variable size arrays
type par
.... !data
integer :: location
end type par
type locations
....! data
type (par), allocatable, dimension(:) :: pars
end type locations
type (par), allocatable, dimension(:) :: all_pars
type (locations), allocatable, dimension(:) :: all_loc
.... !read numpars, numlocs from file etc
allocate(all_pars(numpars))
allocate(all_locs(numlocs))
!initialize all_pars
do n = 1:numpars
....
all_pars(n)%location = some_location
enddo
!get particles in each location
do n = 1:numlocs
allocate(all_locs(n)%pars(count(all_pars(:)%location .ne. n)))
all_locs(n)%pars = pack(all_pars, (all_pars(:)%location .ne. n)) !ERROR: An assignment of different structure types is invalid.
enddo
the compiler does not complain with my equivalent lines of code for the stack overflow example above, but it indeed does have an issue when i attempt to use that array to store the result of a pack function call. i suspect that it may be the case that the allocate function is not behaving as expected, but since the code does not compile, i cannot debug it....
the squirrely idea for pack usage comes from http://flibs.sourceforge.net/fortran_aspects.html , about halfway down the page.
I am running on a linux system, with ifort 12.1.3.293
any help is much appreciated
This may be an extended comment rather than an answer ...
to get it to compile I modified your posted code to;
program main
implicit none
integer :: numpars, numlocs, n
type par
!data
integer :: location
end type par
type locations
! data
type (par), allocatable, dimension(:) :: pars
end type locations
type (par), allocatable, dimension(:) :: all_pars
type (locations), allocatable, dimension(:) :: all_locs
!read numpars, numlocs from file etc
numpars = 10
numlocs = 4
allocate(all_pars(numpars))
allocate(all_locs(numlocs))
!initialize all_pars
all_pars(1:numpars:4)%location = 1
all_pars(2:numpars:4)%location = 2
all_pars(3:numpars:4)%location = 3
all_pars(4:numpars:4)%location = 4
!get particles in each location
do n = 1,numlocs
! allocate(all_locs(n)%pars(count(all_pars(:)%location .ne. n)))
all_locs(n)%pars = pack(all_pars, (all_pars(:)%location .ne. n))
enddo
end program
and it compiles without a hitch on my Mac with Intel Fortran 13.something. Of course, since you've only posted a syntactically-slightly-incorrect part of your code I can't be sure that this tells you very much.
Since you don't show that your code uses implicit none your error might be down to the difference between all_loc and all_locs or some other similar issue.
Note, in passing, that with Fortran allocatable arrays you don't need to allocate all_locs(n)%pars prior to setting its value with the call to pack, the compiler will take care of that for you. This, though, is not the source of your error.
Related
I would like to assign a pointer in a derived type that is contained in the same derived type. The code below gives me the error below. What is going on here, and how can I solve this?
24 | zoos(i)%tigers(1) => zoos(i)%animals(1, 1)
| 1
Error: Expected bounds specification for 'zoos' at (1)
module mo_zoo
implicit none
type zoo
integer, dimension(:,:), pointer :: animals
integer, dimension(:), pointer :: tigers
integer, dimension(:), pointer :: ducks
end type zoo
save
type(zoo), dimension(:), pointer :: zoos
end module mo_zoo
program test
use mo_zoo
implicit none
integer :: n_zoos
integer :: i
n_zoos = 4
allocate(zoos(n_zoos))
do i = 1, n_zoos
allocate(zoos(i)%animals(10, 2))
zoos(i)%tigers(1) => zoos(i)%animals(1, 1)
zoos(i)%ducks(1) => zoos(i)%animals(1, 2)
end do
end program test
The problem is nothing to do with the derived type, and the error message is wrong.
The problem is that zoos(i)%ducks is a pointer to an array, not an array of pointers, so you need to point zoos(i)%ducks at zoos(i)%animals(:, 2), rather than zoos(i)%ducks(1) at zoos(i)%animals(1, 2).
I have previously talked about this in this answer.
I believe this does what you want:
module mo_zoo
implicit none
type zoo
integer, dimension(:,:), pointer :: animals
integer, dimension(:), pointer :: tigers
integer, dimension(:), pointer :: ducks
end type zoo
save
type(zoo), dimension(:), pointer :: zoos
end module mo_zoo
program test
use mo_zoo
implicit none
integer :: n_zoos
integer :: i
n_zoos = 4
allocate(zoos(n_zoos))
do i = 1, n_zoos
allocate(zoos(i)%animals(10, 2))
zoos(i)%tigers => zoos(i)%animals(:, 1)
zoos(i)%ducks => zoos(i)%animals(:, 2)
end do
end program test
I would also like to offer a frame challenge. As noted in the comments, particularly by Ian Bush, pointers in Fortran are notoriously error-prone.
I would recommend replacing any allocated pointers with allocatables. These allocatables also need to be targets if they have pointers pointing at them, like so:
module mo_zoo
implicit none
type zoo
integer, dimension(:,:), allocatable :: animals
integer, dimension(:), pointer :: tigers
integer, dimension(:), pointer :: ducks
end type zoo
save
type(zoo), dimension(:), allocatable, target :: zoos
end module mo_zoo
program test
use mo_zoo
implicit none
integer :: n_zoos
integer :: i
n_zoos = 4
allocate(zoos(n_zoos))
do i = 1, n_zoos
allocate(zoos(i)%animals(10, 2))
zoos(i)%tigers => zoos(i)%animals(:, 1)
zoos(i)%ducks => zoos(i)%animals(:, 2)
end do
end program test
There are a number of advantages to using allocatables over pointers where possible:
The memory held by allocatables will automatically be freed when the allocatables drop out of scope1.
Compilers can make stronger assumptions about allocatables than about pointers, sometimes leading to faster code.
1 At least, this is true according to the Fortran standard. There are several outstanding problems with some compilers (notably this bug) relating to finalisation.
Let me just preface this by saying that I am very new to Fortran but familiar with Python. My research project however requires me to use some pre-written Fortran code, which at this moment wont compile on my pc. I am trying to understand why.
The actual code I am trying to compile is very long and probably not very illuminating, but I think I have managed to come up with a minimal example of where I think the issue is. Let's say I have a very simple module and subroutine as follows,
module arraycheck
implicit none
real*8, allocatable, dimension(:) :: x
contains
subroutine fillx
real*8, allocatable, dimension(:) :: x
allocate(x(5))
x(1) = 1
x(2) = 2
x(3) = 3
x(4) = 4
x(5) = 5
print*, x
end subroutine fillx
end module arraycheck
which I expect to simply create an array x, which when the subroutine fillx is called fills the array with the integers 1 to 5. My actual source contains something conceptually similar to this. Now I also have a main program as follows,
program main
use arraycheck
print*, x
call fillx
print*,x
end
My idea here would be that on the first print statement the variable x is still unallocated, so print returns nothing, and then on the second print statement x has been filled, so it should return the filled array.
However on both print statements nothing is returned. Now in my original source code something similar happens, which causes runtime to throw an error that an unallocated array was passed somewhere as an actual argument, which should have been allocated. It seems like the exact same thing happens as in my small example here.
So my question is, is the behaviour that I observe in my example here expected? And if it is, how can I alter the code to make it work in the way that I would want it to? If I know this I might better understand why the actual source doesn't work.
Just in case it is relevant, I am using gfortran on ubuntu.
Thanks!
You have too different xs. They do not have anything in common. One a module array and one array local to the subroutine. When you allocate the local array in the subroutine, it does not do anything to the other array in the module.
Also, you cannot print array that is not allocated. That is not standard conforming (undefined behaviour). Anything can happen. You should definitely enable all compiler checks when diagnosing problems. The compiler should complain about your code with those checks.
Remove the local array declaration and avoid referencing unallocated variables. Module procedures have access to module variables through host association.
module arraycheck
implicit none
real*8, allocatable, dimension(:) :: x
contains
subroutine fillx
allocate(x(5))
x(1) = 1
x(2) = 2
x(3) = 3
x(4) = 4
x(5) = 5
print*, x
end subroutine fillx
end module arraycheck
program main
use arraycheck
call fillx
print*,x
end
Also, real*8 is not standard Fortran, it is a non-standard extension. Fortran 90 and later uses the kind system instead.
Here are some other things which might be helpful - shown in UPPERCASE.
module arraycheck
USE ISO_C_BINDING, ONLY : C_Int32_t, C_DOUBLE
implicit none
PRIVATE
real(KIND=C_DOUBLE), allocatable, dimension(:), PUBLIC :: x
PUBLIC Creation_X, Destruction_X, FillX
contains
subroutine Creation_X(n)
USE ISO_C_BINDING, ONLY : C_Int32_t
IMPLICIT NONE
INTEGER(KIND=C_Int32_t), INTENT(IN) :: n
allocate(x(n))
RETURN
end subroutine Creation_X
subroutine Destruction_X
USE ISO_C_BINDING, ONLY : C_Int32_t
IMPLICIT NONE
IF(ALLOCATED(X)) DEALLOCATE(X)
RETURN
end subroutine Destruction_X
subroutine fillx
USE ISO_C_BINDING, ONLY : C_Int32_t
IMPLICIT NONE
INTEGER(KIND=C_Int32_t) :: N
DO I= 1, SIZE(x)
x(I) = I
ENDDO
RETURN
end subroutine fillx
end module arraycheck
program main
use arraycheck
CALL Creation_X(5)
call fillx
print*,x
CALL Destruction_X
end
I have the following code which is producing a segmentation fault. It does complain that
forrtl: severe (408): fort: (7): Attempt to use pointer TT when it is not associated with a target
Now I am pretty sure what the reason is, namely, it is trying to access my copy assignment routine, while I am just trying to initialise the object.
By commenting out generic :: assignment(=) => copy it works fine!
I am compiling the code as follows : (IFORT version 19.0.3)
ifort -O0 -debug full -check all -traceback -g -C -CB -CU -CA -fpp filaname.f90
and running by ./a.out
module md
implicit none
type T_TEST
integer :: ii
contains
procedure, pass(this) :: COPY
generic :: assignment(=) => copy
end type
interface t_test
module procedure init
end interface t_test
type(t_test) , allocatable :: tt
contains
function init( size )
integer, intent(in) :: size
type(t_test) , allocatable :: init
allocate( init )
init% ii = size
end function
subroutine copy(this, old )
class(t_test), intent(out) ::this
type(t_test), intent(in) :: old
this% ii = old% ii
end subroutine
end module md
program t_Testprogram
use md
implicit none
tt = t_test( 100 )
end program t_Testprogram
The reason is that the overloaded assignment copy does not support allocatable left hand sides. So when the value of this is used in this% ii = old% ii , it actually does not exist and a null pointer is used. But I do agree the Intel's error message is confusing or even incorrect.
The automatic left hand side (re-)allocation only applies to intrisic assignments, not to user defined ones. In user-defined ones you must program yourself the exact behaviour. And you did not specify anything for not-allocated left hand sides.
This works for me:
type T_TEST
integer :: ii
end type
interface assignment(=)
procedure copy
end interface
subroutine copy(this, old )
class(t_test), allocatable, intent(out) ::this
type(t_test), intent(in) :: old
if (.not.allocated(this)) allocate(this)
this% ii = old% ii
end subroutine
Or you can just allocate the object first (that is what I would do here because gfortran seems to not like generic resolution based on the allocatable attribute - a F08 feature).
allocate(tt)
tt = t_test( 100 )
It seems that you are thinking that just because the constructor has its result variable "marked" allocatable, it will allocate the left hand side of the assignment for you. It is not so. The only thing it does it that it allocates its own result as a temporary variable. This result is then assigned in tt = t_test() and then deallocated automatically.
Remember, the result variable is not the same as the left hand side of the assignment. The result can be used in an expression of many different types, not just in an assignment. It can be passed to a subroutine, it can be used in an arithmetic expression, it can be printed...
Your constructor can be just
function init( size )
integer, intent(in) :: size
type(t_test) :: init
init% ii = size
end function
and the result will be exactly the same. There is no reason to make it allocatable, it just complicates it, but does not change the result in the slightest.
Maybe what you are trying to follow some C++ RAII principles, but remember, C++ is simply not Fortran.
I'm new to Fortran programming and I'm trying to understand the call between subroutines. So I wrote a simple program to test it
Here is my code
program dummy
real, allocatable, dimension(:) :: zz,yy
call test2(zz,yy)
print *, zz, yy
contains
subroutine test1(ar1,ar2,arsum)
real, dimension(:) :: ar1,ar2
real, allocatable, dimension(:) :: arsum
allocate(arsum(size(ar1)+size(ar2)))
arsum(1:size(ar1)) = ar1
arsum(size(ar1)+1:size(ar1)+size(ar2)) = ar2
end subroutine test1
subroutine test2(sg1,sg2)
real, dimension(3) :: g1,g3
real, dimension(4) :: g2,g4
real, allocatable,dimension(:) :: sg1,sg2,dum
g1 = 1.0
g2 = 2.0
g3 = 3.0
g4 = 4.0
call test1(g1,g3,dum)
sg1 = 2*dum
call test1(g2,g4,dum)
sg2 = 3*dum
end subroutine test2
end program dummy
However this throws me the following error
forrtl: severe (151): allocatable array is already allocated
Image PC Routine Line Source
dummy.exe 0000000000409B1C Unknown Unknown Unknown
dummy.exe 0000000000402E70 MAIN__ 26 dummy.f90
dummy.exe 0000000000402A2E Unknown Unknown Unknown
libc-2.23.so 00002B3E716C7830 __libc_start_main Unknown Unknown
dummy.exe 0000000000402929 Unknown Unknown Unknown
The test1 subroutine simply concatenates any two given arrays. Test2 subroutine defines the arrays to be concatenated and does some algebra on the output and stores them in new arrays. The program dummy simply prints the new arrays.
What is it that I'm doing wrong here?
Let's look at the flow of the program here. There's some terminology involved here, but what is used can hopefully be explored through other documentation.
The main program calls the subroutine test2 with a couple of arguments. For the problem here, those arguments are of no interest. Instead, look at the local (to the subroutine) variable dum.
dum is an allocatable array. It starts life at execution of test2 as not allocated. It's first an (actual) argument to the call of test1 and later as an (actual) argument to another call of test1. So, what goes wrong?
Intent of the arguments is crucial here. Really crucial. One should read up on intents elsewhere before continuing with this answer.
So, we're now familiar with argument intents.
On entering the subroutine test1 the dummy argument arsum has the same allocation status as the actual argument dum. During test1's execution there is an allocate statement.
An allocate statement may only attempt to allocate a thing not already allocated. This is fine on the first call: on entry dum/arsum is not allocated. During execution of the subroutine arsum is allocated, and this affects the allocation status of test2's dum.
On the second call to test1 arsum is now allocated because the actual argument dum is allocated. The allocate statement fails, with the error message given, because of this.
That's the problem; how to fix? We need to ensure arsum is not allocated. There are two obvious ways:
test the allocation status of arsum and respond accordingly (perhaps with a deallocate);
deallocate dum between calls of test1.
But there is a possibly more appropriate way. Note that dum is useful only as returning to test2 the value of some operation. Think back to intents: this is what intent(out) signifies.
If we rewrite the subroutine test1 as
subroutine test1(ar1,ar2,arsum)
real, dimension(:) :: ar1,ar2
real, allocatable, dimension(:), intent(out) :: arsum
allocate(arsum(size(ar1)+size(ar2)))
arsum(1:size(ar1)) = ar1
arsum(size(ar1)+1:size(ar1)+size(ar2)) = ar2
end subroutine test1
then, because of the intent(out), attribute arsum/dum is automatically deallocated if it is allocated on entry.
Finally (and not shown), one could even consider using a function to return arsum or even use automatic arrays rather than allocatable ones. Or, even Fortran 2003 automatic allocation and an array constructor:
subroutine test1(ar1,ar2,arsum)
real, dimension(:) :: ar1,ar2
real, allocatable, dimension(:) :: arsum ! Or with `intent(out)`
arsum = [ar1,ar2]
end subroutine test1
I'm new to Fortran (more experienced in C), and am trying to allocate memory for a matrix of values using the allocate command. The code is:
module SMS
contains
subroutine readSMS(elem)
real, dimension(:,:), allocatable :: elem
allocate( elem(3792, 3) ) ! this will be a variable later on, for now I've
! hard-coded the number of elements in my test case
end subroutine
end module
When running, the code always crashes on the allocate line, with the error: Program exception - access violation. This program, however, works fine if elem is a local variable as opposed to one passed in to the subroutine. In C, I would use something like:
double **elem;
readSMS(&elem); //pass in a pointer to elem so that memory can be allocated
Is there a similar method in Fortran that I can use to allocate memory in a subroutine?
Here is the call to the function:
program main
use SMS
implicit none
include 'mpif.h'
! Variables
integer ierr,num_procs,my_id
integer num_elem,num_regions
real, dimension(:,:), allocatable :: elem
real, dimension(:,:), allocatable :: regions
! Body of main
call MPI_INIT(ierr)
call MPI_COMM_RANK(MPI_COMM_WORLD,my_id,ierr)
call MPI_COMM_SIZE(MPI_COMM_WORLD,num_procs,ierr)
call readSMS(elem)
deallocate(elem)
call MPI_FINALIZE(ierr)
end program main
At the moment, this is the entirety of the program (as you can see, I'm just getting started).
#francescalus I think the subroutine readSMS is in the module, so the explicit interface is not the problem. #wolfPack88 look at the link provided by #Jonathan and you will be able to figure out the solution.
update:
module SMS
contains
subroutine readSMS(elem)
real, dimension(:,:), allocatable :: elem
allocate( elem(10, 3) )
elem=10
end subroutine
end module
program main
use SMS
implicit none
real, dimension(:,:), allocatable :: elem
call readSMS(elem)
print *, elem
deallocate(elem)
end program main
This code works in ifort without any issue...