Increase number of unit numbers available for OMP file opening #2339
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We were having problems with the `!OMP` directives around high resolution file reading in AWAE.f90. Since the file reading starts with a call to `GetNewUnit` before starting the opening, parallel calls to `GetNewUnit` could result in the same unit number handed out to two processes. The first process would open the file and start reading, but then the second process would open a different file with the same unit number causing read errors for both processes as they attempted to read the same file at the same time. To resolve this, an optional start unit number is added to `GtNewUnit`. This optional argument is propagated up through to the calls within the `!OMP` loop where a `N*100` is used as the starting unit number for the search (where `N` is the turbine number). Theoretically this will solve the parallel file reading issue from AWAE. Routine changes: `GetNewUnit` - Increased maximum unit from 1024 to 64k (likely won't be an issue since most times where more than 1024 files are needed will be on supercomputers where the unit number limit is really high) - optional argument for starting unit number. Defaults to old behaviour when not present. `ReadLowResWindFile` - optional argument for starting unit number. Defaults to old behaviour when not present. `ReadHighResWindFile` - optional argument for starting unit number. Defaults to old behaviour when not present. AWAE `UpdateStates` - call to `ReadHighResWindFile` includes `nt*100` as the start unit number
|
Closing this in preference of the simpler solution in #2340 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Needs testing and approval by @rthedin before merging
Feature or improvement description
We were having problems with the
!OMPdirectives around high resolution file reading in AWAE.f90. Since the file reading starts with a call toGetNewUnitbefore starting the opening, parallel calls toGetNewUnitcould result in the same unit number handed out to two processes. The first process would open the file and start reading, but then the second process would open a different file with the same unit number causing read errors for both processes as they attempted to read the same file at the same time.To resolve this, an optional start unit number is added to
GtNewUnit. This optional argument is propagated up through to the calls within the!OMPloop where aN*100is used as the starting unit number for the search (whereNis the turbine number). Theoretically this will solve the parallel file reading issue from AWAE.Routine changes:
GetNewUnitReadLowResWindFileReadHighResWindFileUpdateStatesReadHighResWindFileincludesnt*100as the start unit numberRelated issue, if one exists
There may be several FAST.Farm issues related to this, but it is unknown at the moment.
Impacted areas of the software
FAST.Farm
AWAEmodule file reading of high-res VTK files inside the!OMPdirective inUpdateStatesAdditional supporting information