Bugfix: Unexpected behavior in SerialRefine caused by quiet NaNs

[paulf81]

Description

If the farm power used in the Serial-Refine optimization method returns NaN (for example, some combination of yaw angles results in an invalid or unrealistic solution), then Serial Refine quietly tests the NaN case, finds it makes no improvement, and so defaults to no change. In the included example (75_check_sr.py), optimizing over 4 turbines (with a large range of yaw angles +/-50 deg to provoke the issue), before the suggested change to the argmax gives clearly suboptimal yaw angle result:

GCH optimal: [31.25 25. 0. 0. ]

In the proposed code change, by replacing argmax with nanargmax, we improve the situation by allowing the test comparison:

ids_better = (farm_powers_opt_new > farm_powers_opt_prev)

To use the best non-nan case, instead of using the nan case.

Additionally, to make this issue less silent, we issue a warning to the user.

With the change, the final output in example 75_check_sr.py is:

GCH optimal: [31.25 25. 18.75 0. ]

Impacted areas of the software

yaw_optimizer_sr.py

[Bartdoekemeijer]

Hi @paulf81, interesting problem! Can you give an example why a farm power production value would be NaN? Also, maybe more a question to @rafmudaf, should we be raising warmings using the logger or is this fine?

[paulf81]

Hi @Bartdoekemeijer, sorry! i missed all the comments I had originally included in the post I accidentally put into a comment box (@rafmudaf , maybe I can ask we can review the new format quickly? I couldn't tell where to put the body of the description of the pull request). To answer your question, if you try the temporary example 75 with nanargmin back to argmin you will see the issue. In this case we are using a too large yaw angle, but no the nan occurence is a little unpredictable. Then also, we see for large farms this can sometimes happen without very large angles, but haven't got it pinned yet.

[misi9170]

@paulf81 thanks for doing this! @Bartdoekemeijer another use case is, as Paul mentioned, when there is a large FLORIS calculation going that could be producing NaNs for unknown reasons. When running within a serial refine operation, those NaNs would get silently ignored and serial refine would provide an output that is not optimal, which is confusing to the user. This happened to me recently because there were minor bugs in the new model (producing NaNs that I wasn't aware of). This new implementation will both

• Let the user know that there were NaNs in the serial refine computation, and
• Proceed to provide reasonable outputs even in the presence of NaNs.

Perhaps more often than not, the NaNs are coming from something buggy upstream, but I think it's still helpful for serial refine to call them out so that the user could go back and search for what causes them.

[rafmudaf]

Also, maybe more a question to @rafmudaf, should we be raising warmings using the logger or is this fine?

Yes, good catch @Bartdoekemeijer. The warning message should use the logging infrastructure. This allows to use a consistent formatting and integrates with the settings in the input file for logging location (stdout/stderr vs file) and logging level.

[Bartdoekemeijer]

Perhaps more often than not, the NaNs are coming from something buggy upstream, but I think it's still helpful for serial refine to call them out so that the user could go back and search for what causes them.

Ah that makes sense. I agree!

[rafmudaf]

@misi9170 @paulf81 do you intend for @Bartdoekemeijer and @bayc to review, as well?

[paulf81]

I believe we're good to merge now @rafmudaf , thank you!