Raise informative errors if v3 input files passed in

[misi9170]

Addresses #791

Checklist:

• Raise informative errors if v3 floris input yaml used
• Raise informative errors if v3 turbine yaml used
• Provide converter for v3 floris input yaml
• Provide conveter for v3 turbine yaml (see floris/tools/convert_turbine_v3_to_v4.py, introduced in Replace Cp with power in turbine definition and throughout FLORIS #765)

Notes and discussion points

• Can the converter utilities (for both turbine and the main floris input files) be used if Floris is installed from PyPI? If not, do we need to somehow add support for that?
• The check for a v3 floris input only raises an informative error if Floris is instantiated from a file---a more generic error will be raised if Floris is instantiated from a dictionary. I think this is OK, but I wanted to flag it here.
• We don't currently have a converter for cp -> power conversion for multidimensional turbines (where the cp/power curves are specified on a separate csv file). I think this is a small enough use case for the time being that we can ask users to do their own conversion, but again, I wanted to flag it.

[paulf81]

This is really great and very helpful, thank you @misi9170 !

[paulf81]

hi @misi9170 , I went through the code and thought it all looks great, thank you! I approved. I agree with your 2nd and 3rd comments that this is an ok way to leave things. Then on pip install, there I don't know, maybe something to see in beta testing?

[rafmudaf]

I like the spirit of this pull request, and I think it's a very helpful addition. Architecturally, this is mixing the physics model with the software infrastructure. I suggest to keep anything related to versioning, especially things you'll want to go back and change later as new versions come up, all in one place at the outer-most layer of the architecture. There was a place for this in the Floris class from the v2 to v3 shift (https://github.com/NREL/floris/blob/develop/floris/simulation/floris.py#L167). Essentially, when we read and deal with the Farm class in the future, we're not going to care about the input checking and messaging, so this adds more noise for our brains. Keeping it at the top allows us to forget about it until we need to go find it.

That being said, I'm happy with your decision on how to handle it.

[misi9170]

To help address my third point above, I've now added an explanation that the user will need to do their own conversion of the multidimensional turbine csv file if they call convert_floris_input_v3_to_v4.py on a floris input file that specifies multidim_cp_ct as the velocity model, as well as raising an error and an explanation if the user runs convert_turbine_v3_to_v4.py on a multidimensional turbine yaml.

[rafmudaf]

Regarding #829 (comment), @misi9170 and I looked at the options for catching outdated turbine inputs at a higher level in the architecture of FLORIS. The ideal time is prior to initializing the Floris object so in Floris.from_file or Floris.from_dict.

turbine_type can be either a list of dictionaries or a list of strings for the turbine names. If it's a list of dictionaries, inspecting the data is straightforward. However, if it's a list of strings referring to turbine names, then the turbine data are not yet available for inspection. This is specifically a problem when using the external turbine library feature.

Rather than trying to hack something together that is more complicated, we agreed it's best to have a more robust check within the Farm class rather than at the Floris class level.