[petsc-users] VecGetArrayReadF90 with gfortran

[Satish Balay]

Have you compiled the my modified code with petsc makefile that I provided?

I've check with - but I can't reproduce this problem.

balay at es^/sandbox/balay/test $ gfortran --version
GNU Fortran (GCC) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Satish


On Fri, 23 Mar 2018, Samuel Lanthaler wrote:

> Thank you very much for your effort Satish. It appears that even in your
> version of the example, I'm having the same problem with a pointer that is not
> properly assigned. Seems weird, I also tried recompiling petsc, but that gave
> me the same. The configure file for petsc is also attached.
> 
> Btw. It appears the latest version of gfortran I have access to on my work
> station is gcc-6.3.
> 
> >> mpif90 --version
> GNU Fortran (GCC) 6.3.0
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Does anyone maybe have any ideas?
> 
> Thanks,
> 
> Samuel
> 
> 
> On 03/23/2018 05:42 PM, Satish Balay wrote:
> > Attaching the modified version that works with complex [using complex build
> > of petsc]
> >
> > BTW: I'm using the following gfortran [but I don't think the version makes
> > any difference] with petsc-3.8 (maint branch):
> >
> > $ gfortran --version
> > GNU Fortran (GCC) 8.0.1 20180222 (Red Hat 8.0.1-0.16)
> >
> > Satish
> >
> > --------
> >
> > balay at asterix /home/balay/download-pine
> > $ make ex2f
> > mpif90 -c -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g
> > -I/home/balay/petsc/include -I/home/balay/petsc/arch-cmplx/include    -o
> > ex2f.o ex2f.F90
> > mpif90 -Wall -ffree-line-length-0 -Wno-unused-dummy-argument -g   -o ex2f
> > ex2f.o  -Wl,-rpath,/home/balay/petsc/arch-cmplx/lib
> > -L/home/balay/petsc/arch-cmplx/lib
> > -Wl,-rpath,/home/balay/soft/mpich-3.3b1/lib
> > -L/home/balay/soft/mpich-3.3b1/lib
> > -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/8
> > -L/usr/lib/gcc/x86_64-redhat-linux/8 -lpetsc -llapack -lblas -lX11 -lpthread
> > -lm -lmpifort -lgfortran -lm -lgfortran -lm -lquadmath -lmpicxx -lstdc++ -lm
> > -Wl,-rpath,/home/balay/soft/mpich-3.3b1/lib
> > -L/home/balay/soft/mpich-3.3b1/lib
> > -Wl,-rpath,/usr/lib/gcc/x86_64-redhat-linux/8
> > -L/usr/lib/gcc/x86_64-redhat-linux/8 -ldl
> > -Wl,-rpath,/home/balay/soft/mpich-3.3b1/lib -lmpi -lgcc_s -ldl
> > /usr/bin/rm -f ex2f.o
> > balay at asterix /home/balay/download-pine
> > $ ./ex2f
> >   setting values
> >   assembling vector
> >   copying vector to array
> >   N =           10
> >   m =           10
> >   getting vecX size
> >   getting ownership range
> >   ownership range:            0          10
> >   copy values to global array
> >   vecX_pt:
> >   SIZE =           10
> >                    (1.0000000000000000,0.0000000000000000)
> >                    (2.0000000000000000,0.0000000000000000)
> >                    (3.0000000000000000,0.0000000000000000)
> >                    (4.0000000000000000,0.0000000000000000)
> >                    (5.0000000000000000,0.0000000000000000)
> >                    (6.0000000000000000,0.0000000000000000)
> >                    (7.0000000000000000,0.0000000000000000)
> >                    (8.0000000000000000,0.0000000000000000)
> >                    (9.0000000000000000,0.0000000000000000)
> >                    (10.000000000000000,0.0000000000000000)
> >   copy_buffer =
> >                    (1.0000000000000000,0.0000000000000000)
> >                    (2.0000000000000000,0.0000000000000000)
> >                    (3.0000000000000000,0.0000000000000000)
> >                    (4.0000000000000000,0.0000000000000000)
> >                    (5.0000000000000000,0.0000000000000000)
> >                    (6.0000000000000000,0.0000000000000000)
> >                    (7.0000000000000000,0.0000000000000000)
> >                    (8.0000000000000000,0.0000000000000000)
> >                    (9.0000000000000000,0.0000000000000000)
> >                    (10.000000000000000,0.0000000000000000)
> >   calling allreduce
> >   buffer =
> >                    (1.0000000000000000,0.0000000000000000)
> >                    (2.0000000000000000,0.0000000000000000)
> >                    (3.0000000000000000,0.0000000000000000)
> >                    (4.0000000000000000,0.0000000000000000)
> >                    (5.0000000000000000,0.0000000000000000)
> >                    (6.0000000000000000,0.0000000000000000)
> >                    (7.0000000000000000,0.0000000000000000)
> >                    (8.0000000000000000,0.0000000000000000)
> >                    (9.0000000000000000,0.0000000000000000)
> >                    (10.000000000000000,0.0000000000000000)
> > balay at asterix /home/balay/download-pine
> > $
> >
> > On Fri, 23 Mar 2018, Satish Balay wrote:
> >
> >> I'm attaching the modified code - that appears to work fine for me. My
> >> changes are:
> >>
> >> 1. use .F90 suffix - so the compiler does the f90 freeform/preprocessing
> >> automatically
> >> 2. remove slepc references and use petsc only
> >> 3. compile with a petsc formatted makefile
> >> 4. replace complex with real*8 - thats compatible with PetscScalar
> >>
> >> So perhaps you can modify your version of test code - to be closer to
> >> this one [or vice versa] to see what is triggering the difference in
> >> behavior.
> >>
> >> Satish
> >>
> >> On Fri, 23 Mar 2018, Samuel Lanthaler wrote:
> >>
> >>> Hi all,
> >>>
> >>> I am having trouble using the function VecGetArrayReadF90 under gfortran.
> >>> I
> >>> have created a minimal example and put it in the attachment. Basically, it
> >>> appears that the input pointer is empty upon return from
> >>> VecGetArrayReadF90. The code runs fine, when compiled with ifort, so I
> >>> don't know what's going on.
> >>>
> >>> I am attaching the code and makefile that I used, as well as the command
> >>> line output that I can see. Though the errors are just to do with the fact
> >>> that the output pointer is empty, so the command line output is not all
> >>> that helpful...
> >>>
> >>> Thanks in advance for your help!
> >>> Sam
> >>>
> 
>