[Feature]: Bring back verbose option (default False?) to the function df_mark_turbdata_as_faulty

[paulf81]

Description

In one of the more recent changes, df_mark_turbdata_as_faulty, I think lost its verbose option. I think this can be handy in case where you use this function directly (rather than within ws_power_curve filtering). Could we bring it back? Or was it slowing things down? @misi9170 and @Bartdoekemeijer do you know?

Related URLs

No response

[misi9170]

No problem from my perspective. I think the big revamp in this module was #78 , so as long as @Bartdoekemeijer is not aware of any reason not to have a verbose option, I think it could be reintroduced

[Bartdoekemeijer]

I dropped it back then because I felt like it wasn't sufficiently informative. It just said it increased the number of invalid measurements from X to Y, but it didn't mention the filter reason. I moved print statements from this lowest-level function up to the ws_pow_filtering class, see https://github.com/NREL/flasc/blob/7087338f31841f65028fd03d5f3f836795dc6721/flasc/turbine_analysis/ws_pow_filtering.py#L251

This gives more informative messages like

Faulty measurements for WTG 021 increased from 15.116 % to 18.129 %. Reason: 'Curtailment between 6 and 10 m/s'.

Though, I'm not opposed to re-adding a verbose option to df_mark_turbdata_as_faulty. I also think FLASC may generally require some rethinking on how we should be logging/printing information to the console. Perhaps it could benefit from some sort of logger like FLORIS has.

[misi9170]

I also think FLASC may generally require some rethinking on how we should be logging/printing information to the console. Perhaps it could benefit from some sort of logger like FLORIS has.

I like the idea of a logger. It's a bit strange that we often set warnings to ignore in the example notebooks because there is a lot of printout to screen---that seems like something we should be able to clean up and handle better. If they are legitimate warnings, we shouldn't be ignoring them or encouraging our users to ignore them

[paulf81]

Agree, I think adopting the FLORIS logging approach directly is probably the most straightforward solution, I can open an issue on it.

This is probably a little off topic, but it came up in the. same line of work, we use ws_pow_filtering, to handle some filters that aren't themselves "ws-pow" filtering per se, I wonder if in this same re-work, we could make that name more general? I also think elements of things in dataframe_filtering and ws_pow_filtering, should be brought together into one module?

[paulf81]

Closing in favor of more general approach in #135