PetscPrintf/ifort 9.1

[Paul T. Bauman]

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.
>>
>>