Changes between Initial Version and Version 1 of Ticket #507


Ignore:
Timestamp:
04/28/11 17:48:06 (13 years ago)
Author:
arango
Comment:

The call is correct! It is very likely that your merge failed or you deleted by accident the variable ncFRCid. This is the only ID variable that was retained. It is a very important one since it will allows to spread the forcing fields into different files. We cannot use the ncid in the derived-type FRC(:,:) structure because there is not association between the forcing field and the NetCDF ID of the file containing the needed field.

The SHARED variables in OpenMP parallel loops are correct in main2d/main3d. The logic in these routines changed because of the nesting structure. They are going to change even more in the future. It turns out that every compiler implements the OpenMP standard differently. I am using all the latest compilers. Sometimes, all the threads do not enter the parallel region if something is wrong in the SHARED token. I discovered this when investigation the odd behavior of the profiling clocks in shared-memory. I spent several days in the debugger looking at this.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #507

    • Property ResolutionWorksForMe
    • Property Status newclosed
  • Ticket #507 – Description

    initial v1  
    1 I thought I'd try compiling the NEP5 domain to shake out my bugs. Lo and behold, not all are mine. Here's from get_data.F:
     1I thought I'd try compiling the '''NEP5''' domain to shake out my bugs. Lo and behold, not all are mine. Here's from get_data.F:
    22
    33{{{
     
    66
    77}}}
    8 The compiler doesn't know what to make of ncFRCid and nFfiles.
     8The compiler doesn't know what to make of '''ncFRCid''' and '''nFfiles'''.
    99
    10 Also, in main3d.F, some SHARED(ng) are gone, some remain. Is that right?
     10Also, in '''main3d.F''', some '''SHARED(ng)''' are gone, some remain. Is that right?