0

Dear Stack over flow community, I am running a simple simulation with KPP processor and after the 9th output .dat file (out of 150) the simulation terminates with the following error message:

forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write

Compiler used: Intel Fortran Compiler 2022.2.1 .

This might be the part of the Fortran code involved:

 * OPEN( unit=10, file="dyno_"//ex_no(1)//ex_no(2)//ex_no(3)//".dat")

......
......

  INTEGER i

      WRITE(10,999) (TIME-TSTART)/3600.D0,  &
                   (C(LOOKAT(i))/CFACTOR, i=1,NLOOKAT)
999   FORMAT(E24.16,100(1X,E24.16))*

I hope you can help with that.

Thank you in advance.

I tried checking the WRITE statement in the Fortran Integrator.f90 script but I did not find enough resources inline to check exactly what the problem was.


Maybe this longer description helps:

After successfully compiling a Makefile, with Intel Fortran Compiler 2022.2.1, with the options suggested by chw21, I get an executable file called dynho.exe.

In order to get the desired output I execute dynho.exe with the ./ command. The output should be made of 150 .dat files, because the simulation uses 150 different sets of initial conditions.

The simulation runs but terminated after producing only 9 out of 150 expected .dat files.

The execution of the dynho.exe has been made submitting the salloc script in bwunicluster:

#!/bin/bash  
#SBATCH   --nodes=1
#SBATCH   --cpus-per-task=5
#SBATCH   --mem=600mb
#SBATCH   --time=27:00:00           
#SBATCH   -J  test_bwbatch               # Specify job name
#SBATCH   --mail-user=blablabla@kit.edu
#SBATCH   --mail-type=BEGIN,END,FAIL

echo "Start kpp script execution at $(date)"

./dynho.exe

which produces a .out file. This is the part where the forrtl error is mentioned:

forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write
Image              PC                Routine            Line        Source
dynho.exe          0000000000455A3A  Unknown               Unknown  Unknown
dynho.exe          0000000000454737  Unknown               Unknown  Unknown
dynho.exe          0000000000408629  dynho_util_mp_ini          66  dynho_Util.f90
dynho.exe          0000000000430EE6  MAIN__                     82  dynho_Main.f90
dynho.exe          000000000040385D  Unknown               Unknown  Unknown
libc-2.28.so       000014B9B1F6D493  __libc_start_main     Unknown  Unknown
dynho.exe          000000000040377E  Unknown               Unknown  Unknown

============================= JOB FEEDBACK =============================

NodeName=uc2n501
Job ID: 21896960
Cluster: uc2
User/Group: ii5664/imk-tro
State: FAILED (exit code 66)
Nodes: 1
Cores per node: 6
CPU Utilized: 00:12:52
CPU Efficiency: 9.02% of 02:22:36 core-walltime
Job Wall-clock time: 00:23:46
Memory Utilized: 5.89 MB
Memory Efficiency: 0.98% of 600.00 MB

I could post the dynho_Util.f90 and dynho_Main.f90 routines but I would not to overwhelm the post.

This is part of the dynho_Util.f90 :

     SUBROUTINE InitSaveData (j)

      USE dynho_Parameters
      INTEGER    :: j
      CHARACTER  :: ex_no(3)

      ex_no(1:2) = '000'

   
       IF(j.lt.10) then
          WRITE(ex_no(3),4) j
4         FORMAT(i1) 
       ELSEIF (j.ge.10.and.j.lt.100) then          
          WRITE(ex_no(2:3),5) j     !! This is line 66  !!
5         FORMAT(i2) 
       ELSE
          WRITE(ex_no(:),6) j
6         FORMAT(i3)
       END IF

      OPEN( unit=10, file="dynho_"//ex_no(1)//ex_no(2)//ex_no(3)//".dat")
    !  open(10, file='dynho.dat')

      END SUBROUTINE InitSaveData

This dynho_Util.f90 routine is a bit longer but I guess the relevant part should be this one.

GiorgioT
  • 1
  • 2
  • 2
    Welcome, please take the [tour] and read [ask]. You should really show more code. At the very least, all variables should be declared, but very often a full [mre] is actually necessary. Please note that the relevant write is in an **internal** write so the line you are showing is probably not the right one and you will really have to show more. An internal write is where one write into a character string. – Vladimir F Героям слава Mar 09 '23 at 10:41
  • 2
    @GiorgioT, OK let's have a look at dynho_Util.f90, especially the bit around line 66. Funny that you get the first 9 files ... how are you setting up their names? – lastchance Mar 09 '23 at 19:18
  • lastchance is right, the overflow likely happens when setting-up the `ex_no` array. We have many questions and answers about numbered file names https://stackoverflow.com/questions/1262695/convert-integers-to-strings-to-create-output-filenames-at-run-time (check all the duplicates linked there). If you want a specific answer about your problems, you simply have to show the relevant code. Read [mcve]. It will be around line 66. It pays off to learn to read the error messages and backtraces. – Vladimir F Героям слава Mar 10 '23 at 07:20

2 Answers2

2

The internal write is writing to part of the variable

character :: ex_no(3)

This is a character array, extent 3, length 1. In the internal write

write(ex_no(1:2), '(I2)') 10

we are pointing to two records in the internal file, ex_no(1) and ex_no(2).1 The write, though, is writing just one record, so transfers to just ex_no(1). But, ex_no(1) is a character of length 1 and writing two characters to that ("10") is too many.

This is the reason for the fault.

Correcting this involves a complete rewrite of the logic, as you should be using a scalar character of length 3, and using a format like (I3.3) instead of those convoluted conditionals. You can read about the correct way to generate files like this in another question and its answers.


1 When using an array in an internal file, each element of the array is one distinct record in the transfer operation.

francescalus
  • 30,576
  • 16
  • 61
  • 96
1

I agree with Vladimir, you should give more information. I don't think that the line(s) you presented contain the error. In the line above you write to a file on unit 10, but the error references an internal write on unit -5.

This usually happens when you try to write to a string variable, but the content to be written is too large, something like this:

program overflow
    implicit none
    character(len=10) :: some_string
    write(some_string, *) "Some content longer than", 10, "characters"
end program overflow

I have encountered that recently in such a situation:

character(len=256) :: fullname
character(len=200) :: dirpath, filename

write(fullname, "(A, A1, A)") trim(dirpath), "/", filename

Because filename wasn't trimmed, only 55 characters of the dirpath variable remained before the hundred-plus trailing spaces of filename became too long for fullname to handle. This went fine while the path to the directory contained less than 56 characters, but suddenly broke when it was 59.

I would suggest compiling with the options: -O0 -g -traceback which will give you the specific line where this happens.

chw21
  • 7,970
  • 1
  • 16
  • 31