Dynamic arrays f95 - fortran

I am trying to understand how to use dynamic memory in f95.
I know that the following code in f2003 works.
program main
use pippo
implicit none
integer, allocatable :: arr(:)
call createDynamic(arr)
end program main
module pippo
contains
subroutine createDynamic(arr)
implicit none
integer, allocatable,dimension(:)::arr
integer :: i,n
n=10
allocate(arr(n))
do i=1,n
arr(i) = i
end do
end subroutine createDynamic
end module pippo
I would like to write a version in f95: what is the proper way to do it?

Your code us valid Fortran 95 + the ISO/IEC TR-15581 enhancements to allocatable arrays, which allowed allocatable dummy arguments.
In pure Fortran 95 you have to allocate the array in the main program or use pointers. However, it is year 2019, almost 2020. There is very little reason to use Fortran 95 without this TR. Or even not just using most of the widely supported Fortran 2008 features.

Related

How to understand this negative index array variable declaration? [duplicate]

I need in a program to pass some allocatable arrays to subroutines, and i need to know if the way I do it are in the standard or not.
If you know where I can search for the standard of fortran, Tell me please.
Here is a little code that will better explain than words
program test
use modt99
implicit none
real(pr), dimension(:), allocatable :: vx
allocate(vx(-1:6))
vx=(/666,214,558,332,-521,-999,120,55/)
call test3(vx,vx,vx)
deallocate(vx)
end program test
with the module modt99
module modt99
contains
subroutine test3(v1,v2,v3)
real(pr), dimension(:), intent(in) :: v1
real(pr), dimension(0:), intent(in) :: v2
real(pr), dimension(:), allocatable, intent(in) :: v3
print*,'================================'
print*,v1(1:3)
print*,'================================'
print*,v2(1:3)
print*,'================================'
print*,v3(1:3)
print*,'================================'
end subroutine test3
end module modt99
on screen, I get
================================
666.000000000000 214.000000000000 558.000000000000
================================
214.000000000000 558.000000000000 332.000000000000
================================
558.000000000000 332.000000000000 -521.000000000000
================================
So are the three ways of dummy arguments in subroutine test3 legal (in what version of fortran, 90, 95, 2003?) and are their behavior normal?
The first version passes the array slice to the subroutine. Note that boundary information are not passed along in this way, arrays are assumed to start at 1 and go to size(array).
The second way is just like the first one, but you manually set the lower boundary to 0, that's why printing v3(1:3) gives you the values with an offset of 1.
The third way passes all array information to the subroutine (including boundaries), hence the "correct" indexing. Passing allocatable arrays was introduced with Fortran 2003.
Apart from the fact that you have an aliasing issue (passing the same variable to three different dummy arguments), all three versions are legal.
You can find all documents of the standards here.
Especially, take a look at the Fortran 2003 Standard, Ch. 5.1.2.5 DIMENSION attribute to see the differences between assumed shape and deferred shape arrays in dummy arguments.

Reset (deallocate / nullify) a Fortran allocatable array that has been corrupted

