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

Migrate OutListParameters.xlsx Into OpenFAST #413

Closed
jjonkman opened this issue Mar 16, 2020 · 8 comments
Closed

Migrate OutListParameters.xlsx Into OpenFAST #413

jjonkman opened this issue Mar 16, 2020 · 8 comments

Comments

@jjonkman
Copy link
Collaborator

As mentioned in #391, the OutListParameters.xlsx spreadsheet for ElastoDyn, ServoDyn, etc. have not yet been migrated from FAST v8.16 to OpenFAST. This spreadsheet contains a list of all possible output parameters from ElastoDyn, ServoDyn, etc., including their name(s), description, coordinate system, and units. Not only is this spreadsheet useful documentation, but it is also used to auto-generate output-processing source code, and so, is important to keep updated when changing the source code. This spreadsheet should be migrated to OpenFAST.

Also, as mentioned in the following topic on our forum: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=2458&p=14236, the local tower forces from ElastoDyn--TwrHt1FLxt, TwrHt1FLyt, and TwrHt1Flzt etc.--are not described correctly in the OutListParameters.xlsx spreadsheet. They should be described as "Local tower fore-aft shear force of tower gage 1", "Local tower side-to-side shear force of tower gage 1", and "Local tower axial force of tower gage 1" etc., respectively. This description should be fixed.

@rafmudaf
Copy link
Collaborator

Like @andrew-platt mentioned in #391 (comment), the spreadsheet does exist in some form in the openfast-library src. A few others are located in the module directories:

>>mbp@~/Development/openfast/modules (dev $)$ find . -name *xlsx
./openfast-library/src/OutListParameters.xlsx
./orcaflex-interface/src/OutListParameters.xlsx
./aerodyn/src/OutListParameters.xlsx
./aerodyn14/src/AD_RegistryEntries.xlsx
./inflowwind/src/OutListParameters.xlsx
./beamdyn/src/OutListParameters.xlsx

I'm not sure why there are two versions of some of these. In any case, if there's no functional reason for that, I suggest that they be consolidated into the "main" one in openfast-library.

@jjonkman
Copy link
Collaborator Author

Thanks @rafmudaf for clarifying! I misread @andrew-platt's comment.

Regardless, the OutListParameters.xlsx spreadsheet must still be updated/corrected.

For modularization sake, I would suggest having a separate OutListParameters.xlsx spreadsheet for each module that needs one. This is already the case for several modules, but I would suggest doing the same for ElastoDyn, ServoDyn, etc.

@bjonkman
Copy link
Contributor

I had a chat with @andrew-platt about the OutListParameters.xlsx file a few weeks back. As I told him, I really hate having multiple spreadsheets with the same name. It is painful to try to copy information between them because Excel can't have them both open at the same time.

@jjonkman
Copy link
Collaborator Author

How about appending the module name to each spreadsheet, e.g., OutListParameters_ElastoDyn.xlsx?

@bjonkman
Copy link
Contributor

That's better than all with the same name. However, I still prefer to have one spreadsheet with a tab for each module, and then put it in a documentation directory. It makes it easier to compare variable names against those in different modules.

@rafmudaf
Copy link
Collaborator

Good point - this should be moved to docs/ and included in a download link in the online documentation.

@andrew-platt
Copy link
Collaborator

If we move it to docs/, then there isn't much need to keep separate files. I had originally been of the opinion that the OutListParameters should be split out by module. However, after discussing it with @bjonkman, I am of the opinion that we should keep it all in a single file in the docs/. It is used more frequently as documentation reference than for generating code so it makes sense to keep it there.

If we didn't keep all the documentation in one place but rather split it out into each modules source directory, then I would lean towards splitting the OutListParameters.

@andrew-platt
Copy link
Collaborator

Updated in #429

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

No branches or pull requests

4 participants