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