Opened 16 years ago

Closed 16 years ago

#174 closed upgrade (Done)

OpenMP and THREADPRIVATE

Reported by: arango Owned by: arango
Priority: minor Milestone: Release ROMS/TOMS 3.2
Component: Nonlinear Version: 3.2
Keywords: Cc:

Description

OpenMP supports the THREADPRIVATE(var) pragma so variables can be make private to a thread. We use this directive in ROMS only for the time profiling variables proc, Cstr, and Cend. As implemented in ROMS, we used common blocks for the var argument. Nowadays, this is problematic in some compilers like gfortran. Since the newer versions of OpenMP is mature nowadays in mostly all the compiler that support it, we are removing the common block and just pass the variable names as arguments.

So we are changing mod_parallel.F from:

#ifdef _OPENMP
        common /process/ proc
!$OMP THREADPRIVATE (/process/)
        common /wallclock/ Cstr, Cend
!$OMP THREADPRIVATE (/wallclock/)
#endif

to

#ifdef _OPENMP
!$OMP THREADPRIVATE (proc)
!$OMP THREADPRIVATE (Cstr, Cend)
#endif

Many thanks to Mark Hadfield for suggesting this change. I tested this change with the pgf90, ifort, and gfortran compilers.

I also updated the build.sh and build.bash scripts to allow the user to set the paths of the libraries required by ROMS using environment variables which take precedence to the values specified in the makefile macro definitions file (Compilers/*.mk).

I also changed the Compilers/*.mk to include the missing token ESMF_COMM in the ESMF_SUBDIR definition. There were also missing some flags for OpenMP option in the FFLAGS definition.

Change History (3)

comment:1 by arango, 16 years ago

Resolution: Done
Status: newclosed

in reply to:  1 comment:2 by shchepet, 16 years ago

Resolution: Done
Status: closedreopened

Replying to arango:

Here it should be explained that, for THE FIRST TIME EVER, the latest Open MP standard, Version 3.0 released on May, 2008 supports application of the THREADPRIVATE directive to an independent variable, provided that the variable is STATICALLY allocated (e.g., is placed into a common block; is declared inside a module; or is placed into a save statement).

Previous Open MP standards, Version 2.2 (May 2005) and Version 2.0 (November 2000, Fortran only; March 2002, C++) did not support that: They supported only placing name of a NAMED common block, so the only way to create a variable which is statically allocated (hence retains its value from one subroutine call to another), but is also private to a thread is to place that variable into a common block and declare it threadprivate.

Open MP standard specification is available at

http://openmp.org/wp/openmp-specifications/

Just click on

Latest Official OpenMP Specifications

  • Version 3.0 - (May, 2008). (PDF)

Unlike for the previous releases, the PDF document is now much bigger: 326 pages (vs. ~100), and is not user friendly (you probably have to hire an attorney to read it for you). The first useful example occurs on page 194. Look also at several following pages.

comment:3 by arango, 16 years ago

Resolution: Done
Status: reopenedclosed

Sasha, thank you for the clarification. Yes, indeed this is a nice option for OpenMP. The use of common blocks in F90 and inside of a module is an overkill. Perhaps, this is the reason why gfortran is having problem with the old construct. This is a stricter compiler.

Note: See TracTickets for help on using tickets.