PetscPrintf/ifort 9.1

[Paul T. Bauman]

Leif Strand wrote:
> Paul,
>
> The "\n" -> linefeed (012) translation is performed by the compiler. 
> Only a C compiler would be expected to do this.  So the key difference 
> here is g95 vs. ifort.
I understand the key difference is g95 vs. Intel - what I don't 
understand is why because I thought all I was doing was passing a 
character string to PetscPrintf and (I assumed) that PetscPrintf made 
appropriate C calls to print the message out. Hence, I assumed that the 
Fortran wrapper was doing something different between the two 
compilers.  I thought perhaps this what was going on (and why I bothered 
to mail the list).  So, what does the PetscPrintf call from FORTRAN do?

> program hello
>     write (*,*) 'Hello,\nworld!'
> end program hello
>
> Compiled with g95, this produces the following output:
>
> $ ./hello
>  Hello,
> world!
> $
That is strange (and not what a write(*,*) should do). Thanks for this 
example.
>
> But compiled with ifort, the escape sequence is interpreted literally:
>
> $ ./hello
>  Hello,\nworld!
> $
>
> I would assume the g95 behavior is non-standard.  (Since I don't 
> really know Fortran, I don't know how to tell a Fortran compiler to 
> embed a newline...)
>
> --Leif
>
>
> Matthew Knepley wrote:
>> On 8/28/07, Paul T. Bauman <pbauman at ices.utexas.edu> 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
>>
>> This is much lower level than PETSc. It is in the C standard. There
>> must be something
>> else going on here. We do this EVERYWHERE in the code. For instance,
>> why would the
>> -ksp_monitor output work. This uses \n in exactly the same way.
>>
>>    Matt
Right, I understand it's C standard (and therefore wouldn't expect C to 
behave any differently), but what's going on in the FORTRAN call? It's 
just passing the character string to the C call and the string being 
interpreted the "C way"? I guess my solution then (considering my P.S.) 
is to us a C routine to do this?

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