Help please - optimization problem ...

Accelerated Computing HPC Compilers Legacy PGI Compilers
#1

Hi All,

I’m trying to figure out what might be wrong with a chunk of code. I have a subroutine which is part of a module which is in turn a part of a large simulation code. When compiled with no optimization or -O1 it works correctly - when compiled with -O it does not. When compiled with -O the code gives the right value on the first execution of the subroutine and an incorrect NaN value on subsequent execution for vr and vz in the code snippet below.

When I add write statements for current_angle, current_velocity, launch_velocity and vr,vz - before and after the assignment to vr,vz - they all contain appropriate values even vr,vz before the assignment. However, the values for vr,vz themselves change to NaN’s after the assignment while the other variables do not change (as expected). The write statement includes explicit calculations of the values assigned to vr,vz and these give the correct values as well.

This is compiler version 7.2.3 - RHEL5 - 32bit - core2

Are there any specific coding issues that could cause this sort of problem? I’ve run into these sorts of things occasionally and can never find a problem with the code itself. Are there any compiler options that could help me figure out what the compiler is doing and why it the optimized code doesn’t work?

Thanks,

David

P.S. Adding a SAVE to the declaration of vr,vz does not change the result

subroutine assign_velocity(item_velocity ,… launch_velocity,current_angle,current_velocity …)

type(velocity_type) :: item_velocity
real,intent(in) :: launch_velocity,current_angle
real,intent(out) :: current_velocity
…
! locals

real :: vr,vz
…

write(0,’(a,10(1x,g12.5))’) ‘ASSIGN1:’,current_velocity,current_angle,vr,vz,neutral_time_step,&
&current_velocity_in_r,current_velocity_in_z,COS (Current_Angle),sin(current_angle),&
& Current_Velocity * COS (Current_Angle), Current_Velocity * SIN (Current_Angle)


Current_Velocity = Launch_Velocity

vr = Current_Velocity * COS (Current_Angle)
vz = Current_Velocity * SIN (Current_Angle)

write(0,’(a,10(1x,g12.5))’) ‘ASSIGN2:’,current_velocity,current_angle,vr,vz,neutral_time_step,&
&current_velocity_in_r,current_velocity_in_z,COS (Current_Angle),sin(current_angle),&
& Current_Velocity * COS (Current_Angle), Current_Velocity * SIN (Current_Angle)

item_velocity%v(1) = vr
item_velocity%v(2) = vz
…

end subroutine …

Output:

ASSIGN1: 1238.7 0.0000 975.81 0.0000 0.10000E-07 -0.85850E-05 -0.11991E-04 1.0000 0.0000 1238.7 0.0000
ASSIGN2: 975.81 0.0000 NaN NaN 0.10000E-07 NaN NaN 1.0000 0.0000 975.81 0.0000

#2

Hi David,

I’d like you to try compiling “-O -Kieee”. “-Kieee” uses stricter versions of COS and SIN then the more optimized (and less precise) versions.

If this isn’t it, then I’d need to see the entire subroutine to better undertand the issue. If large, feel free to send the example to PGI customer service (trs@pgroup.com) and have them forward it to me.

Thanks,
Mat

#3

Just an update - I compiled the code with -O -Kieee … unfortunately, this triggered a separate issue elsewhere in the code so I wasn’t able to evaluate the effect on the initial problem.

input_HC_H_mass is an input value set to 1.0

avg_H_mass = input_HC_H_mass
temp_mod = mod(avg_H_mass,1.0)
write(0,*) temp_mod, avg_H_mass, input_HC_H_mass

This code, when compiled with -O -Kieee will give values of temp_mod of 0.0000 (correct answer) or NaN - apparently almost randomly - Avg_H_mass and input_HC_H_mass are always 1.00000 no matter what value temp_mod ends up getting.

When compiled with -O - this particular code does not seem to be a problem.

Anyway, I can send the module that caused the original issue in case you want to take a look at it.

Cheers,

David