PGI release 7.05 error in regrid (MM5)

My operating system is CentOS4.4, when i run the pregrid.csh in regrid program using PGI release 7.05 in 32bit x86 platform, the following error occurred,

[root@gridlab100 pregrid]# ./pregrid.csh

Processing for SourceType = 3D



Starting ON84 processing for type 3D

cd /usr/src/redhat/BUILD/mm5V3-3.7.0/REGRID/pregrid/on84

ln -s /usr/src/redhat/BUILD/mm5V3-3.7.0/REGRID/pregrid/NCEP_ON84.9303 ON84FILEA

\



** pregrid version number: 0.28 **





HSTART, HEND = 1993-03-13_00:00:00 1993-03-14_00:00:00
Opening: ON84FILEA


Subroutine DATINT:
Interpolating 3-d files to fill in any missing data…


Looking for data at time 1993-03-13_00

Date not found: 1993-03-13_00:00:00
FORTRAN STOP
foreach: No match.

Does anyone know how to solve it? THANK YOU.

(Actually i already solve it by using PGI compiler release 6.08, but when i built this program in rpm package, it occurred another error during installation as below:

error: Failed dependencies:
libpgc.so is needed by mm5V3-regrid-3.7.0-1.i386

i try all possible to set library path such as add a line
export LD_LIBRARY_PATH=$PGI/lib
in /etc/bashrc
and type ldconfig in terminal command line, still face the same failed dependencies problem, so if anyone got good solution, pls HELP ME, THANK YOU)

Hi kklee0074,

This is caused by a source code error in pregrid and only works by luck with the 6.0 compilers. The solution is to concatenate a NULL character at the end filename that’s being passed to the C function which opens the data file.

To fix, change line 31 to ron84_record.F

call COPEN(iunit, ifd, trim(on84flnm)//char(0), 1, ierr, -1)

Full details can be found HERE and HERE.

Hopefully the dependency problem will go away after this change. If not, let us know and we’ll try to help out.

  • Mat

Hi Mat,

Thank you for your fast reply my message, after trying your way to solve the problem, the dependencies problem still can’t be solved, do you have any other suggestion for me? Thank you so much.

Hi kklee0074,

In 32-bit, the PGI shared runtime libraries are located in the “lib” directory. Typically “$PGI” is set to either “/usr/pgi” or “/opt/pgi” so the full LD_LIBRARY_PATH would be “$PGI/linux86//lib”. Of course, you may have “$PGI” set differently so please adjust as needed.

Hope this helps,
Mat

Hi Mat,

[root@gridlab100 6.0]# pwd
/usr/local/pgi/linux86/6.0
[root@gridlab100 6.0]# ls
bin include liblf LICENSE.txt PORTABLE TRIAL_LICENSE
doc jre LICENSE_ACML.txt man REDIST
EXAMPLES lib LICENSE_STLport.txt PGIinstall src

Above is what i have, as u see, i don’t have libso directory, i only have lib and liblf directory. I try to copy the libpgc.so file from lib directory to directory /usr/lib and /lib and run ldconfig, but still not work, the dependencies problem still unsolved.

Furthermore, when i run the command ld -lpgc, the output is as below:
[root@gridlab100 lib]# ld -lpgc
ld: warning: cannot find entry symbol _start; not setting start address

This indicate the system detect the library libpgc.so, rite? But when i try to install the rpm package, it still failed with dependencies, i just wonder why this will happen? The final way i can think of is install the rpm package by using --nodeps option which will just ignore the dependencies, i try once, it work as the mm5 package install can run normally. But is that any solution other than this, if not until final moment, i don’t want to use this method.

Hi kklee0074,

My mistake, I meant that libpgc.so is found in the “lib” directory in 32-bit, not “libso” which is used in 64-bits. I’ve corrected my earlier post.

As for the missing dependency error, it does appear that the linker is finding the library. However, I don’t have enough experience with building RPMs to help on how best to package the MM5 binary. Are you also able to include “libpgc.so” in the RPM? Can you build MM5 statically (-Bstatic) so you don’t have any external dependencies?

Are you planning on redistributing the package? If so, keep in mind that there are several “libpgc.so” libraries, each one supporting a different kernel versions. By either packaging a particular “libpgc.so” or linking statically, you may cause your program not to run correctly on some systems. For more portable code, you can download and redistribute the PGI 6.0 32-bit portability package (found HERE) which will install the correct “libpgc.so” for the user’s system. Also, you may want to consider compiling with the “-tp px” flag to set your architecture target to be a generic i386 processor. Although much slower, it will allow the binary to run on many more systems. Of course, if it will only be run on more modern architectures, use the oldest architecture target your program will be executed on. See “pgf90 -help -tp” for a complete list of architecture targets.

  • Mat