- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear All,
I am new on this forum and I am facing a problem so confusing for me that this is one of the last place to find help
I have Fortran program including different versions of Fortran syntax (77 and 90) using paralellized OMP technics for some parts of the program. The program is used through a dll, main functions are called from an another main program. Interfaces functions are not paralellized.
I updated make file options from Intel parallel studio XE2011 to OneAPI2021.4. Flags options for the first version were:
ifeq ($(TYPE_COMPIL), optim)
FCFLAGS = /O2 /Qopenmp /Qfpp /Qparallel /Qopenmp-link:static \
/debug:full /debug-parameters:all
else
FCFLAGS = /GS \
/check:format,arg_temp_created /debug:full \
/debug-parameters:all /traceback /fpe0 /CU \
/Qfpp /Qopenmp /Qopenmp-link:static
endif
DFLAGS = /assume:byterecl /convert:big_endian /Qsafe-cray-ptr \
/DCN_RSIZE=4 /DCN_ISIZE=4 /DARCH64 /real-size:32 /integer-size:32
Flags options for the OneAPI2021.4 version were:
ifeq ($(TYPE_COMPIL), optim)
FCFLAGS = /O1 /fp:precise /Qopenmp /fpp /Qparallel /debug:full \
/debug-parameters:all
else
FCFLAGS = /GS /fp:precise \
/check:format,arg_temp_created /debug:full \
/debug-parameters:all /traceback /fpe0 /CU \
/fpp /Qopenmp
endif
DFLAGS = /assume:byterecl /convert:big_endian /Qsafe-cray-ptr \
/DCN_RSIZE=4 /DCN_ISIZE=4 /DARCH64 /real-size:32 /integer-size:32
To sum up I switched from O2 to O1, add /fp:precise option remove /Qfpp and /Qopenmp-link:static. These two last flags are no more supported by OneAPI version.
Compilation is OK but during runing the program some random overflow exception occurs on one array named SIG . This array made of 400 values is sometime well initialized and some time not, even though initializing loop is applied each time.
OMP instruction are used before array is initialized as followed:
I suspect modification about OMP technic, but I have no idea about how to handle this problem. Any idea or thinkfull suggestion would be very much appreciated, thank you very much.
For any further information feel free to ask me.
All the best
JohnB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The workaround is needed beginning with 2021.10.0. Applying the workaround to your code will ease your migration to ifx.
@JohnBeshop, do you know that ifort is deprecated and will be no longer be available at the end of 2024?
ifx is the new Intel Fortran Compiler. It's evolving fast so you'll want to use the latest release, 2024.0.0.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If your parallel region contains a CALL to a subroutine (or function) that uses one or more of the common blocks listed on your COPYIN, then that(those) procedure(s) will reference the main thread's common blocks (not the thread team member's copy).
What I suggest doing is:
1) add DEFAULT(none) to the PARALLEL DO
2) replace COPYIN with FIRSTPRIVATE
3) remove the /CommonBlockNames/
Compile, to produce an error list of variables of the common blocks that are used in the parallel region.
4) For each variable, verify the listed variable is contained in a former listed common block and if so, add those variable names to the FIRSTPRIVATE list, if not listed in one of the former listed common blocks then this may be a data sharing problem with your code to be investigated.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried following lines, I am not sure if it's correct could you confirm ? Thank you !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes.
Now when you compile, you will receive error reports of the use of references to the COMMON block variables made within the parallel region. You may also get error reports of other variables in the scope of the procedure reference in the parallel region. For the common block variables in error, add to the FIRSTPRIVE clause. If any procedure scoped variables reported as error, you will have to determine how it is to be used (private, shared, firstprivate).
Also it is important to make a build and run with all compile time checks (i.e. interfaces) and runtime checks (array bounds, uninitialized variables, etc...). After any resolutions, you can then remove the checks.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, have you bult a Debug (OpenMP) configuration with all compile time and runtime diagnostics enabled? This will verify your interfaces, index out of bounds and some of the uninitialized variable accesses.
When you reach the point of modernizing your code, consider converting the common blocks into module user defined types:
! YourModuleNameHere.f90
module commons_mod
type CCRN_t
real :: variableNameHere
...
end type CCRN_T
!$OMP threadprivate(CCRN)
type(CCRN_T) :: CCRN
... ! other types here
end module commons_mod
Then in your code where referencing those data add:
use commons_mod
To reference the variables
CCRN%variableNameHere
Whole word Find and Replace will make quick work of the edits.
Note, you can also threadprivate(/YourCommonBlockHere/), but that might introduce additional problems if your use of accessing the common blocks is not consistent.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
Thanks a lot for your advice, I will try them and let you know how it works in few days. Any how it's not tell me why it seems to work with XE2011 but not with OneAPI2021.4.
Any how appreciate your help !
All the best
JohnB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Incorrect programs with undefined behavior may seem to "work", but then fail with a compiler or settings change.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That was a real challenge when migrating from MS Fortran 3.13 to Powerstation, the changes nearly drove me crazy.
It is a much bigger problem with some of the modern languages such as C#.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There's this comment in the Fortran Release Notes about COMMON blocks and OpenMP data sharing clauses:
COMMON Block
Beginning with the Intel Fortran Compiler (ifx) version 2023.2.0 and the Intel Fortran Complier Classic (ifort) version 2021.10.0,
programs that declare a COMMON block, instead of individual COMMON block variables, in an OpenMP data sharing clause cause a runtime failure, i.e. segmentation fault or incorrect result. The workaround is to declare the individual COMMON block variables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Barbara thank you for your help,
do you mean that for my version intel oneAPI 2021.4 the work around you proposed should work also ? Or do I have to use at least 2021.10.0 and apply this workaround ?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The workaround is needed beginning with 2021.10.0. Applying the workaround to your code will ease your migration to ifx.
@JohnBeshop, do you know that ifort is deprecated and will be no longer be available at the end of 2024?
ifx is the new Intel Fortran Compiler. It's evolving fast so you'll want to use the latest release, 2024.0.0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Barbara,
What about the common block variables within /commonBlockName/ and
!$omp threadprivate(/commonBlockName/)
Where the /commonBlockName/ is declared in a module and used elsewhere.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim -
THREADPRIVATE common blocks should be OK.
--Lorri
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page