forums.silverfrost.com

[Konstantin8]

I have a program distributed by NASA. During debugging I see the mentioned error on reading a binary data file.
I'm able to attach the ftn95 project with source files and data file.
Or source files can be downloaded from
http://nssdcftp.gsfc.nasa.gov/models/atmospheric/hwm07/

I use Win32 build in Plato.

Thanks in advance.

[IanLambley]

If those files were written by another compiler, then there is no real standard for unformatted binary files and the form of the record length part of each line changes for lines of length less or greater than 256 characters.
Try using this program on the .dat files:

[mecej4]

I was able to convert the unformatted data files after I enlarged the buffers in IanLambley's converter program to cover the longest of the input data files.

The NASA source code has some bugs that are easy to find and fix, but without those fixes you will not get correct results. Subroutine HWMupdate needs an explicit interface but one is not provided. There are some subroutine arguments that have declared INTENT(IN) but are modified. There are some variables that are not initialized. Here is a brief list of fixes:

File dwm07b.f90:

Change INTENT of GLON to "IN OUT" in subroutines DWM07B_HWM_INTERFACE and GD2QD

Initialize HR in subroutine GD2QD.

File hwm07e.f90:

Change INTENT of GLON to "IN OUT" in subroutines HWM07.

Initialize LAST() in subroutine HWMQT.

Change subroutine HWMUPDATE to a contained subroutine or provide an explicit interface to it in its caller(s).

Initialize GZWGHT in subroutine LOADMODEL.

File apexcord.f90: Change INTENT of GLON to "IN OUT" in subroutine APEX.

If you (original poster) are interested, I can see about posting the modified sources and the FTN95 compatibles *.dat files somewhere from where you can download them. (This forum does not seem to allow attaching files to messages).

[JohnCampbell]

It always annoys me to see programs released with binary data files.
It would be much better if the .dat files were text files, where the data was written as text numbers.
The penalty to be paid for file size or run time is minimal, while the choice of number formats to limit precision errors is ususlly minimal, given the accuracy of the initial data estimates.
Using text files as an interface between programs also makes validation of the data much easier.

John

Ian, thanks for your program. It is very useful.
It fails where the record size is larger than the input array or the logical record is not fully contained in the work array. I think you need to test if the next logical record is fully contained in WORK, rather than "do while (iwork_pointer < iwork_end)". If you change 65536 to be larger than the file ( can change up to about 1gb ) then ther is no problem.
If you open the file as access='transparent', you can read the file 1 byte at a time and do away with the input buffer, reading the 4_byte header, then the info, then the 4_byte trailer.
You might like to consider the TRANSFER intrinsic to generate the integer*4 value.
The other problem is if the source file is from a unix or linux source, where the problem of ??_endian makes it more complex. You then need to know the structure of each record.

[Konstantin8]

Hi all,
Thanks for help!

I try to use the posted program but have an error with undefined elements in the input array.

If I correctly understand I need to enlarge dimensions of input and work arrays and also enlarge NBYTES value in the READF@ call.

Is it correct?

[Konstantin8]

[IanLambley]

John,
Thanks for the info. I could have opened it as a direct access file with a recl=1, but I was trying to avoid too many reads as I thought that could slow down the processing.
Yes, the TRANSFER intrinsic would be much better but I'm caught in a Fortran 66 time warp, I must do better, but, heavens, I've just sold my 1961 Riley 1.5 and I'm still in shock! LOL
Regards
Ian

[mecej4]

Konstantin8:

[Konstantin8]