MPI logic is not working with RAFT (level 1) optimization #324
Comments
|
@dzalkind This is the issue that I discussed with you today. I will follow up with this issue once I figure out more details. Thank you. |
|
I think part of the issue here is that the WEIS/weis/glue_code/runWEIS.py Line 165 in 08517c7 If the optimization flag in the analysis options is set to True, this example works. However, we should be able to detect the flags in the design variables. Looking into that next. |
|
I think, based on the schema, this condition should always be true: https://github.com/WISDEM/WISDEM/blob/992076a14bf2f18defc1dd5be17e72c89e83431f/wisdem/glue_code/gc_LoadInputs.py#L650 @gbarter or @ptrbortolotti, has anything changed in this area or should we do that recursive search regardless? |
I think that line predates the schema. I agree that with the schema and enforcement of defaults, the check is unnecessary. |
|
I also don't like it. I am not sure how that check made its way into the code, but essentially if any DV is set to be optimized, the opt solver flag is set to True regardless of the user input. do we want that? I like to have that master switch turning on and off optimizations in my analysis options yamls, especially because it helps switch between optimization and DOE. all in all, I'm in favor of changing those four line to |
|
I agree that it's confusing when flags are changed by the software and not the user. I believe the code is never going to the |
|
@dzalkind I didn't pay attention to the schema before, but even if DV is flagged, it would be ideal to let users easily switch to do the optimization or not. Thank you for figuring this out. At this moment, I can just be consistent in setting the opt_flag along with what I want to solve. |
|
@dzalkind Another problem I wanted to bring up is that it behaves differently when MPI is used or not. I think the code should behave consistently whether or not the MPI is used. |
|
I agree with that. We can address that in our upcoming MPI work. What exactly is happening that's different? Is it trying to optimize just because we're using MPI? |
|
A different but related issue is when we need to run OpenFAST/DFSM simulations in parallel as part of the DOE studies. I'm adding a workaround I found for this issue, per @dzalkind's directions. Running DOE studies with OpenFAST simulations in parallel hangs when generating the turbsim files. The workaround that runs just the openfast simulations in parallel for every DOE iteration is as follows:
It would be nice if this issue can also be fixed. |
Description
The new MPI implementation utilizing the OpenMDAO's MPI object seems to work fine with OpenFAST examples, but it is not working with level 1 RAFT examples.
Steps to reproduce issue
developbranch and move toexamples/15_RAFT_Studiesdirectorympirun -np 4 python weis_driver_raft_opt.pyCurrent behavior
Expected behavior
Runs well with utilizing all cores in finite differencing
Code versions
The text was updated successfully, but these errors were encountered: