problem with readinf .mod files

[milenko1976]

I have this:open(23, file='vel.mod', form='unformatted',
+ status='old')
Velocity model is vel.mod but Intel 11.1 sees this binary data as Amiga Sound Tracker Audio.Why?
Of course ,when I try to read it later it is not possible.I tried to rename vel.mod into vel.mdl but it doesn't work too.

[milenko1976]

FD: finite difference traveltime calculation
forrtl: severe (39): error during read, unit 23, file /home/milenko/fast1/nfd/vel.mod
Image PC Routine Line Source
main 00000000004AF21D Unknown Unknown Unknown
main 00000000004ADD25 Unknown Unknown Unknown
main 000000000045CB10 Unknown Unknown Unknown
main 0000000000411A6F Unknown Unknown Unknown
main 00000000004112A2 Unknown Unknown Unknown
main 00000000004240AA Unknown Unknown Unknown
main 000000000040849F Unknown Unknown Unknown
main 000000000040460E Unknown Unknown Unknown
main 000000000040336C Unknown Unknown Unknown
libc.so.6 00007F7861B165A6 Unknown Unknown Unknown
main 0000000000403269 Unknown Unknown Unknown


Gives me error during read???

[mecej4]

The .mod suffix can stand for Fortran module files, sound files (as you noted), Modula source files (as Make thinks), etc. A Fortran compiler has no specialized foreknowledge of the format of binary files. What is the response to the command

$ file vel.mod

?

It is possible that you have a declared MODULE VEL in your source so that, when that Fortran source file is compiled, the resulting module file clobbers your data file of the same name. Then, when your program runs, it tries to read the intended binary data file, but instead is trying to read the module file.

[milenko1976]

Thanks mecej4.Well I get this:
milenko@hp6830s:~/fast1/nfd$ file vel.mod
vel.mod: data

[milenko1976]

I get this for this binaries:
milenko@hp6830s:~/fast1/nfd$ file vel.1d
vel.1d: data
milenko@hp6830s:~/fast1/nfd$ file vel1
vel1: data

[milenko1976]

Is it possible that 64bit CPU can be issue here?

[TimP]

Quoting milenko1976

Is it possible that 64bit CPU can be issue here?

No, but 32- and 64-bit compilers have different .mod file formats.

[Steven_L_Intel1]

What exactly is the problem? The Intel compiler does not associate file types with applications - you are using a separate utility that is simply guessing based on the file type.

[milenko1976]

Who is then associating file with applicaton?

[mecej4]

Who is then associating file with applicaton?

Whichever agent you used to peek into the file -- possibly in some GUI.

I think that we have reached the limit of what can be guessed without seeing some source code, preferably a complete short example.

Unformatted files written by Fortran are often not portable across platforms, OS, compiler, etc. There has to be an exact correspondence between the I/O list items used in the WRITE statements that produced the file and the READ statements that attempt to read the file.

We do not know how the unformatted files that your program is trying to read were produced. Please provide more information.

[milenko1976]

OK.This is part of file model.f
open(23, file='vel.mod', form='unformatted',
+ status='old')
c
c convert the velocity array to velocity/size
c
vmult=.001/size
do 50 k=1,nz
do 50 j=1,ny
read(23) (veli(i),i=1,nx)
do 51 i=1,nx
51 vel(i,j,k)=veli(i)*vmult
50 continue

vel.mod is built this way.
vel1d.in is input ASCII file used by velbuild.f
if(imod.eq.3) then
c
open(10, file='vel1d.in', status='old')
open(12, file='vel1d.out')
c
i=1
100 read(10,*,end=999) zin(i),vin(i)
i=i+1
go to 100
999 npts=i-1
c
do 200 k=1,nz
depth=zmin+float(k-1)*size
do 210 j=2,npts
if(depth.ge.zin(j-1).and.depth.le.zin(j)) then
velocity=(depth-zin(j-1))*(vin(j)-vin(j-1))/
+ (zin(j)-zin(j-1))+vin(j-1)
go to 220
end if
210 continue
write(6,3)
3 format(/'*** 1D profile not shallow or deep enough ***'/)
stop
220 do 230 i=1,nx
do 230 j=1,ny
230 vel(i,j,k)=velocity
write(6,4) depth,velocity
write(12,4) depth,velocity
4 format(2f10.3)
200 continue
end if
open(unit=36, file='vel.mod', form='unformatted')
do 130 k=1,nz
do 130 j=1,ny
do 131 i=1,nx
131 veli(i)=vel(i,j,k)*1000.
130 write(36) (veli(i),i=1,nx)
stop
end

[Steven_L_Intel1]

Error during rerad is a generic message that is given when one of the specific messages (for example, EOF) doesn't apply. You can call ERRSNS to get the "system" error code that led to this.

The code you have assumes that the data file was written by Intel Fortran or one that uses the same unformatted file layout. Can you show us the first few lines of an "od -h" command on the file?

