error with /opt with derived type

Paul,

To check my program, I am compiling most of my program with /check, but trying to use /opt for a few routines that are compute intensive. With these compile options mix, the following code example does not appear to work correctly with /opt. the module was compiled with /check

      count_best = 0
      count_last = 0
      sum_ri     = 0
!
      do id = 1,num_node
         if (mod (id,500000) == 0) write (*,2001) 'Checking sector allocation',id
!
         x  = (node_data(id)%ix - 1) * grid_dx + xmin_g
         y  = (node_data(id)%iy - 1) * grid_dx + ymin_g
!
!      find nearest segment centre
         ri = 1.e30
         ik = 0
         do k = 1,channel_no+1
            rk = (x - sector_data(k)%x1)**2 + (y - sector_data(k)%y1)**2
            if ( rk >= ri ) cycle
            ri = rk
            ik = k
         end do
!
         count_best(ik) = count_best(ik) + 1
         count_last(k)  = count_last(k)  + 1
         sum_ri         = sum_ri + sqrt(ri)

I have included count_best, count_last and sum_ri stats to confirm the behaviour. with /opt, ik is always 1, implying rk is not being updated (correctly calculated) for each itteration of k. average of ri is 30,498 (metres) I have checked that the itteration goes for 730 cycles (channel_no+1)

with /debug used for the module and routine, ik is being correctly calculated in the range 1:730 and ri averages 160 metres

This is a large program with a 2.5gb data set so not easy to send. num_node = 7,548,638

Any suggestions, as I would like to be able to use /opt for some key loops.

John

John

I don't have any suggestions about what is going wrong. /opt can only optimise locally so should have no effect on other subprograms.

At a quick glance, I don't think that I can reproduce the effect without further information. If you are able to provide a working sample then I would be happy to investigate further.

Paul,

the problem is when using /opt for the following loop

!      find nearest segment centre 
         ri = 1.e30 
         ik = 0 
         do k = 1,channel_no+1 
            rk = (x - sector_data(k)%x1)**2 + (y - sector_data(k)%y1)**2 
            if ( rk >= ri ) cycle 
            ri = rk 
            ik = k 
         end do 

I suspect that /opt is optimising out the recalculation of rk at each step of loop k, as with /opt, at the end of the loop; ik=1 and k = 731

John

Try doing the calculation in different ways. Does the /explist help in this situation?

Paul, I can confirm that rk is not being updated for each itteration of k. I have changed the code for this loop to: print_this = in_list ( id, print_list, 10) ! do k = 1,channel_no+1 rk = (x - sector_data(k)%x1)**2 + (y - sector_data(k)%y1)**2 if (print_this) write (98,) id, k, ik, ri, rk if ( rk >= ri ) cycle ! if (kd > 0) num_better = num_better + 1 ! count changes to existing definitions ri = rk ik = k end do if (print_this) write (98,) id, k, ik, ri, rk

For a selected node, this gives a report like:

       255565           1          22          7114407.26500              4393344.85000
       255565           2           1          4393344.85000              4393344.85000
       255565           3           1          4393344.85000              4393344.85000
       255565           4           1          4393344.85000              4393344.85000
       255565           5           1          4393344.85000              4393344.85000
....
       255565         730           1          4393344.85000              4393344.85000
       255565         731           1          4393344.85000              4393344.85000

If this routine is compiled with /debug, I get: 255565 1 22 7114407.26500 4393344.85000 255565 2 1 4393344.85000 3986640.05000 255565 3 2 3986640.05000 3599935.25000 255565 4 3 3599935.25000 3233230.45000 255565 5 4 3233230.45000 2886456.78500 ... 255565 22 21 31932.6849000 22340.5961000 255565 23 22 22340.5961000 32751.1042000 255565 24 22 22340.5961000 63159.6970000 ... 255565 730 22 22340.5961000 2676905821.09 255565 731 22 22340.5961000 2676905821.09

I can overcome the problem by not using /opt, but the real problem is that /opt does not work for this situation, which I think is derived types. Can some of these /opt short-comings be investigated?

John

I will make a note of this for investigation.

Paul,

I have sent an email with the code for this problem. It includes the module required to define the derived types.

John