In the given code below, the value of total_data=fftw_alloc_complex(alloc) should be double the value of alloc. For nn = 16, when I run this code with mpi in 2 cores, the value of alloc is 1152, so total_data must be 2304 for both cores, but it gives 94157412191808 for core 0 and 93907390824000 for core 1. All the required variables for the main program and for FFTW3 and MPI are defined in module_mhd_pl. I properly linked the required libraries for MPI and FFTW3 in a makefile.

program fft_test_mpi_3d
use module_mhd_pl
use, intrinsic :: iso_c_binding
implicit none
integer:: i1, i2, i3, size, rnk
real*8,allocatable,dimension(:,:,:) :: x
character(len=80) :: fname
real*8:: mytime,rank

! Initialize MPI
call mpi_init(ierr)
call mpi_comm_rank(mpi_comm_world, myrank,ierr)
call mpi_comm_size(mpi_comm_world, nprocs, ierr)
! call fftw_mpi_init()

n1 = 16
n2 = 16
n3 = 16
n1hf = n1/2+1

! Compute local size for array

alloc = fftw_mpi_local_size_3d(n3,n2,n1/2+1, &
mpi_comm_world,local_n3,local_i3_start)

! This function creates an error
total_data = fftw_alloc_complex(alloc)

! Allocate memory for inp and outp arrays
allocate(inp(n1 + 2, n2, local_n3))
allocate(outp(n1hf, n2, local_n3))

call c_f_pointer (total_data,inp,[n1+2,n2,local_n3])
call c_f_pointer (total_data,outp,[n1hf,n2,local_n3])
print*, n1hf,alloc,total_data,local_n3,local_i3_start,myrank

! Create local FFTW plan
pfor = fftw_mpi_plan_dft_r2c_3d(n3, n2, n1, inp, outp, &
mpi_comm_world, FFTW_MEASURE)

! Create local Inverse FFTW plan
pinv = fftw_mpi_plan_dft_c2r_3d(n3, n2, n1, outp, inp, &
mpi_comm_world, FFTW_MEASURE)
! allocate(x(n1+2,n2,local_n3))
x = 0.0d0

call mpi_barrier(mpi_comm_world,ierr)
write(*,*)'step=1'
write(fname,'(g8.0)')myrank+1
open(unit=10,file='input'//trim(adjustl(fname))//'.dat', &
status='unknown')
do i3_loc = 1, local_n3
i3 = i3_loc + local_i3_start
do i2 = 1, n2
do i1 = 1, n1hf
ireal = 2*i1-1
iimag = 2*i1
x(ireal,i2,i3) = dble(i1+i2+i3+myrank+1.0d0)
x(iimag,i2,i3) = dble(i1+i2+i3+myrank+2.0d0)
write(10,*) x(ireal,i2,i3),x(iimag,i2,i3)
end do
end do
end do

call mpi_barrier(mpi_comm_world,ierr)
write(*,*)'step=2'
! Execute local FFTW plan
inp = x
call forward_fftw
x = inp

call mpi_barrier(mpi_comm_world,ierr)
write(*,*)'step=3'

write(fname,'(g8.0)')myrank+1
open(unit=11,file='Test'//trim(adjustl(fname))//'.dat', &
form='formatted',status='unknown')
do i3 = 1, local_n3
do i2 = 1, n2
do i1 = 1, n1
write(11,*) x(i1,i2,i3)
enddo
enddo
enddo
close(11)

! Execute local Inverse FFTW plan
inp = x
call backward_fftw
x = inp

deallocate(x)

! Destroy local FFTW plan
call fftw_destroy_plan(pfor)
call fftw_destroy_plan(pinv)
call fftw_free(total_data)

! Finalize FFTW3
! call fftw_mpi_cleanup()

! Clean up MPI interface
call MPI_FINALIZE(ierr)

end program

fftw_alloc_complex returns a type(C_PTR).

https://developer.arm.com/documentation/101004/2100/Fast-Fourier-Transforms-FFTs/FFT-memory-functions/fftw-alloc-complex

It doesn't seem to be declared in the code shown.

The values you indicate seem not unusual for 64 bit pointers.

On Wednesday, August 2, 2023 at 1:27:17 PM UTC+5:30, gah4 wrote:
> fftw_alloc_complex returns a type(C_PTR).
>
> https://developer.arm.com/documentation/101004/2100/Fast-Fourier-Transforms-FFTs/FFT-memory-functions/fftw-alloc-complex
>
> It doesn't seem to be declared in the code shown.
>
> The values you indicate seem not unusual for 64-bit pointers.

I included fftw3.f03 file in which fftw_allloc_complex function is defined and required variables were declared in module_mhd_pl subroutine like this:

integer(C_SIZE_T)::alloc
type(C_PTR) :: total_data

On Thursday, August 3, 2023 at 10:59:11 PM UTC-7, Pratik Patel wrote:

(snip)

> I included fftw3.f03 file in which fftw_allloc_complex function is defined and required variables were declared in module_mhd_pl subroutine like this:
>
> integer(C_SIZE_T)::alloc
> type(C_PTR) :: total_data

Sounds right.

Why is call

fftw_mpi_init()

commented out?

That initializes many things needed before any other fftw_mpi calls.

On Friday, August 4, 2023 at 5:23:15 PM UTC+5:30, gah4 wrote:
> On Thursday, August 3, 2023 at 10:59:11 PM UTC-7, Pratik Patel wrote:
>
> (snip)
> > I included fftw3.f03 file in which fftw_allloc_complex function is defined and required variables were declared in module_mhd_pl subroutine like this:
> >
> > integer(C_SIZE_T)::alloc
> > type(C_PTR) :: total_data
> Sounds right.
>
> Why is call
>
> fftw_mpi_init()
>
> commented out?
>
> That initializes many things needed before any other fftw_mpi calls.

