Paul,
Thanks. I'll add it to the FAQ
Barry
On Wed, 29 Aug 2007, Paul T. Bauman wrote:
> Hi Barry,
>
> To preface, I sincerely appreciate your prompt response and willingness to
> produce quick fixes.
>
> However, it was pointed out to me in my office today (by someone who knows
> more about interfacing C and FORTRAN than I and who watches the petsc-users
> list) that the following code would have been the correct way for me to do
> this (I tested and it works on intel and g95):
>
> call PetscPrintf(PETSC_COMM_WORLD,
> "==============================================="//achar(10), ierr)
> call PetscPrintf(PETSC_COMM_WORLD, " Beginning of
> Program"//achar(10), ierr)
> call PetscPrintf(PETSC_COMM_WORLD,
> "==============================================="//achar(10), ierr)
>
> 'achar' is a FORTRAN intrinsic function that gets fed an integer and returns
> the corresponding ascii character from the ascii character set. In this case,
> 10 corresponds to the new line command and thus passes the correct format to
> the C call. I tested on the reverted version of zmprint.c and it works
> correctly (although it also works correctly with the patch you sent).
>
> I wanted to share out of the sake of proliferation of knowledge (and not to
> make you feel like I wasted your time). Thanks again for your efforts,
> especially to us lingering FORTRAN'ers. Hopefully this will clarify in the
> future if it ever comes up again. Sorry for the trouble.
>
> Paul
>
> Barry Smith wrote:
> > Paul,
> >
> > I have pushed a fix to petsc-dev that resolves this problem. If you are
> > not using petsc-dev you can simply replace the file
> > src/sys/fileio/ftn-custom/zmprintf.c with the attached file then run make
> > lib shared in that directory then relink your program.
> >
> > Barry
> >
> >
> > On Tue, 28 Aug 2007, Paul T. Bauman wrote:
> >
> >
> > > Hello,
> > >
> > > Kind of a non-numerical question - sorry. I'm using PetscPrintf from
> > > Fortran
> > > using the following calling sequence (for example):
> > >
> > > call PetscPrintf(PETSC_COMM_WORLD,
> > > "=============================================== \n", ierr)
> > > call PetscPrintf(PETSC_COMM_WORLD, " Beginning of
> > > Program
> > > \n", ierr)
> > > call PetscPrintf(PETSC_COMM_WORLD,
> > > "=============================================== \n", ierr)
> > >
> > > On my mac laptop (PowerPC) with PETSc 2.3.2-p7 compiled with gcc 4.0.1 and
> > > g95, this prints as expected:
> > >
> > > ===============================================
> > > Beginning of Program
> > > ===============================================
> > >
> > > On a linux workstation (AMD Opteron) with PETSc 2.3.2-p7 compiled with
> > > icc,
> > > icxx, ifort 9.1, the "\n" is treated as a character and not treated as
> > > "move
> > > to new line" so the output is all on one line:
> > >
> > > =============================================== \n Beginning
> > > of
> > > Program \n=============================================== \n
> > >
> > > While not the end of the world, it is a bit annoying. Am I screwing up the
> > > calling sequence and just got lucky with g95? Or a bug (PETSc or Intel)?
> > >
> > > Thanks,
> > >
> > > Paul
> > >
> > > P.S. The reason why I care is because on any compiler I've used (other
> > > than
> > > Intel), write(*,*) prints out at different times and not in sequence with
> > > PETSc so all my output comes out after PETSc is done outputting. Using
> > > PetscPrintf, I can have everything print out in order.
> > >
> > >
>
>