Write a matrix same that gfortran

Write a matrix same that gfortran

Hi friends. I'm writing a matrix in file. When I compile with ifort the matrix don't view ok, but when I compile with gfortran is Ok. I don't understand. The test program is:

PROGRAM PRUEBA
REAL, DIMENSION(16,16) :: S
INTEGER :: I,J
OPEN(1,FILE='PRUEBAMATRIZS.dat')
DO I=1,16
DO J=1,16
S(I,J)=I*J
END DO
END DO
DO I=1,16
WRITE(1,*) S(I,:)
END DO
CLOSE(1)
WRITE(*,*)'HEMOS TERMINADO'
END PROGRAM

The file that I get with intel is PRUEBAMATRIZINTELFORTRAN.dat and the file that I get with gfortran is PRUEBAMATRIZGFORTRAN.

How do I get the same result in intel in gfortran?

Thanks,
Regards

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You're using "*" for the format. The Fortran standard allows a compiler maker to do anything they like with the output. You cannot expect 2 different compilers to behave the same.

If you want to control the format, number of data entries per line, and number of digits you must create your own format descriptor.

ron

Ok. In conclusion the problem is free style. I solved it like this:

PROGRAM PRUEBA
REAL, DIMENSION(16,16) :: S
INTEGER :: I,J
OPEN(1,FILE='PRUEBAMATRIZS.dat')
DO I=1,16
DO J=1,16
S(I,J)=I*J
END DO
END DO
DO I=1,16
WRITE(1,20) S(I,:)
20 FORMAT(16F10.3)
END DO
CLOSE(1)
WRITE(*,*)'HEMOS TERMINADO'
END PROGRAM

But, I don't know the number elements, for example:

PROGRAM PRUEBA
REAL, ALLOCATABLE,DIMENSION(:,:) :: S
INTEGER :: I,J,TOTAL
WRITE(*,*)'DIMENSION?'
READ(*,*)TOTAL
ALLOCATE(S(TOTAL,TOTAL))
OPEN(1,FILE='PRUEBAMATRIZS.dat')
DO I=1,TOTAL
DO J=1,TOTAL
S(I,J)=I*J
END DO
END DO
DO I=1,TOTAL
WRITE(1,20) S(I,:)
20 FORMAT(TOTALF10.3)
END DO
CLOSE(1)
WRITE(*,*)'HEMOS TERMINADO'
END PROGRAM

In this last example, the number of columns is total, how can I write well the matrix?
Thanks Ron

with Fortran 90/95 and older, you can use a repeat count for the format specifier. However, it has to be a literal constant, so you must put in a huge repeat count to work for any foreseeable case. This example will print 10 values per line, with up to 16 million element arrays:

...rest of your code...
DO I=1,TOTAL
DO J=1,TOTAL
S(I,J)=I*J
END DO
END DO

WRITE(1,20) S
20 FORMAT(1000000(10F10.3,/))

...rest of your code...

There is a cool new Fortran 2008 feature we've implemented in our Composer XE 2011 compilers. This will only work with our latest compiler. It is the F08 unlimited format repeat count with "*", like this

WRITE(1,20) S
20 FORMAT(*(F10.3,/))

or using much more modern syntax:

write(1,'(*(F10.3,/))') S

the "/" throws a new line.

I don't know if gfortran has implemented the "*" infinite repeat specifier.

I hope this helps.

ron

You can also use a big number, say 1000, if you know the number of values will be less than that.

Steve - Intel Developer Support

The problem is that the dimensions of matrix is unknow. The user write the dimension in terminal. Then, I don't know number of values of columns, in your example, you write ten values for columns, but I don't know if is ten, eleven or hundred....

WRITE(1,20) S
20 FORMAT(1000000(10F10.3,/))

The other possibility is:

WRITE(1,20) S
20 FORMAT(*(F10.3,/))


But, the output is the type:

1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
11.000
12.000
13.000
14.000
15.000
16.000
2.000
4.000
6.000
8.000
10.000
......
And I need to have a matrix, with dimension total*total:
1.0 2.0 3.0 4.0 5.0 ....
17.0 18.0..................

And, write(1,'(*(F10.3,/))') S, produce the same output:

1.000
2.000
3.000
4.000
5.000
6.000
7.000
8.000
9.000
10.000
11.000
12.000
13.000
14.000
15.000
16.000
2.000
4.000
6.000
8.000
10.000

Thanks for your help!

Best Reply

There are a couple of different ways of printing matrices in "natural" format. The simplest way is to use a DO loop in which one row is written at a time, using a large-enough repeat count on the format specification:

DO i=1,NRows
write(*,10)(S(i,j),j=1,NCols)
END DO
10 FORMAT(10000F10.3)

Another way is to use a non-standard extension that is provided in Intel Fortran: VFE (Variable Format Expressions), which are described in the Intel Fortran Reference Manual.

A third method is to build up the output line using internal writes to the proper places in a line-length character variable and, when the line is complete, to output the string.

Along with any method you choose, it is worth considering the writing of a utility subroutine to print matrices the way you want, and call that subroutine whenever you want. This is actually done in some numerical libraries, e.g., IMSL.

Finally, a comment. In the opening message of this thread, you wrote "When I compile with ifort the matrix don't view ok, but when I compile with gfortran is Ok. I don't understand". Such comments are pointless because of the subjective qualifier "ok", unless you also explain what "ok" is supposed to signify, or can claim that the Fortran Standard requires a certain format for the output.

If you use syntax for which the Standard allows implementation-dependent consequences, you may ask how to change the syntax to obtain a desired output format, but you have no justification for saying that one format is "ok" and the other is not so.

Mecej4, in the first place, thanks for your help. Thanks for you, my problem is resolved.
Now, I'm native Spanish, my English is very bad, I'm sorry if the use of 'ok' isn't well. But, My intention was to say that I did not get the result I wanted. I thought I was using the standard, I feel that the title was wrong. Try to change it and to close the issue.
Thanks to Intel, the media and users, are the best.
Thanks, and Regards

It was not my intention to be critical of your English at all.

I merely wanted to point out that the substance of the comment in question was such that no appropriate response could be given. Along the same lines, "..I did not get the result I wanted" without any adjacent clarifications is either ambiguous or assumes that a person reading it knows or can reason out what it is exactly supposed to mean.

I could have mentioned non-advancing I/O as yet another alternative, but I felt that in this instance it would be a dubious choice.

Anyway, I am happy to note, the issue can be considered "solved".

Leave a Comment

Please sign in to add a comment. Not a member? Join today