Example 2 fails with RotorSE: True #240
Comments
|
Hi, These 02 examples are designed to be run without most parts of WISDEM. They will not update an OpenFAST model except to run different load cases. Enabling RotorSE will result in unexpected behavior. We are planning to release a series of software and documentation improvements over the next year with new ARPA-E funding, and we would be happy to discuss specific solutions for you and your team. Best, Dan |
|
Let's leave this issue open until we can throw an appropriate error for the situation posed. |
|
Hi @dzalkind, thanks for the explanation - I didn't understand the relationship between the modules and was going off of the settings for previous WEIS runs. I'm now encountering an issue where WEIS seems to run the first Case without any issue, but then does not proceed to the next one and seems to hang after printing the runtime for the completed Case, almost like it is expecting user input, but without any prompts about what to input. Do you know what might be causing this? Thank you! |
|
Hi Meg, Can you please share the output log? It may also just be that WEIS finished its runs. There should be two case_matrix files (one .txt and one .yaml) where you run the OpenFAST simulations. There, you can confirm which cases have been set up. Dan |
|
Hi Dan, I don't seem to have an output log that indicates what is happening in the backend, but the case matrix looks like all the cases are properly defined: Please advise how to enable the output log you are referring to - I don't see one in the WEIS yamls or the .fst file. ( Meg |
|
Hi Meg, By the output log, I mean the terminal messages from the WEIS run. You can Dan |
|
I'm not having success with that command. I've tried some variations, but as written I get:
If I try
which then hangs and I have to interrupt, leading to a long Traceback message. |
|
Instead of writing to your terminal, it's writing to |
|
Ah, I was expecting the file to be in the temp/ folder, but it was at the cd level. Now attached: It was hanging after
and required two CTRL+C interrupts before adding the final 4 lines of the file. |
|
Are you still running with the same modeling options that we defined here? Can you let it go for a while and try to figure out where it's hanging? Is there an error message that appears when you CTRL+C? |
|
I am still running it with the OpenFAST executable, I now have I have had it running since 5 ET, and so far the log only contains up until
(I have refreshed it a couple times). I can try a single keyboard interrupt to see what else comes in, since it seems to take 2 interrupts to fully kill the run. |
|
This time a single interrupt killed it, at which point the final 4 lines of the log file were printed, as in the version I shared. The terminal error message after the interrupt:
|
|
I let it run one more time before logging off (~5:30 PM ET) and just checked back on it (8:40 PM ET). It seems it wasn't hung, just taking an incredibly long time in between Cases. The first Case finished running in OpenFAST at 5:37 (~4 minute runtime on a 320s simulation), and OpenFAST was not called again until 6:18 PM for Case 2, finishing up about 4 minutes later as well. The 3rd Case started at 7:03 PM, the 4th at 7:48 PM, and the 5th at 8:30, which has completed but the 6th not yet begun. I will share the updated log file tomorrow once it is completed, but I don't see any messages in it that indicate why the delay between cases is so long. As far as I'm aware, all optimizations should be off and it should simply be reading and running the specified OpenFAST input files, though it's possible I've missed something somewhere. |
|
Hello Meg, thank you, that helps the debugging... Can you please check to make sure that your output files have a reasonable size (10-100 MB)? Is the number of output channel "ordinary" (100 or so), is your DT_Out in OpenFAST normal (100 Hz or so)? The alternative is that something went wrong with the compiling of pCrunch, but that would be a first. Also, is there a way for us to reproduce the issue locally? If not, feel free to send me an invite and we can do a screenshare |
|
Hi Pietro and Dan, Thank you both for your patience and support, I'm a bit embarrassed to say that everything seems to be working, I just overscoped the outputs for what my computer is capable of. I had nodal outputs turned on for both AeroDyn and ElastoDyn, for all 3 blades with more than 20 nodes in each case. Each output file was 1.13GB! I'm trying again with some different settings. I didn't realize how much of an impact the nodal settings would have on run time, but it makes sense in hindsight. I might suggest these would be good warnings/notes to include in documentation around nodal outputs. :) Thank you again for your support, and apologies if I wasted your time! |
Description
Hi again,
I am trying to run WEIS in the format of example 02, where an
openfast_fileandopenfast_dirare specified with the OpenFAST input files. I am able to both run example 02 and my own simulations with this format, until enabling RotorSE, at which point I get the errors below in the Current Behavior section (the errors are different for example 02 than for my own runs).In my own directory, I am using the IEA 15MW RWT model, though it seems to be a slightly different 'vintage', with 60 blade stations and other numerical differences vs. those in example 02.
I am not trying to run an optimization, simply to use WEIS's DLC-generation ability paired with more control over the OpenFAST input files, so if my error is around some attempted optimization task, please advise how to turn that off. I have set
driver: optimization: flag: Falseandrecorder: flag: Falsein themodeling_options.yamland am still getting the below error.If enabling RotorSE means something in the WEIS files needs to be configured differently, it would be great if documentation around those changes could be added - perhaps to the README file in that example's folder - as they are not self-evident.
Thanks very much for your help - this issue is keeping me from making progress in my day job!
Best,
Meg
Steps to reproduce issue
In example 02:
RotorSE: flag: Truein `modeling_options.yaml'python weis_driver.pyCurrent behavior
Example 02 error
My directory error
Note: this error comes after updating the
n_pitch_perf_surfacesparameter inmodeling_options.yamlto 104 to match the pitch vector dimension in theCp_Ct_Cq.txtfile, and then_tsr_perf_surfacesparameter to 72 for the same reason. I am unable to follow the proverbial thread in the error message to determine where themax_allowable_td_ratioshould be found.Expected behavior
Simulations run as expected and I am able to run DLCs through WEIS with OpenFAST input files defined.
Code versions
The text was updated successfully, but these errors were encountered: