FlorisInterface Redesign

[RHammond2]

@rafmudaf, I wanted to start a discussion to keep track of some of our early thoughts on how to redesign the FlorisInterface to promote better usage practices.

A few of our high level concerns/thoughts/questions could be summarized as follows:

• Some methods rerun calculate_wake compared to others despite similar naming conventions, so we should either have separate analysis and get_x workflows, or use a separate interface for analysis running and results getting.
  • A big concern from my end is some methods reset an analysis and some do not, so for some workflows we can get intermediary calculations, but for others, we have just the one output. This means that for some use cases, users have to rewrite basic FlorisInterface code, which is unideal because it opens users up to significant errors.
  • Analysis method calls should run calculate_wake if it hasn't been run yet, but not reset the workflow. This could be slightly problematic because some analysis methods modify the configuration, and so not resetting those values will be a huge break in compatibility.
• Is Floris and FlorisInterface entirely redundant, so should one get removed in favor of the other? Or some kind of hybridization?
• What do we actual want out of a user interface? How do we create a design that encourages better coding patterns, for example, not loading a file and reintializing to change basic parameters?
  • To help avoid these repetitions, it would be helpful to be able to save a loadable configuration to enable reuse.
  • All of our examples should also avoid using these patterns to discourage this usage.

[wjscooty]

hello，do you know how to change the parameters in .yaml without creating a new .yaml?

[rafmudaf]

This question is out of scope for this particular discussion. Please create a new discussion under the q&a category and we will provide a response asap.