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