When a situation such as described in Incorrect fortran errors: allocatable array is already allocated; DEALLOCATE points to an array that cannot be deallocated happens (corrupted memory leaves an allocatable array that appears allocated but does not "point" to a valid address), is there anything that can be done within Fortran to cure it, i.e., reset the array as deallocated, without trying to deallocate the memory it points to?
The situation is a Fortran/C program where a piece of C code purposefully corrupts (writes garbage to) allocated memory. This works fine for arrays of normal types. But with an allocatable array of a user-defined type, which includes itself an allocatable component, the garbage written to the portion belonging to the allocatable component means that now the component appears as allocated, even though it's not. Rather than making the C code aware of what it should corrupt or not, I'd prefer fixing it after, but "nullifying" the allocatable component, when I know I don't care about the memory it currently appears to point to. With a pointer, it would be just a matter of nullify, but with an allocatable array?
If the memory is really corrupted as in stack corruption/heap corruption. You cannot do anything. The program is bound to fail because the very low-level information is lost. This is true for any programming language, even C.
If, what is corrupted, is the Fortran array descriptor, you cannot correct it from Fortran. Fortran does not expose these implementation details to Fortran programmers. It is only available via special headers called ISO_Fortran_binding.h from C.
If the only corruption that happened was making Fortran thing that the array is allocated where it isn't, it should be rather simple to revert that from C. All it should be necessary is to change the address of the allocated memory. Allocatable arrays are always contiguous.
One could also try dirty tricks like telling a subroutine that what you are passing is a pointer when it in fact is an allocatable and nullify it. It will likely work in many implementations. But nullifying the address in a controllable way is much cleaner. Even if it is just a one nullifying C function you call from Fortran.
Because you really only want to change the address to 0 and not make any other special stuff with the array extents, strides and other details, it should be simple to do even without the header.
Note that the descriptor will still contain nonsense data in other variables, but those should not matter.
This is a quick and dirty test:
Fortran:
dimension A(:,:)
allocatable A
interface
subroutine write_garbage(A) bind(C)
dimension A(:,:)
allocatable A
end subroutine
subroutine c_null_alloc(A) bind(C)
dimension A(:,:)
allocatable A
end subroutine
end interface
call write_garbage(A)
print *, allocated(A)
call c_null_alloc(A)
print *, allocated(A)
end
C:
#include <stdint.h>
void write_garbage(intptr_t* A){
*A = 999;
}
void c_null_alloc(intptr_t* A){
*A = 0;
}
result:
> gfortran c_allocatables.c c_allocatables.f90
> ./a.out
T
F
A proper version should use ISO_Fortran_binding.h if your compiler provides it. And implicit none and other boring stuff...
A very dirty (and illegal) hack that I do not recommend at all:
dimension A(:,:)
allocatable A
interface
subroutine write_garbage(A) bind(C)
dimension A(:,:)
allocatable A
end subroutine
subroutine null_alloc(A) bind(C)
dimension A(:,:)
allocatable A
end subroutine
end interface
call write_garbage(A)
print *, allocated(A)
call null_alloc(A)
print *, allocated(A)
end
subroutine null_alloc(A) bind(C)
dimension A(:,:)
pointer A
A => null()
end subroutine
> gfortran c_allocatables.c c_allocatables.f90
c_allocatables.f90:27:21:
10 | subroutine null_alloc(A) bind(C)
| 2
......
27 | subroutine null_alloc(A) bind(C)
| 1
Warning: ALLOCATABLE mismatch in argument 'a' between (1) and (2)
> ./a.out
T
F

Fortran Type mismatch in argument n at 1 passed REAL(8) to integer (4)

I'm having a problem with a fortran 77 project (Yes i know it's archaic, but my prof requres us to program in fixed form fortran)
So I'm having a problem with a subroutine, which should read an N dimension Vector, which should be a column. the code for this looks like: (its still an early draft for my homework, just trying to figure out how to call a subroutine the rest of the code will be done if i can compile this problem)
Program gauss
implicit double precision (A-H,O-Z)
!he directly asked for implicit typing
call Vread(V(N))
end program
Subroutine Vread(V,N)
Implicit double precision (A-H,O-Z)
dimension V(N)
read(*,*) (V(I),I=1,N)
return
end
So my problem is: If I try to compile it with gfortran gauss.exe -o gauss.f the compiler returns with error:
Type mismatch argument 'n' at(1); passed REAL(8) to Integer(4)
In your main program you write
call Vread(V(N)) ! this passes a rank-1 vector with N elements
but your subroutine is declared
Subroutine Vread(V,N) ! this requires 2 arguments
Change the call to
call Vread(V,N)
and let your professor know that the 21st Century arrived a while age. Note too that it is possible to write 21C Fortran in fixed-form. It doesn't make much sense, but might enable you to toe the line while developing in a more modern version of the language.
!he directly asked for implicit typing
I trust that you are in a jurisdiction where you do not pay directly for your education. If you are paying fees then demand more, you're being cheated.

Program stops due to array allocation in a function [duplicate]

