Allow space-separated entry by default #45
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.
Issue pointed out on the forums: https://forums.nrel.gov/t/the-rotorapexoffsetpos-array-was-not-assigned-valid-real-values-on-line-59-issue-with-openfast-toolbox/8616
The issue is reproducible and is occurring with entry
RotorApexOffsetPos
that has 3 components. Only the first one is being read since by default the toolbox is not accepting space-separated entries:openfast_toolbox/openfast_toolbox/io/fast_input_file.py
Line 475 in 2553643
This PR changes that behavior, even though I'm not directly changing the variable
allowSpaceSeparatedList
in the line above. Now, for every line, we read as many space-separated consecutive scalars and bools as possible. Strings are still only read once. The prior implementation only read two integers whenallowSpaceSeparatedList
is set to True:openfast_toolbox/openfast_toolbox/io/fast_input_file.py
Lines 1240 to 1242 in 2553643
Such restriction is now lifted.
The goal with the change is that when the user reads a file using
f = FASTInputFile('my_openfast_input.dat')
and then writes it again withf.write('my_openfast_input_mod.dat')
, no changes are introduced.There is one detail:
Now when the user specifies extra inputs because he/she knows OpenFAST will not read them, e.g.
2 3 WindType <comments>
, then the toolbox will in fact read both and re-write them as2, 3 WindType <comments>
. The new written file will still be read by OpenFAST normally, only taking into account the first value. However, some processing scripts might have checks likef['WindType']==2
and that would fail.