How should technology-level details be defined in the yaml?

[johnjasa]

We'll often need to define parameters for a technology that will be used for the performance, cost, LCA models, etc. We'll want to make it clear where to define these values and how to make sure they're only defined in one place.

Here, I have an example implementation of the details entry containing that information. What is a good name for these details? They're not specific to a particular performance or cost model, but generally define the technology itself (in this case a wind plant). I don't love the name details.

technologies:
  wind:
    performance_model:
      model: "wind_plant"
    cost_model:
      model: "wind_plant"
    resource: 
      type: "pysam_wind"
      wind_speed: 9.
    details:  # need a much better name for this
      num_turbines: 20
      turbine_rating_kw: 3000.0
      rotor_diameter: 120.0
      hub_height: 100.0
      layout_mode: "grid"
      model_name: "pysam"
      model_input_file: null
      layout_params:
        border_spacing: 0.5
        border_offset: 0.5
        grid_angle: 2.0
        grid_aspect_power: 4.0
        row_phase_offset: 0.2
      rating_range_kw: [1000, 5000]
      floris_config: null
      operational_losses: 10.0
      timestep: [1, 60]
      fin_model: "default"
      name: "UtilityScaleWindPlant"

[genevievestarke]

technology specifications?

[jaredthomas68]

I think technologies with their own subsystems, like wind turbines in wind plants, could/should have their own input files that could just be included. This will make it simple to swap out turbine types or do mixed turbine types. The other benefit of this is that some models (ORBIT, FLORIS, etc) may require specifically formatted files and/or dictionaries that may not match our style. Thus, I think the detail section could even just be a file name or "include".

Perhaps a section or file name entry for each model for a given tech (physical system, performance, cost, etc).

Specifying for each tech model is also where we start having things defined in multiple places, so we probably need a way to handle that effectively, like a placeholder in the lower level files if a given field needs to be filled from the higher level information (like site or system)

[jaredthomas68]

We may also want to adopt standards for a given tech if they exist, such as WindIO for wind:
https://github.com/IEAWindTask37/windIO

[bayc]

I think the details should fall under the specification of the model that they pertain to, e.g.:

technologies:
  wind:
    name: "UtilityScaleWindPlant"
    performance_model:
      model: "wind_plant"
      num_turbines: 20
      turbine_rating_kw: 3000.0
      rotor_diameter: 120.0
      hub_height: 100.0
      layout_mode: "grid"
      model_name: "pysam"
      model_input_file: null
      layout_params:
        border_spacing: 0.5
        border_offset: 0.5
        grid_angle: 2.0
        grid_aspect_power: 4.0
        row_phase_offset: 0.2
      rating_range_kw: [1000, 5000]
      floris_config: null
      operational_losses: 10.0
      timestep: [1, 60]
      resource: 
        type: "pysam_wind"
        wind_speed: 9.
    cost_model:
      model: "wind_plant"
    finance_model:    
      fin_model: "default"

My reasoning is that there may be different inputs required for different models, and by including them with their models, it simplifies the dictionary processing as well as updating input files for different models/inputs.

And in response to Jared's file suggestion, I think anywhere in the yaml dictionary specification, any dictionary or sub-dictionary can be replaced with a separate yaml file, and we can use the current utilities to !include those files as needed.

Also, I was initially thinking that the model parameter under performance_model, cost_model, and finance_model would be the name of the model being used, e.g. floris, pysam, orbit.

[johnjasa]

I think the details should fall under the specification of the model that they pertain to, e.g.:

My reasoning is that there may be different inputs required for different models, and by including them with their models, it simplifies the dictionary processing as well as updating input files for different models/inputs.

Great input here, thanks y'all.

Chris, I debated having the details be part of the individual models as you suggest but hesitated due to items like num_turbines or rotor_diameter. Presumably both the performance and cost models would need to know the number of turbines. Should we have each model specify it in the yaml individually (so a user might have to change it in two places if modifying the file), or use a yaml variable defined once and used in multiple places like WISDEM does here?