- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am puzzled by the compiler error I get with the following part of my subroutine:
...
!$0MP PARALLEL DO DEFAULT(SHARED) PRIVATE(I_NL_SUBSET)
DO I_NL_SUBSET=1,N_NL_SUBSETS
IF (NL_SUBSETS_FLAGS(I_NL_SUBSET)) THEN
CALL SUB_NL_FCN(I_NL_SUBSET,NL_SUBSETS,X_TIME,FNL_TIME,STATE_TIME, &
N_NL_SUBSETS,N_TIME,N_TIME_PLUS_PADDING,N_NL_DOFS,SUB_ERROR)
ENDIF
ENDDO
!$OMP END PARALLEL DO
...
The error message I get is: "Error: Misplaced part of an OpenMP parallel directive", and it points to the END PARALLEL DO directive.
SUB_NL_FCN and SUB_ERRORare declared as EXTERNAL(they are dummy arguments). NL_SUBSET is of a type declared in a module. All other variables areof either REAL(8), INTEGER(4) type, some are arrays, all are dummy arguments passed to the subroutine which contains the parallel region above.
What is wrong here?
Thanks,
Olivier
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Olivier,
Try commenting out the two !$OMP statements _without_ touching any of the interviening code.
(Just place a C***Debug*** to the left of each statement/directive)
Then compile and check for errors
The purpose is to test to see if you have a problem with your continuation line. If you do have a problem with your continuation line then some other error will appear (e.g. bad IF statement)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I forgot to mention
In the sample code above the CALL statement is on the left margin. I assume this is not the case in your actual code.
However, if your call statement is located at the left margine then it is not a CALL statement... it is a Comment.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The END PARALLEL DO is superfluous here. If you want an END PARALLEL, you need
!$OMP PARALLEL
!$OMP DO
DO
....
ENDDO
!$OMP END PARALLEL
It's syntactically legal to have CALL starting in column 1 only if you use free form syntax compiler option. However, it's even more important to use a reasonable indentation scheme when using free format, if only to avoid sending yourself and others in chase of red herrings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim
Olivier used a single statement !$OMP PARALLEL DO therefore he needs to end with !$OMP END PARALLEL DO
He did not program to style you mentioned in your post (!$OMP PARALLEL, then !$OMP DO, then code, then !$OMP END DO, then !$OMP END PARALLEL)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your help... Actually... I found the mistake I made... nothing to be proud of... after all these years programming in Fortran...
... it's kind of the worse mistake you can make for your own ego...
... I realized that I wrote !$OMP with a 0 (zero) instead of the letter O...
Now, maybe the Fortran compiler could check the syntax of the OpenMP directives, to catch this kind of (really) silly mistake? Dr. Fortran, what do you think?
Justone of these days... so much time wasted for so little...
Olivier
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many years ago as an undergraduate, I spelled FORMAT with a 0, to get the apparently meaningless error message "this is not a Fortran statement". Just tried IVF with the same mistake - the compiler messages are not that more informative:
Error1 Error: Missing mandatory separating blank
Error2 Error: Syntax error, found IDENTIFIER 'X' when expecting one of: .EQV. .NEQV. .XOR. .OR. .AND. .LT. < .LE. <= .EQ. == .NE. /= .GT. >
Error3 Error: Syntax error, found END-OF-STATEMENT when expecting one of: => = .
Apart from the lack of colouring in MSVS which shows that "F0RMAT" is not a keyword, I still think it would take a while to work out why the statement won't compile. It seems that 30 years of compiler development still can't account for our stupid mistakes;-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page