Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move calls to GetNewUnit into file opening routines and wrap with !$OMP critical #2538

Closed

Conversation

andrew-platt
Copy link
Collaborator

This is ready to merge

Feature or improvement description
We have had issues with unit numbers when opening files for many years when OpenMP is used. The root issue was that the GetNewUnit call was separate from the actual file opening. This could lead to race conditions when multiple threads hit a GetNewUnit before the retrieved unit numbers were used to open the corresponding files.

To solve this, we moved all the GetNewUnit calls into the Open*File subroutines in NWTC_IO.f90. Inside those routines we wrap the GetNewUnit and open(*) command pairs in a !$OMP critical block. This should prevent the same unit number from being given out to two different OpenMP threads at once.

We debated if this should go into 3.5.5 or 4.0.0. In the end we decided this would be better to address in 3.5.5, mostly so that I don't have to field any more questions or bug reports about it when users stay on the 3.5.x series longer.

Related issue, if one exists
#2510
There were many others over the years that we suspect may be related.

Impacted areas of the software
This change should be completely transparent to the end users, but should fix issues with conflicting unit numbers when OpenMP is used.

Additional supporting information
We originally thought about wrapping the original GetNewUnit calls and the following Open*File calls, but decided that would complicate the code considerably. Instead we decided it was simpler to move the GetNewUnit calls and handle the !$OMP critical block in the library so future programmers would not need to think about it.

Test results, if applicable
No test results should change.

I'm not positive this is necessary without more advanced OMP directives that the `!$OMP critical`.  With my luck though, some obscure compiler will be unhappy about it if I don't.
END IF

!$OMP critical
call GetNewUnit(Un,ErrStat,ErrMsg)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For backward compatibility, could you wrap this call to GetNewUnit (here and the other places it's now called) in an IF statement like IF (Un < 0) call GetNewUnit()?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, GetNewUnit could be changed to start looking at units at the given Un value if it's >= 0. Otherwise, Un is really intent(out) only.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll wrap those calls in an if statement. I think we want to maintain that backwards compatibility for now.

@andrew-platt andrew-platt force-pushed the f/GetNewUnit_in_fileOpening branch from bccfe13 to 64316e6 Compare December 3, 2024 21:53
@andrew-platt andrew-platt force-pushed the f/GetNewUnit_in_fileOpening branch from 64316e6 to 7c80785 Compare December 3, 2024 21:57
@andrew-platt andrew-platt force-pushed the f/GetNewUnit_in_fileOpening branch from 7c80785 to 683ae61 Compare December 3, 2024 22:27
@andrew-platt
Copy link
Collaborator Author

After discussing this with @deslaughter, we concluded that there are to many code changes going into this PR to make sense for a 3.5.5 release.

I am closing this PR and will open a new one to dev with a reworked version of these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants