I want to write a subroutine which could be used in 1D or 2D geometry.
Consequently I have variables that will be used only in the latter case.
I wish I could write a declaration section in that style:
real ( kind = double ) :: uleft,vleft,uright,vright
real ( kind = double ) :: distanceinx
real ( kind = double ) :: ...
if (ndim == 2) then
real ( kind = double ) :: ulow,vlow,uup,vup
real ( kind = double ) :: distanceiny
end if
but it doesn't compile.
Is there a syntax to do what I want to do in a proper way ?
A big part of the code will be similar in the two cases (ndim = 1 or 2) so I think that makes sense.
Just leave the variables there and don't use them in 1D. The syntax you propose does not exist and I don't know of any other similar one.
In Fortran 2003 you can also make them allocatable, but that is worth it only for arrays, to save some space.
Do not care about couple of unused bytes on the stack. They can remain unused in 1D.
You could treat the 1D array as a special two-dimensional array with Nx1. Then you could always use the 2D version of your code. You can still check for the length of the second dimension to determine the dimension. This even allows for extension to the third dimension!
Routines/functions like norm2 also work on both types, so this could further simplify your code.
Related
I'm trying to understand the documentation for sgemm as I am transitioning code from using this library to a different library.
The function prototype is
sgemm ( character TRANSA,
character TRANSB,
integer M,
integer N,
integer K,
real ALPHA,
real, dimension(lda,*) A,
integer LDA,
real, dimension(ldb,*) B,
integer LDB,
real BETA,
real, dimension(ldc,*) C,
integer LDC
)
I am having trouble understanding the role or LDA and LDB. The documentation says
LDA is INTEGER
On entry, LDA specifies the first dimension of A as declared
in the calling (sub) program. When TRANSA = 'N' or 'n' then
LDA must be at least max( 1, m ), otherwise LDA must be at
least max( 1, k ).
What does it mean that it specifies the first dimension of A? Is this like switching between row and column major? Or is this slicing the tensor?
LD stands for leading dimension. BLAS is originally a library of Fortran 77 subroutines and in Fortran matrices are stored column-wise: A(i,j) is immediately followed in memory by A(i+1,j), which is opposite of C/C++ where a[i][j] is followed by a[i][j+1]. In order to access element A(i,j) of a matrix that has dimensions A(LDA,*) (which reads as LDA rows and an unspecified number of columns), you need to look (j-1)*LDA + (i-1) elements from the beginning of the matrix (Fortran arrays are 1-indexed by default), therefore you need to know the value of LDA. You don't need to know the actual number of columns, therefore the * in the dummy argument.
It is the same in C/C++. If you have a 2D array declared as a[something][LDA], then element a[i][j] is located i*LDA + j positions after the start of the array, and you only need to know LDA - the value of something does not affect the calculation of the address of a[i][j].
Although GEMM operates on an M x K matrix A, the actual data may be embedded in a bigger matrix that is LDA x L, where LDA >= M and L >= K, therefore the LDA is specified explicitly. The same applies to LDB and LDC.
BLAS was developed many years ago when computer programming was quite different than what it is today. Memory management, in particular, was not as flexible as it is nowadays. Allocating one big matrix and then using and reusing portions of it to store smaller matrices was the norm. Also, GEMM is extensively used in, e.g., iterative algorithms that work on various sub-matrices and it is faster to keep the data in the original matrix and just specify the sub-matrix location and dimension, so you need to provide both dimensions.
Starting with Fortran 90, the language has array slicing and automatic array descriptors that allow one to discover both the dimensions of a slice and those of the bigger matrix, so if GEMM was written in Fortran 90 or later, it wouldn't be that verbose in respect to its arguments. But even if that was the case, C doesn't have array descriptors, so you'll still have to provide all those arguments in order to make GEMM callable from C. In C++, one can hide the descriptor inside a matrix class, and many math libraries actually do so (for example, Scythe).
I am trying to do a 1D IFFT transformation of a complex input array with a conjugate even symmetry, with z(1) and z(N/2+1) being real. The total size of the array is N=256. If I prepare the IFFT like the following:
stat = DftiCreateDescriptor( desc_handle, DFTI_DOUBLE, DFTI_REAL, 1,256)
stat = DftiSetValue(desc_handle, DFTI_CONJUGATE_EVEN_STORAGE, DFTI_COMPLEX_COMPLEX)
stat = DftiSetValue(desc_handle, DFTI_PLACEMENT, DFTI_NOT_INPLACE)
stat = DftiComputeBackward(desc_handle, X_in, M_out)
... where X_in has the conjugate symmetry even described above. That means that M_out is expected to be a mathematical real array in the sense that if:
real(dp) :: M_out(N+2)
then the expected real fortran array with have every other element equal to zero.
complex(dp) :: M_out(N/2)
then the expected complex fortran array will have N/2 size with the imaginary part being zero.
However the results I get are not real after doing the above. It is like the routines do not understand that the input complex fortran array does not have the conjugate even symmetry. Why is that? Do I have to add any other preference parameters to ensure the structure of the input is read correctly?
In this example forward domain is real and backward domain is conjugate even with complex storage. Therefore MKL expects that X_in is of type Complex[] and M_out is of type Real[]. Results are real.
I suspect, that you supplied a complex array as M_out. Then this array is interpreted as Real[] and contains real results of the backward transform. No zeroes for imaginary part are inserted.
I have
module mymod
contains
subroutine mysub(matrix_dum, i_size, j_size)
integer :: i, j, i_size, j_size
real(8), dimension(:,:) matrix_dum
do j=1, j_size
do i = 1, i_size
matrix_dum(i,j) = 11.d0*matrix_dum(i,j)
end do
end do
end subroutine mysub
end module mymod
program main
use mymod
implicit none
real(8), dimension(:,:,:), pointer :: matrix
integer :: i, num_matrices, i_size, j_size
num_matrices = 11
i_size = 5000
j_size = 6000
!only one of them are uncommented in actual practice
!I have two choices this choice takes a very very long time
allocate(matrix(num_matrices,i_size,j_size))
matrix = 11.d0
do i = 1, num_matrices
call mysub(matrix(i,:,:),i_size,j_size)
end do
!this one does the same job instantly
allocate(matrix(i_size,j_size,num_matrices))
matrix = 11.d0
do i = 1, num_matrices
call mysub(matrix(:,:,i),i_size,j_size)
end do
deallocate(matrix)
end program main`
Why does the second work as I expected but the first does not. I know it must be the way Fortran stores multidimensional arrays in a single line with memory locations one after the other. But I am not sure about my syntax. Am I correctly passing the addresses of the matrices? or am I telling it to copy the entire matrix instead of giving it the address. How do you pass the pointer to a section of a multidimensional array? what is going on here?
Typically Fortran processors store arrays in the array element order defined by the language - such that the left most subscript varies fastest as you move from element to element.
So all the elements of matrix(:,:,1) will be contiguous - located next to each other.
The elements of matrix(1,:,:) will not be contiguous if SIZE(matrix,1) /= 1.
Operations on arrays that are not in array element order or that are not contiguous are often slower (e.g. they may be less cache friendly or may, in some cases, require the construction of intermediate temporary arrays).
I want to assign complex array as variable.
My code is like
complex indx(3,3)
integer i,j
do i=1,3
do j=1,3
indx(i,j) = (i,j)
write(*,*) indx(i,j)
end do
end do
and in this case I am getting an error like
A symbol must be a defined parameter in this context. [I]
indx(i,j) = (i,j)
You must use function cmplx to build a complex value you want to assign.
complex indx(3,3)
integer i,j
do i=1,3
do j=1,3
indx(i,j) = cmplx(i,j)
write(*,*) indx(i,j)
end do
end do
The syntax you tried is only valid for constant literals.
The answer by Vladimir F tells the important part: for (i,j) to be a complex literal constant i and j must be constants.1 As stated there, the intrinsic complex function cmplx can be used in more general cases.
For the sake of some variety and providing options, I'll look at other aspects of complex arrays. In the examples which follow I'll ignore the output statement and assume the declarations given.
We have, then, Vladimir F's correction:
do i=1,3
do j=1,3
indx(i,j) = CMPLX(i,j) ! Note that this isn't in array element order
end do
end do
We could note, though, that cmplx is an elemental function:
do i=1,3
indx(i,:) = CMPLX(i,[(j,j=1,3)])
end do
On top of that, we can consider
indx = RESHAPE(CMPLX([((i,i=1,3),j=1,3)],[((j,i=1,3),j=1,3)]),[3,3])
where this time the right-hand side is in array element order for indx.
Well, I certainly won't say that this last (or perhaps even the second) is better than the original loop, but it's an option. In some cases it could be more elegant.
But we've yet other options. If one has compiler support for complex part designators we have an alternative for the first form:
do i=1,3
do j=1,3
indx(i,j)%re = i
indx(i,j)%im = j
end do
end do
This doesn't really give us anything, but note that we can have the complex part of an array:
do i=1,3
indx(i,:)%re = [(i,j=1,3)]
indx(i,:)%im = [(j,j=1,3)]
end do
or
do i=1,3
indx(i,:)%re = i ! Using scalar to array assignment
indx(i,:)%im = [(j,j=1,3)]
end do
And we could go all the way to
indx%re = RESHAPE([((i,i=1,3),j=1,3))],[3,3])
indx%im = RESHAPE([((j,i=1,3),j=1,3))],[3,3])
Again, that's all in the name of variety or for other applications. There's even spread to consider in some of these. But don't hate the person reviewing your code.
1 That's constants not constant expresssions.
Consider the following:
program main
integer, parameter :: n=10, m=20
integer ints(n,m)
real floats(m,n)
!... initialize ints
! ...
floats=transpose(ints)
!... do stuff with floats
end
looking at the documentation for gfortran, it seems that transpose(ints) will return an integer array which will then be cast to reals. In this operation, the compiler (gfortran) creates a temporary array for the transposed array which seems like a waste (compile with gfortran -O3 -Warray-temporaries -o test test.f90). Also note that if you change the real array "floats" into an integer array, the warning goes away.
Is there a way to do this (for arbitrary types) without generating a temporary array? (I also tried floats(:,:)=transpose(ints) because I read somewhere that it mattered ... ). Does it behave this way with other compilers?
You could try
floats = transpose(real(ints))
but I wouldn't be very surprised if gfortran (or any other compiler) generated a temporary array to implement this. I'd be more surprised if it didn't.
You might also try
forall (J=1:N, K=1:M) floats(K, J) = real(ints(J, K))
Again, I wouldn't be surprised if a compiler created a temporary array to implement this.
do i = 1, n
do j = 1, m
floats(j,i) = real(ints(i,j))
enddo
enddo
You could make your own transpose interface for handling different data types, although it would have to be a subroutine and not a function.
interface transpose_
module procedure transpose_ints_to_reals
end interface
subroutine transpose_ints_to_reals(ints_in, reals_out)
...
end subroutine
call transpose_(ints,floats)