I tried with that also but it didn't work either. I think fftw_alloc_compex doesn't require mpi initialization,
so no need to initialize fftw_mpi_init().

On Friday, August 4, 2023 at 6:51:27 AM UTC-7, Pratik Patel wrote:
> On Friday, August 4, 2023 at 5:23:15 PM UTC+5:30, gah4 wrote:

(snip)
> > Why is call

> > fftw_mpi_init()
> > commented out?

> I tried with that also but it didn't work either. I think fftw_alloc_compex doesn't require mpi initialization,
> so no need to initialize fftw_mpi_init().

As far as I know, you need fftw_mpi_init() even for calls that don't use MPI.

You are, at least supposed to, call it before any other fftw_mpi_... routine.

It might allocate some arrays, or some such, and those might be used by others.

On Saturday, August 5, 2023 at 12:01:34 AM UTC+5:30, gah4 wrote:
> On Friday, August 4, 2023 at 6:51:27 AM UTC-7, Pratik Patel wrote:
> > On Friday, August 4, 2023 at 5:23:15 PM UTC+5:30, gah4 wrote:
> (snip)
> > > Why is call
>
> > > fftw_mpi_init()
>
> > > commented out?
> > I tried with that also but it didn't work either. I think fftw_alloc_compex doesn't require mpi initialization,
> > so no need to initialize fftw_mpi_init().
> As far as I know, you need fftw_mpi_init() even for calls that don't use MPI.
>
> You are, at least supposed to, call it before any other fftw_mpi_... routine.
>
> It might allocate some arrays, or some such, and those might be used by others.

Actually, I am using another's code as a reference in which he didn't initialize fftw_mpi_init()

and it is working perfectly fine

On 8/5/2023 5:28 AM, Pratik Patel wrote:
> On Saturday, August 5, 2023 at 12:01:34 AM UTC+5:30, gah4 wrote:
>> On Friday, August 4, 2023 at 6:51:27 AM UTC-7, Pratik Patel wrote:
>>> On Friday, August 4, 2023 at 5:23:15 PM UTC+5:30, gah4 wrote:
>> (snip)
>>>> Why is call
>>
>>>> fftw_mpi_init()
>>
>>>> commented out?
>>> I tried with that also but it didn't work either. I think fftw_alloc_compex doesn't require mpi initialization,
>>> so no need to initialize fftw_mpi_init().
>> As far as I know, you need fftw_mpi_init() even for calls that don't use MPI.
>>
>> You are, at least supposed to, call it before any other fftw_mpi_... routine.
>>
>> It might allocate some arrays, or some such, and those might be used by others.
>
> Actually, I am using another's code as a reference in which he didn't initialize fftw_mpi_init()
>
> and it is working perfectly fine

It is probably best to understand from the documentation whether it is
recommended to always use the init procedure. It is the case that often
any specific procedure may not depend on the initialization, but you
don't really know for sure unless you have the code to peruse. I
personally would consider it to be bad design on the part of the mpi
package if it did depend on initialization and then didn't complain when
the procedure is called (with possible option to disable that checking
for performance reasons). I've used several packages, including
graphics APIs that require such initialization regardless of whether the
specific function requires it or not. It is simply part of the GUI
template in a "better safe than sorry" structure.

On Saturday, August 5, 2023 at 7:55:52 AM UTC-7, Gary Scott wrote:
> On 8/5/2023 5:28 AM, Pratik Patel wrote:

(snip)
> > Actually, I am using another's code as a reference in which he didn't initialize fftw_mpi_init()
> > and it is working perfectly fine

> It is probably best to understand from the documentation whether it is
> recommended to always use the init procedure. It is the case that often
> any specific procedure may not depend on the initialization, but you
> don't really know for sure unless you have the code to peruse.

Especially, just because a program works, doesn't mean that the things
that it does are right.

Often enough, you can use elements outside an array without actual problems..
You might store into another array that you aren't using.

As well as I understand it, there are some arrays that get initialized.

On Saturday, 5 August 2023 at 20:28:37 UTC+10, Pratik Patel wrote:
> On Saturday, August 5, 2023 at 12:01:34 AM UTC+5:30, gah4 wrote:
> > On Friday, August 4, 2023 at 6:51:27 AM UTC-7, Pratik Patel wrote:
> > > On Friday, August 4, 2023 at 5:23:15 PM UTC+5:30, gah4 wrote:
> > (snip)
> > > > Why is call
> >
> > > > fftw_mpi_init()
> >
> > > > commented out?
> > > I tried with that also but it didn't work either. I think fftw_alloc_compex doesn't require mpi initialization,
> > > so no need to initialize fftw_mpi_init().
> > As far as I know, you need fftw_mpi_init() even for calls that don't use MPI.
> >
> > You are, at least supposed to, call it before any other fftw_mpi_... routine.
> >
> > It might allocate some arrays, or some such, and those might be used by others.
> Actually, I am using another's code as a reference in which he didn't initialize fftw_mpi_init()
>
> and it is working perfectly fine
..
That doesn't prove anything.
Uninitialized variables contain junk values.
Junk can be anything -- it could be zero, or it could be very small values.
Such values, of used, might not show up as wrong values in the result.
It won't hurt to initialize the variables. Try it anyway.