0

I have a program, written in fortran90, that is writing an array to a file, but for some reason is using an asterix to represent multiple columns:

8*9,  4,  2*9,  4

later on reading from the file I am getting I/O errors:

lib-4190 : UNRECOVERABLE library error

A numeric input field contains an invalid character.

Encountered during a list-directed READ from unit 10 Fortran unit 10 is connected to a sequential formatted text file:

Does anyone have any idea why this is happening, and if there is a flag to feed to the compiler to prevent it. I'm using the cray fortran compiler, and the write statement looks like this:

write (lun,*) nsf_species(bundle%species(1:bundle%n_prim))

Update:

The line reading in the data file looks like:

read (lun,*) Info(ifile)%alpha_i(1:size)

I have checked to ensure that it is this line that is causing the problem.

Community
  • 1
  • 1

3 Answers3

2

This compression of list-directed output is a very useful feature of the Cray Compilation Environment when writing out large amounts of data. This compressed output will, however, not be read in correctly, as you point out (which is less useful).

You can modify this behaviour, not using a compiler flag but by using the "assign" command.

Consider this sample code:

PROGRAM test
IMPLICIT NONE

INTEGER :: u

OPEN(UNIT=u,FILE="f1",FORM="FORMATTED",STATUS="UNKNOWN")
WRITE(u,*) 0,0,0
CLOSE(u)

OPEN(UNIT=u,FILE="f2",FORM="FORMATTED",STATUS="UNKNOWN")
WRITE(u,*) 0,0,0
CLOSE(u)

END PROGRAM test

We first build with CCE and execute. Files f1 and f2 both contain the compressed output form:

$ ftn -o test.x test.F90 
$ ./test.x 
$ cat f1
 3*0
$ cat f2
 3*0

Now we will use "assign" to modify the format in file f2. First we need to define a filename to hold the assign information:

$ export FILENV=my_filenenv

Now we use assign to switch off the compressed output for file f2:

$ assign -y on f:f2

Now we rerun the experiment (without needing to recompile):

$ ./test.x 
$ cat f1
 3*0
$ cat f2
 0,  0,  0

There are options to do this for all files, for certain filename patterns or many other cases.

There are other things that assign can do. See "man assign" with PrgEnv-cray loaded for more details.

ahart
  • 86
  • 3
  • 1
    You surely mean "list-directed" rather than "unformatted". However, can you explain why this perfectly legitimate input line can't be read? – francescalus Jul 30 '15 at 14:10
  • HI Ahart, thanks for the suggestion. I haven't tried this assign command, as the code outputs the files and reads them back in during a single run. –  Jul 31 '15 at 07:58
  • 1
    @user67257 Try that anyway, it could help changing the file. I still however suppose that the real error is somewhere else. – Vladimir F Героям слава Jul 31 '15 at 08:20
1

The write statement is using list directed formatting (it is still a formatted output statement - "formatted" means "formatted such that a human can read it")- as specified by the * inside the parenthesised part of the statement. The rules for list directed output give a great deal of freedom to the compiler. Typically, if you actually care about the details of the output, you should provide an explicit format.

One of the rules that does apply is that the resulting output should generally be suitable for list directed input. But there are some rather surprising rules for what is permitted as input for list directed formatting. One such feature is that you can specify in the input text a repeat count for an input values using the syntax repeat*value.

The compiler has noticed that there are repeat values in the output, so it has used this repeat count feature.

I don't know why you get an error message when reading the file under list directed input - as the line you show is a valid input line for list directed input. Make sure that the line causing the error is actually the line that you show.

IanH
  • 21,026
  • 2
  • 37
  • 59
  • Hi Ian, thanks for your response. The line causing the error is that above, and as you say I'm not sure why it happens. I thought this was fairly standard, but the error is recent, as it hadn't been happening before. I've emailed the help desk of the system, hopefully they will be able to help. –  Jul 31 '15 at 07:56
1

A simple workaround solution would be to change the write statement so that it does not use the compressed format. e.g. change to:

write (lun,'(*(I5))') nsf_species(bundle%species(1:bundle%n_prim))

The '*' allows an arbitrary number of repeats of the specified format and should suppress the compressed output format.

However, if the compiler outputs in compressed format than it should be able to read back in in the same compressed format. Hopefully the helpdesk will be able to get to the root of why that does not work.

AndyT
  • 491
  • 2
  • 10
  • Hey Andy, thanks for the suggestion. The help-desk actually suggested the same thing, but now the code is writing an inordinate amount of white space with this write statement, but not the data. Not sure why that would happen.... –  Jul 31 '15 at 14:11
  • @user67257 Lots of whitespace would be the result if you missed out the inner parenthesis, i.e. if you had: '(*I5)' rather than: '(*(I5))' Could this just be a typo? – AndyT Aug 03 '15 at 12:53