Radiation virtual sensor calculations (for Plant and Array)

Discussion

Following discussion with @m.hamilton-jones and @l.feierl we came to a conclusion on how to specify radiation sensors on Arrays and Plants.

• Basically, an Array now has 3 calculated irradiance virtual sensors:
  • Output slots: Array attributes rd_gti, rd_bti and rd_dti (for global, beam & diffuse irradiance)
  • Same for Plant, including rd_dni

Calculation

• To calculate these output radiations, a Plant / Array has 4 input slots: A user can assign (exactly 0 or 1) Sensors to these slots:
  • Input slots: Plant / Array attributes _in_global, _in_diffuse, _in_beam, _in_dni
  • Tilt & orientation (metadata of global, diffuse, beam) can be same or different from the array's tilt & orientation. Tilt can also be zero (horizontal radiation).
  • The virtual sensor algorithms will take care to do the necessary conversions right. In case no conversion is necessary the input Sensor will be fed through, so no additional storage is required.
  • Input sensors might carry more information, e.g. the position of a sensor along the collector height. This is all stored in metadata and not reflected in the input channel names.
  • Radiation conversion works autonomously for each component: A Plant / Array uses only the 4 input slot Sensors to calculate its radiations, no other radiation Sensors taken into account. Plant information that is not sensor- or array-dependent may be used (e.g. Plant.te_amb etc).
• Use Cases: Use case overview uploaded as a design below, and editable as draw.io file

Shading / Masking of Arrays

• One idea to include shading & diffuse masking for Arrays could be to distinguish clearly between
  1. poa (plane of array) irradiances. rd_gti_poa, rd_bti_poa and rd_dti_poa
  2. and array irradiances which represent the beam shaded & diffuse masked irradiances. rd_gti, rd_bti and rd_dti
• This also makes the radiation conversion simpler as it reduces things to fewer cases.
• Downstream user / kernel / KPI methods can make a choice about what radiation specifically they want (poa or array).
• @d.tschopp Would be good to get your opinion on this.

Input data combinations: Not all combinations of input slots are valid, because some lead to non-solvable radiation. Implemented in virtual_sensors.py: assert_enough_radiation_inputs()

ok?	input data combination
✔	in_global
❌	only 1 input but not in_global
✔	in_global + any other
✔	in_beam + in_diffuse
✔	in_dni+ in_diffuse
❌	in_dni+ in_beam

Definition

/cc @l.feierl @d.tschopp