problem with readinf .mod files

problem with readinf .mod files

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.

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

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 00007F7861B165A6 Unknown Unknown Unknown
main 0000000000403269 Unknown Unknown Unknown

Gives me error during read???

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.

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

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

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

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

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

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.

Retired 12/31/2016

Who is then associating file with applicaton?

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.

OK.This is part of file model.f
open(23, file='vel.mod', form='unformatted',
+ status='old')
c convert the velocity array to velocity/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. is input ASCII file used by velbuild.f
if(imod.eq.3) then
open(10, file='', status='old')
open(12, file='vel1d.out')
100 read(10,*,end=999) zin(i),vin(i)
go to 100
999 npts=i-1
do 200 k=1,nz
do 210 j=2,npts
if( then
+ (zin(j)-zin(j-1))+vin(j-1)
go to 220
end if
210 continue
3 format(/'*** 1D profile not shallow or deep enough ***'/)
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)

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?

Retired 12/31/2016

Of 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

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.

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

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.

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.

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

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.

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

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.

Retired 12/31/2016

Steve,I don't get it.When I give him ACCESS='STREAM' I get this:
FD: finite difference traveltime calculation
forrtl: File exists
forrtl: severe (10): cannot overwrite existing file, unit 23, file /home/milenko/fast1/nfd/vel.mod

Did you change the STATUS field to 'NEW'?

Retired 12/31/2016

Yes,I did.I am going to install on other comp,to see if architecture plays role here.

Architecture does not matter, The issue now is that with STATUS='NEW'. it requires that the file not exist before the OPEN is done, and clearly it does. If this file is being read, go back to STATUS='OLD'. If you will be overwriting any existing file, use STATUS='REPLACE'.

Retired 12/31/2016

I am physicist not programmer,do not understand all this perfectly.Look at this example,rec_ascii.f
character*72 ifname,ofname
write(*,*, fmt="(/'Enter input file name')")
read(5,85) ifname
85 format(a72)
write(*,*, fmt="(/'Enter output file name')")
read(5,85) ofname
open(unit=11, file=ifname, form='unformatted', status='old')
open(unit=12, file=ofname)
100 read(11, end=999) x,y,z,t,u,i
write(12,5) x,y,z,t,u,i
5 format(5f10.3,i3)
go to 100
999 write(6,1) n
1 format(/'number of lines in file: ',i10/)
Converts binary into ascii file but I got this:
.000 .000 .000********** nan***
.000 .000 .000********** .000***
.000 .000******************** .000***
Something is WRONG.

Sorry, as far as this transaction is concerned, you are a programmer, whether or not you accept the appellation.

If you want to use unformatted files, which is not something that is recommended for someone new to Fortran, you are going to have to read the documentation or text books to find out the basic features of unformatted files. Without that knowledge, you are consigned to blundering around, as the posts in this thread show.

This is a recommendation to get out of the mess:

1) postpone attempts to process unformattted files written on another machine or by someone else until you have come to grips with the issues.

2) Turn around your last program, making it read from a text file and writing the read data into an unformatted file. Set permissions on the resulting file as 'read-only'.

3) Then, work with the resulting unformatted file and use the above program to read it. You will at this point have the advantage of knowing exactly what was written into the unformatted file, by which compiler, OS, etc.

4) Once you become familiar with unformatted files, go back to your original task.

Thanks a lot macej4.So what do I get with permissons set read-only?

The same kind of benefits that seat-belts give you.

If your second program -- the one that attempts to read the unformatted file and writes a text file -- has a bug in the file I/O statements and tries to clobber or corrupt the file that it is supposed to only read from, you are protected. After a few such accidents, especially if creating the read-only file takes non-trivial effort, one learns to use file permissions for protection.

Mecej 4
How did you manage to calculate numerical values form hex output?

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 is what bothers me.

That is an elementary operation in computing. For small numbers, I do it mentally; for others, I use a calculator with 'dec' and 'hex' buttons. Or, on Unix:

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
ibase=16    # I specify the Input Base
04B2           # I type in a number in hex
1202           # the program prints the same number in decimal

Leave a Comment

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