IES_Toolkit: Push 'PVPanel' type

[rboulton-BH]

Description:

PV Panels are considered a different geometry type in IES and their geometry is really difficult to handle in the software. it is not possible to draw an element then set it as a PV panel, they must be either drawn with a specific tool or imported via GEM file.

It would be really useful to be able to define the PV Panel geometry in another tool (e.g. Rhino/Grasshopper) then import these into IES via GEM. For this, the IES_Toolkit will need to recognise that the BHoM Panel type = SolarPanel (or other implementation if more appropriate) means that the geometry body in GEM is of Category = 3, Type = 202 and SubType = 0, as shown in the snapshot below.

Will need to take care with surface normals when implementing this. Frustratingly, in IES, PV Panels look exactly the same on the front and the back but will inhibit different characteristics if they are facing the wrong direction (basically the sun shines on to the back of the panel therefore there's no electricity generated!). Users will somehow need to understand which way the panel is orientated before import. It'll also be tricky to check that these things are importing correctly during testing!

[FraserGreenroyd]

Will need to take care with surface normals when implementing this. Frustratingly, in IES, PV Panels look exactly the same on the front and the back but will inhibit different characteristics if they are facing the wrong direction (basically the sun shines on to the back of the panel therefore there's no electricity generated!). Users will somehow need to understand which way the panel is orientated before import. It'll also be tricky to check that these things are importing correctly during testing!

So for all panels that make up a space, we take the normal to be pointing away from the space. But I'm guessing PV panels don't have a space attributed to them which would make this harder to check? Would it be safer to assume the normal should be pointing towards a given sun location (I wanna say 'up' but I feel like that would not account for too many use cases to be valid)? If so, we might need to link this in with the SunPosition object to help, it might need to be an extended workflow perhaps?

[charliebrookerBH]

Looks like PV geo set up is super simple. Coordinates for bottom left corner, x and y dimensions, rotation angle CCW from N, and an angle of inclination from the bottom edge of the surface

[charliebrookerBH]

@milogillot-BH has got the basis of this set up here!

rhino PV to gem.zip

[charliebrookerBH]

PV GEM Template below

LAYER
1
COLOUR
0
CATEGORY
3
TYPE
202
SUBTYPE
0
COLOURRGB
32767
PVP PV Panel [PV000000]
1.650000 0.050000 0.000000 2.000000 1.000000 270.000000 10.000000

Format below
PVP PV Panel [PV000000]
x-coordinate y-coordinate z-coordinate x-dimension y-dimension orientation tilt

Note the rotation input I used to generate this PV panel was 90, but the orientation parameter in the GEM is 270.

@jamesramsden-bh and @milogillot-BH to set aside an hour to convert the GH script into C# code. Likely needs to be on IES TK refactor branch that @kprusicka and @FraserGreenroyd are working on as it needs to be in the new adapter code location etc.

[charliebrookerBH]

x and y dimension are positive in the x and negative in the y (giving the PV base point as top left).

Rotation is then applied after this, as shown.

Need to understand how this relates to BHoM panels in order to get surface direction correct. @kprusicka may have thoughts from handling normal direction for the push.

[jamesramsden-bh]

A prototype solution was developed for PR #207 but was not merged as it was not compatible with work being done on panels. Attached the .cs file that contains a standalone working solution that could be used as the basis for the fix for this issue.
SolarPanel.zip