The following code is returning a Segmentation Fault because the allocatable array I am trying to pass is not being properly recognized (size returns 1, when it should be 3). In this page (http://www.eng-tips.com/viewthread.cfm?qid=170599) a similar example seems to indicate that it should work fine in F95; my code file has a .F90 extension, but I tried changing it to F95, and I am using gfortran to compile.
My guess is that the problem should be in the way I am passing the allocatable array to the subroutine; What am I doing wrong?
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%!
PROGRAM test
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%!
IMPLICIT NONE
DOUBLE PRECISION,ALLOCATABLE :: Array(:,:)
INTEGER :: iii,jjj
ALLOCATE(Array(3,3))
DO iii=1,3
DO jjj=1,3
Array(iii,jjj)=iii+jjj
PRINT*,Array(iii,jjj)
ENDDO
ENDDO
CALL Subtest(Array)
END PROGRAM
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%!
SUBROUTINE Subtest(Array)
DOUBLE PRECISION,ALLOCATABLE,INTENT(IN) :: Array(:,:)
INTEGER :: iii,jjj
PRINT*,SIZE(Array,1),SIZE(Array,2)
DO iii=1,SIZE(Array,1)
DO jjj=1,SIZE(Array,2)
PRINT*,Array(iii,jjj)
ENDDO
ENDDO
END SUBROUTINE
!%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%!
If a procedure has a dummy argument that is an allocatable, then an explicit interface is required in any calling scope.
(There are numerous things that require an explicit interface, an allocatable dummy is but one.)
You can provide that explicit interface yourself by putting an interface block for your subroutine inside the main program. An alternative and far, far, far better option is to put the subroutine inside a module and then USE that module in the main program - the explicit interface is then automatically created. There is an example of this on the eng-tips site that you provided a link to - see the post by xwb.
Note that it only makes sense for a dummy argument to have the allocatable attribute if you are going to do something related to its allocation status - query its status, reallocate it, deallocate it, etc.
Please also note that your allocatable dummy argument array is declared with intent(in), which means its allocation status will be that of the associated actual argument (and it may not be changed during the procedure). The actual argument passed to your subroutine may be unallocated and therefore illegal to reference, even with an explicit interface. The compiler will not know this and the behaviour of inquiries like size is undefined in such cases.
Hence, you first have to check the allocation status of array with allocated(array) before referencing its contents. I would further suggest to implement loops over the full array with lbound and ubound, since in general you can't be sure about array's bounds:
subroutine subtest(array)
double precision, allocatable, intent(in) :: array(:,:)
integer :: iii, jjj
if(allocated(array)) then
print*, size(array, 1), size(array, 2)
do iii = lbound(array, 1), ubound(array, 1)
do jjj = lbound(array, 2), ubound(array, 2)
print*, array(iii,jjj)
enddo
enddo
endif
end subroutine
This is a simple example that uses allocatable dummy arguments with a module.
module arrayMod
real,dimension(:,:),allocatable :: theArray
end module arrayMod
program test
use arrayMod
implicit none
interface
subroutine arraySub
end subroutine arraySub
end interface
write(*,*) allocated(theArray)
call arraySub
write(*,*) allocated(theArray)
end program test
subroutine arraySub
use arrayMod
write(*,*) 'Inside arraySub()'
allocate(theArray(3,2))
end subroutine arraySub

passing real arrays from fortran 90 to fortran 77

I have a third-part code in fortran 77, and I have written a subroutine in fortran 90 that I would like to interface to this code. I have found that the variables are not passed correctly from one subroutine to the other. I think the reason is that the definitions of double precision in the two programs is not compatible.
I want that the variable returned to f77 is a double precision. Which real definition shall I use in f90? I am using selected_real_kind(p=15,r=307)
EDIT:
I have changed the declaration to double precision in f90, and I have verified that double precision variables are passed correctly. The problem arises when I am passing allocatable arrays from f90 to f77
The arrays are originally allocated in code f77. then I allocate some allocatable arrays in f90 and then pass them to f77, but this is not working
f77 code:
program oldprog
double precision da(100)
call sub(da)
end
subroutine sub(da)
double precision da(*)
call mynewsub(da)
end
f90 code:
subroutine mynewsub(da)
implicit none
double precision, allocatable:: da(:)
allocate(da(100))
da = 1.0
end subroutine mynewsub
I was thinking to skip the allocation in mynewsub, but then I get SIGSEGV
Your mynewsub accepts the array as allocatable argument.
That requires explicit interface in Fortran 95, and is impossible in Fortran 90, not even speaking about FORTRAN 77 which does not have allocatable at all.
You cannot do this.
And in your main program
program oldprog
double precision da(100)
the array is static. It cannot be reallocated in any way in any version of Fortran, it is fixed forever.
You should think about making it allocatable everywhere an update relevant parts of your code to Fortran 95.