gbarter
commented
1 year ago Thank you for pointing out the issues you were encountering. I think these have now been resolved. In pCrunch, this PR contained the fixes to make that script run seamlessly. The pCrunch develop branch was then incorporated into the WEIS develop branch to keep things up to date.
In general, WEIS runs pCrunch in the background as the results are generated and the summary outputs are contained in the output csv / xlsx / mat / npy archives.
Description
When attempting to use pCrunch on existing WEIS-originated DLC output to obtain fatigue data like DELs, a number of errors occur suggesting that arguments being passed between different functions within pCrunch are not the correct arguments that should be getting passed.
Steps to reproduce issue
A coworker and I are currently working on a modified fork of WEIS (Coworker on Linux, I am on MacOS), but another coworker has had the same issues with the main branch of NREL/WEIS using RHEL servers.
Current behavior
----This is unusual, because the object fatparams in line 385 is supposed to be an instance of FatigueParams used in WEIS/weis/aeroelastice/openmdao_openfast.py (lines 1938, 1943, 1982, 2002, and 2020), and has the same input arguments as what is being checked in analysis.py, line 384 thru 387, where default values are being assigned, so the lifetime parameter should exist). Additionally, from the class definition of FatigueParams, the constructor method assigns default values to each parameter, so the parameter should exist in some form and not cause this error. ----Setting this up as a break point in VS Code, the argument fatparams appears to be an exact copy of _fatiguechannels from line 43 of the post_BatchRun.py script, which is not a FatigueParams instance. ----This error shows up if we try to used the WEIS/pCrunch/batch_processing.ipynb notebook example on a series of DLC output files, showing that the error is not contained to just one example script. ----In order to get past this error to see if we could get the script running, we tried hard-coding the input arguments in analysis.py, lines 384 thru 387 to the default constructor values from the FatigueParams class definition. The next error is the next problem we ran into.
Without looking further into the format of the case matrix or the actual data assigned to the variable cmatrix in a debugging environment, I would assume that either something about the current format of the case matrix is different from the assumed format of the case matrix that is being made in WEIS/pCrunch/pCrunch/utility.py, lines 200 thru 225, or the input data being assigned to the variable cmatrix in lines 171, 192 or 195 is not actually a case matrix, since the assumed type of the data being operated on is incompatible with the operations being applied to it. This is the point where Ben and I decided that this was a bigger issue that should probably be looked at in-depth by the WEIS development team.
Expected behavior
I have not yet seen this version of crunch run through to completion, but I would expect a successful run inside of post_BatchRun.py to produce a results subdirectory within the DLC output directory that has a summary_stats.yaml file, and would successfully process through extreme loads, damage equivalent loads, etc. That could be accessed with minor changes to the post_BatchRun.py script.