As a part of the prototyping activities, we plan to acquire, port and run algorithm code from various instruments on the distributed/parallel testbed and HPCC sites to the extent possible. We plan to communicate the progress on these activities and important lessons learned for hardware architecture and algorithm integration and testing from time to time. I am attaching the first report prepared by Narayan Prasad.
Background
* Acquired AVHRR PATHFINDER algorithm from Mary James (Code 902.3), NASA/GSFC. The algorithm contains 29,600 LOC in ANSI C with POSIX compliant interfaces. The code is operational at NASA/GSFC on an SGI 340 VGX multiprocessor workstation with 256 MB memory amd an SGI Indigo R4000 with 96 MB memory. The code takes 41 hours to process 14 orbits (1 day) of data on the SGI 340 VGX, and 15 hours and 17 minutes to run on the SGI Indigo R4000.
Results/Lessons learned
* Successfully ported the code to a single processor HP735 (node name "oriole") with 144 MB RAM and 99 MHZ clock speed. Additional tests were performed on another HP735 ("sparrow") (with the the same characteristics as "oriole"), and a slower HP715 ("eagle") (32 MB RAM and 50 MHZ clock speed).
* c89 (POSIX compliant interface to the cc compiler) was used to compile and link the program. The code has never been checked for POSIX compliance.
* The latest version of CDF (version 2.4) and HDF (version 3.3 release 3) were used. The operational algorithm used earlier versions.
* A single orbit of data from NOAA-9 satellite was successfully processed by the prototype on all three machines.
* Initial results are encouraging. The timing statistics are as follows (for 1 orbit of data):
ORIOLE: SPARROW: EAGLE: real: 32m 14s real: 1h 16m real: 1h 43m user: 7m 55s user: 7m 43s user: 18m 10s sys: 16m 8s sys: 13m 58s sys: 31m 51s Total CPU ~24m Total CPU: ~21m Total CPU: ~50m
* The AVHRR algorithm has never been run on a machine with less than 64 MB RAM. The prototype indicates that AVHRR algorithm requires no less than 32 MB RAM.
Plans for March-April, 1994:
* Process 14 orbits (1 day) of PATHFINDER data for better benchmark comparisons
* Study portability on other machines
* Check porting to 64-bit architecture to study problems encountered
* Get snippets of MODIS code (Fortran 77) and investigate on Cray and other parallel machines available at GSFC HPCC. Parallelization studies can also be done using tools available on the testbed.
Recommendations based on lessons learned:
The following are some lessons learned when integrating the AVHRR PATHFINDER algorithm. It is very general and is applicable to all science software teams:
* Delivery of science software can be done via anonymous ftp servers. Either the server can be located at the ECS facility, or it can be located at the SCF development facility. The file should be archived by standard UNIX utilities like tar, etc. It should be in compressed form for quicker transmission via ftp. When transferring large data files, tape/cartridge is preferable. The type of tape/cartridge (4mm, 8mm, etc.) should be agreed upon with the AIT prior to data delivery.
* When submitting science software as a tar archive file, do not submit a tar file with the same name as that of a directory/file that would be created when extracted from the archive.
Consider for e.g., pathfinder.tar as an archived file submitted by the science software developer. If the archive (pathfinder.tar) contains a directory called pathfinder.tar, and when the files in the archive are extracted, a file called pathfinder.tar is attempted to be created. Since, such a name already exists, the tar command fails. On some UNIX systems, it gives a "check sum" error. This error is not obvious.
* All directories and subdirectories that would be required by the algorithm must be created when the components of the science software are extracted using the UNIX tar utility. If the software is delivered by other means, directories that must exist for the science software to run correctly should be explicitly stated in a document that accompanies the software delivery.
* Compilation on the HP:
Fortran 77: fort77 is recommended. It is a POSIX-conformant interface to the f77 compiler.
C: c89 is recommended. It is a POSIX-conformant interface to the cc compiler.
The HP Softbench package contains both cc and c89 compilers.
* When submitting data on tapes/cartridges, avoid devices that swap bytes. Porting is a lot easier when bytes are not swapped. Information about the hardware device the tape was created, a listing of the files on tape, size of each file, total data that is contained on each tape should accompany the tape.
* A UNIX man page of the compiler used during software development should accompany the algorithm. With various compiler options available (options varying with versions), it helps in transforming those compiler options to the new environment. Providing such information will be extremely valuable, especially when porting across different platforms and the algorithm integrator wants to know what the equivalent option is on the new platform.