PetscPrintf/ifort 9.1

[Stephan Kramer]

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).
While this may work for you, it is certainly not *the* correct way to do 
it. achar(10) corresponds to LF, whereas windows systems
expect CR+LF (i.e. achar(13)//achar(10)), it may still work under 
windows as well though, depends on your terminal/ application
you view the output with. The correct way in C is really to use \n (and 
in the above case I guess), and in fortran to use two
separate write statements.

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