CRTM 2.0 compiling issue with PGI 10.3

Jerryleo · April 28, 2010, 11:02pm

I compiled CRTM 2.0 with PGI 10.3 on linux box by following command and options

pgf95 -c -g -fast -byteswapio

It complained an internal compiler error and aborted.

PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647) 
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. Scale_Of: bad dtype        0 (CRTM_Atmosphere_Define.f90: 647)
PGF90-S-0000-Internal compiler error. size_of:bad dtype     367 (CRTM_Atmosphere_Define.f90: 647)
PGF90-F-0008-Error limit exceeded (CRTM_Atmosphere_Define.f90: 647)
PGF90/x86 Linux 10.3-0: compilation aborted

Here is the line complained by PGI 10.3

 647     IF ( atm%n_Clouds > 0 ) &
 648       atm_out%Cloud = CRTM_Cloud_AddLayerCopy( atm%Cloud, atm_out%n_Added_Layers )

I tried to compile the CRTM 2.0 with PGI 8.0-4, it works fine with a few warnings.

Any ideas?

Thanks

MatColgrove · April 28, 2010, 11:42pm

Hi Jerry,

Internal Compiler Errors (ICE) are caused by the compiler doing something unexpected (i.e. a compiler bug). In this case, it’s having problems with a malformed data type. Determining the exact problem will take further investigation.

However, I just downloaded the “CRTM Forward Model Test program” from http://www.ssec.wisc.edu/~paulv/Fortran90/CRTM/Developmental/Source_Code.html and it compiled fine using 10.3. Is this the correct source? Can you list out the steps you did to configure and compile the code?

Thanks,
Mat

Jerryleo · April 29, 2010, 5:02pm

Hi,

Thanks for reply.

I think what you downloaded is CRTM 1.2, PGI 10.3 works fine with it.

This internal compiler error just caused by CRTM 2.0 compiled by PGI 10.3.

Please try the lastest CRTM 2.0 If it is possible.

CRTM 2.0

Here is my steps

edit make.macros
comments out the gfortran definition LINUX_FLAGS = $(LINUX_FLAGS_GFORTRAN)
uncomments the pgi definition LINUX_FLAGS = $(LINUX_FLAGS_PGI)
make pgi

PS, gfortran & ifort works fine with the lastest CRTM 2.0.

MatColgrove · April 29, 2010, 7:33pm

Hi Jerry,

Thanks for the pointer. I was able to recreate the error in 10.3. The good news is that it appears to have been fix in the 10.4 release. Please try upgrading your compiler version.

Mat

paulv1 · May 4, 2010, 7:46pm

Just for the record, changes have been made to the CRTM (the soon to be released v2.0.1) that include a fix for this error in the v10.3 PGI compiler.

But, I recommend you take Mat’s advice and upgrade to v10.4 as soon as the opportunity presents itself.

cheers,

paulv (one of the CRTM folks :o)

Jerryleo · May 4, 2010, 8:22pm

Thanks for all kind help.

There is another issue that the CRTM 2.0 will fail by using kmatrix feature at runtime if it si compiled by PGI. I’m not sure whether if it is a compiler floating-point issue or some Fortran feature used by CRTM 2.0 are not supported by PGI.

Because