[milenko1976]

Of course.here it comes:
milenko@hp6830s:~/fast1$ od -h velbuild.f
0000000 0a63 2063 2020 2020 6576 7372 6f69 206e
0000020 2e31 2030 4d20 7261 3120 3939 0a35 0a63
0000040 2063 2020 2020 2d2d 2d2d 2d2d 2d2d 2d2d
0000060 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
*
0000140 2d2d 2d2d 2d2d 630a 2020 2020 7c20 2020
0000160 2020 2020 2020 2020 2020 2020 2020 2020
*
0000240 2020 2020 2020 2020 2020 2020 0a7c 2063
0000260 2020 2020 207c 2020 2020 2020 2020 2020
0000300 2020 2020 2a2a 2a2a 2a2a 2020 2056 2045
0000320 204c 2042 2055 2049 204c 2044 2a20 2a2a
0000340 2a2a 2020 2020 2020 2020 2020 2020 2020
0000360 2020 7c20 2020 0a20 2063 2020 2020 207c
0000400 2020 2020 2020 2020 2020 2020 2020 2020

[mecej4]

That's the hex-dump of your source file in #12: that's not of any use, since we already know that your program is compiled without any problems.

What Dr. Fortran asked you to show, and what's really under question, is the unformatted file that you are trying to read.

[milenko1976]

vel.mod hex dump:
0000000 04b2 0000 0000 0000 1388 1388 1388 1388
0000020 1388 1388 1388 1388 1388 1388 1388 1388
*
0002260 1388 1388 1388 1388 1388 04b2 0000 0000
0002300 0000 04b2 0000 0000 0000 13ec 13ec 13ec
0002320 13ec 13ec 13ec 13ec 13ec 13ec 13ec 13ec
*
0004560 13ec 13ec 13ec 13ec 13ec 13ec 04b2 0000
0004600 0000 0000 04b2 0000 0000 0000 1450 1450
0004620 1450 1450 1450 1450 1450 1450 1450 1450
*
0007060 1450 1450 1450 1450 1450 1450 1450 04b2
0007100 0000 0000 0000 04b2 0000 0000 0000 1487
0007120 1487 1487 1487 1487 1487 1487 1487 1487
*
0011400 04b2 0000 0000 0000 04b2 0000 0000 0000
0011420 14bf 14bf 14bf 14bf 14bf 14bf 14bf 14bf
*
0013700 14bf 04b2 0000 0000 0000 04b2 0000 0000
0013720 0000 14f6 14f6 14f6 14f6 14f6 14f6 14f6
0013740 14f6 14f6 14f6 14f6 14f6 14f6 14f6 14f6
*
0016200 14f6 14f6 04b2 0000 0000 0000 04b2 0000
0016220 0000 0000 152e 152e 152e 152e 152e 152e
0016240 152e 152e 152e 152e 152e 152e 152e 152e

[mecej4]

The first record is quite revealing. It is a record of length 0x04B2, with 0x259 (=decimal 601) INTEGER*2 values, all of which are 0x1388 (=decimal 5000).

This pattern is repeated later, with different values in the other records, again with INTEGER*2 values. From your post, on the the other hand, it is clear that the numbers should all be REAL*4 or REAL*8, which are the only meaningful values for the variable veli.

With this information, you should investigate why your program is dumping short integers instead of 4-byte or 8-byte reals.

[milenko1976]

Thanks mecej4.I think that it is somehow related to hardware.My computer architecture is x86-64 bit.The guy that has written a code worked on SUN-Sparc.So we come here to this big and little endian issue.

[milenko1976]

I have checked now:
integer*2 veli(nxmax)
So veli are integers.What is WRONG then?

[mecej4]

Well, velocities (and other physical quantities) are best represented as real numbers, although it is sometimes convenient to map such variables into integers. This, however, needs to be done with care. Secondly, if you show code containing variables and statements that are normally handled with real arithmetic, and do not disclose that the variables are declared INTEGER*n, you are unlikely to get correct diagnosis are advice on this forum.

Sparc architecture is big-endian, x64 is little endian, so the byte order and record length representation remain issues even when integers are used to move data using unformatted files. The Intel compiler provides option switches to handle conversions.

[milenko1976]

What should I include in makefile?
I came across this:
-convert big_endian

[Steven_L_Intel1]

I don't think the file is big-endian. That would make the record lengths big-endian as well and that doesn't work out. However, it looks as the record lengths are 64=bit, something Sun does for all files on its 64-bit architectures, but we do not. We can express large records, but do so in a way that preserves 32-bit lengths for smaller ones. Ironically, the format we use was suggested to us by a Sun developer who could not get his own team to adopt it!

One way to deal with this is to open the file using ACCESS='STREAM' and read two INTEGER(4) values before and after each record, to consume the record lengths. This assumes you know how long each record is.