Opened 13 years ago
Closed 13 years ago
#507 closed bug (WorksForMe)
Not all smooth with merge — at Version 1
Reported by: | kate | Owned by: | arango |
---|---|---|---|
Priority: | major | Milestone: | Release ROMS/TOMS 3.5 |
Component: | Nonlinear | Version: | 3.5 |
Keywords: | Cc: |
Description (last modified by )
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:
CALL get_ngfld (ng, iNLM, idRtra, ncFRCid(idRtra,ng), & & nFfiles(ng), FRC(1,ng), update(1), &
The compiler doesn't know what to make of ncFRCid and nFfiles.
Also, in main3d.F, some SHARED(ng) are gone, some remain. Is that right?
Change History (1)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Resolution: | → WorksForMe |
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
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.