This issue only caused by PGI compiler and using crtm_kmatirx feature at runtime.
CRTM 2.0 works fine without using kmatrix even if it’s compiled by PGI
CRTM 1.2 works fine with the kmatrix features even if it’s compiled by PGI
For other compiler, such as ifort or gfortran or xlf, CRTM 2.0 works fine with kmatrix features.
There were NO compiling error except some warning messages. But for other compiler, such as ifort or gfortran or xlf, there were no those warning messages complained by PGI. (Detailed: https://forums.developer.nvidia.com/t/pgf90-w-0155-pgf90-w-0171/131717/1)

I’m stuck with this issue and no clue.

Any ideas

MatColgrove · May 5, 2010, 3:53pm

Hi Jerry,

I’d be happy to take a look, however, I’ll need a way to reproduce the problem. Can you please send an example of your driver program to PGI Customer Service (trs@pgroup.com) and ask them to forward it to me?

Thanks,
Mat

Jerryleo · May 5, 2010, 6:09pm

Hi, Mat

Thank you very much indeed for your kind help.

The driver program is WRFVAR 3.2. I compiled WRFVAR 3.2 with CRTM 2.0 support. And assimilated the NOAA radiance data.

I’m tracking back the source codes and trying to figure out where is the problem.

Here are the source codes

WRFVAR v3.2 : http://www.mmm.ucar.edu/wrf/src/WRFDAV3.2.tar.gz
CRTM 2.0 : ftp://ftp.emc.ncep.noaa.gov/jcsda/CRTM/REL-2.0/REL-2.0.JCSDA_CRTM.tar.gz

Here are the test datasets(40M)

ftp://222.221.254.237/pub/radiance.tar.gz

Here are the steps

setenv CRTM ‘crtm 2.0 installed dir’
setenv NETCDF ‘netcdf installed dir’

After installing CRTM 2.0
cd $CRTM
ln -sf ./lib/libCRTM.a libcrtm.a

cd WRFDA
./configure wrfda
./compile all_wrfvar

link the da_wrfvar.exe to the test datasets dir
then run da_wrfvar.exe

MatColgrove · May 7, 2010, 8:56pm

Hi Jerry,

I’m having trouble getting WRFDA 3.2 to compile with CRTM 2.0. When compiling “module_radiance.f90”, get the following errors:

PGF90-S-0084-Illegal use of symbol crtm_allocate_options - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_destroy_channelinfo - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_zero_atmosphere - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_zero_surface - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_destroy_surface - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_destroy_atmosphere - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_assign_surface - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_assign_atmosphere - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_allocate_surface - not public entity of module (module_radiance.f90: 30)
PGF90-S-0084-Illegal use of symbol crtm_allocate_atmosphere - not public entity of module (module_radiance.f90: 30)

It appears to me that CRTM 2.0 has changed the names of several of their variables and WRFDA has not been updated to use them. For example, “CRTM_Options_Define.f90” now uses the symbol “CRTM_Options_Destroy” in 2.0 instead of “CRTM_Destroy_Options” in 1.2.

How did you work around this issue? Are you still using CRTM V1.2?

Thanks,
Mat

Jerryleo · May 10, 2010, 5:05pm

Hi, Mat’s

Thanks for your time.

Sorry I forgot the WRFVAR interface update for CRTM 2.0

update 1. ftp://222.221.254.237/pub/wrfvar-crtm-2.0-interface-update.tar.gz
update 2. ftp://222.221.254.237/pub/CRTM_SensorData_Define.f90

Please overwrite the var directory under WRFDA with update 1, and overwrite CRTM_SensorData_Define.f90 under the src directory of CRTM 2.0 with update 2

I traced back to the source code. I think the issue may be caused by using intrinsic assignment for UDDTs with ALLOCATABLE components.
Here are the paulv’s explanations

PGF90-W-0155-.nullify - must also have PURE attribute

1415 ELEMENTAL FUNCTION CRTM_Atmosphere_Add( atm1, atm2 ) RESULT( atmsum )
1416 TYPE(CRTM_Atmosphere_type), INTENT(IN) :: atm1, atm2
1417 TYPE(CRTM_Atmosphere_type) :: atmsum

… … …

1436 ! Copy the first structure
1437 atmsum = atm1

… … …

1459 END FUNCTION CRTM_Atmosphere_Add

This one would appear to be a bug in the compiler. The compiler folks will have to verify, but from a purely Fortran95/2003 standpoint, use of the ELEMENTAL attribute on a procedure implies said procedure is PURE.

Since the assignment statement is also in the above quote, I assume the warning is issued because the code uses intrinsic assignment (rather than me writing an explicit elemental procedure to do it). By default, intrinsic assignment should be elemental – even for UDDTs… and even for UDDTs with ALLOCATABLE components (of which the CRTM_Atmosphere_type structure contains plenty).

cheers,

paulv

I traced the status change of Atmosphere structure(var/da/da_radiance/da_get_innov_vector_crtm.inc), after calling CRTM_Atmosphere_Zero, Members of Atmosphere, such as Atmosphere(1)%Temperature, also was set to Zero. CRTM_Atmosphere_Zero should only zero the Atmosphere_K, but it also zero Atmosphere at the same time. And this will cause problem in CRTM_K_Matrix_Module(CRTM_K_Matrix_Module.f90 under CRTM 2.0 soruce code directory) when calling CRTM_Compute_Predictors.

458         if (use_crtm_kmatrix) then
459   CALL CRTM_Compute_Predictors
460            ! CRTM surface/atmosphere K initialization
461            do l = 1, ChannelInfo(inst)%n_Channels
462               ! -- Copy the adjoint atmosphere structure
463               Atmosphere_K(l,:) = Atmosphere
464
466              ! -- Copy the adjoint surface structure
466              Surface_K(l,:) = Surface
467           end do
468
469          ! -- Zero the Adjoint outputs
470           ! Important: adjoint variables must be initialized
471           call CRTM_Atmosphere_Zero( Atmosphere_K )
472           call CRTM_Surface_Zero( Surface_K )
473
474           ! Assign tb = R^-1 Re :
475           RTSolution_K(:,1)%brightness_temperature = 1.
476           RTSolution_K(:,1)%radiance = 0.
477    
478           ! [1.3] Call RTM K-Matrix model
479        call da_crtm_k(1, nchanl, 1, Atmosphere,   &
480                             Surface,      &
481                             RTSolution_K, &
482                             GeometryInfo, &
483                             ChannelInfo(inst),  &
484                             Atmosphere_K, &
485                             Surface_K,   &
486                             RTSolution,  &
487                            Options)

Any ideas?

cheers,

Jerry

hnlim · June 2, 2010, 4:26pm

Hi Jerry,

I am keen to know how to get CRTM 2.0 to work with WRFDA 3.2.
The current release of WRFDA 3.2 supports only CRTM 1.2.
I had checked the interface code and they are all for crtm 1.2.

Would you mind giving me advice how to carry out this upgrade?

Thanks
Agnes