spec framework discussion

[bt-]

Starting this issue to continue the discussion from the pvlib issue that is the source for this open specification of the inputs to a pv energy model.

@mikofski, a few quick thoughts for now:

• The yaml file is definitely capturing the essence of what I was envisioning
• I just started looking through the nesting into dicts and lists of the layout parameters. I'll have to look at that more further. I think it might be helpful (at least for me) to generate example system(s) to see how they fit into the layout parameters.
• I like the counts concept
• I also like that it seems possible that this could lead to the ability to use this type of spec + pvlib to model exact systems, like different module types on different mppts of the same inverter. That is likely a longer term capabilty, I would think.
• It seems like the most complicated part of this will be how to standardize specification of array geometry. That seems quite daunting and it would be nice if it could be encapsulated a bit to keep the yaml readable. In my editor (Atom) code folding might be enough, but maybe a separate file to hold coordinates? This specific issue is mostly outside my knowledge. I used to use Sketchup quite a bit and liked that type of interface for quickly building arrays in a 3D interface.

I will plan to come back to this for a closer look.

[mikofski]

it might be helpful (at least for me) to generate example system(s) to see how they fit into the layout parameters.

great idea! I'll try to create a few as well, like the NIST ground array should be pretty straight forward. I think the examples could be kept in the repository if you agree? Thanks!

It seems like the most complicated part of this will be how to standardize specification of array geometry. That seems quite daunting and it would be nice if it could be encapsulated a bit to keep the yaml readable. In my editor (Atom) code folding might be enough, but maybe a separate file to hold coordinates?

I've been thinking about this too. A few thoughts that I haven't full hashed out:

• I think it would be useful to have terrain GIS files (like the ESRI shapefile format) specified in the PVspec similar to TMY and HOR files. In fact given the a geolocated GIS file, some function (from pvlib? other?) could possibly generate a HOR file
• I'm interested in your idea of a separate file for coordinates, can you elaborate on that?
• This spec does allow one to get quite fancy with the geometry with some assumptions, because you can potentially create so many layouts. But it might make sense to have a more detailed PVspec for more complicated 3D layouts, and a simpler PVspec for 2D layouts that are on a designated plane, in which case the GIS file would not be important?

A couple of unanswered questions I have:

• How to handle stringing options, as different arrays? For example, does each layout have an enumerated stringing option like ["straight", "C", "skip", "zig-zag"]
• How to handle variable GCR? Again as different layouts? Then does GCR refer to ahead or behind?
• How to handle mis-aligned rows, or row stop/start coordinates. Seems like every layout might need a position? Does that obviate the is_row_in_front and is_row_in_back fields?
• what about roads? Should there also be is_at_edge_of_array field for each layout?
• At the top level I think the site should have a grade or a GIS file.
• Are rows required to be parallel when viewed from above? Seems fair, but would this rule out any sites? Are those few without parallel rows okay to leave out, or save for the more detailed spec?

I'm not too concerned about having the yaml file getting too large, b/c as you said, you can fold/collapse layouts, inverters, xfmrs you want to hide, and also if it's so big, then I think you would have to import it into some viewer like SolarFarmer, PVsyst, PlantPredict, PVCAD-Mega, Helios3D, etc. assuming they exist.

[bt-]

@gall9488, I know that you spent some time working on an efficient way to translate ACAD array layouts into PVsyst 3D scenes, so I thought you might have some thoughts on the geometry part of this as well. "This" being the beginnings of a yaml specification for defining inputs to PV energy models intended to ultimately be usable across different modelling tools (SolarFarmer, PVsyst, PlantPredict, SAM, pvlib, etc.).

[gall9488]

I'm coming into this blind so I don't know if this explanation is applicable -- we'll need to talk offline @bt- . I built out this calculator ~3 years ago before switching job scopes.

The basic idea is an array or subarray with consistent pitch (N-S) and topo can be reduced to 2 points: Upper Corner and Lower Corner. When subtracted, these corners define a total N-S and E-W measured length. Adding in some module/row/string definitions will allow you to interpolate number of modules per row, strings per row, landscape v portrait orientation, vertical height. Definitions include:

• module dimensions and tilt
• modules in portrait
• pitch
• E-W offset (for rows that do not perfectly align north and south - such as following a diagonal road, etc.
• 'string' length (to break down the number of strings per row in the E-W direction)

In the case of the calculator, I used a macro to export the relative location of the cursor whenever a click occured in AutoCAD to an excel file. Click one corner, click the opposite corner. It does not matter how many rows you capture between these two points. It can be 1 or 5,000 - doesn't matter.

Excel would then take these points and apply a series of manipulations to the data. I built an Excel macro to assemble a text file in the exact form/structure that is compatible with PVSyst after processing the raw data into the inputs PVSyst likes. It's an easy jump from there to switch the PVSyst definition from 'row' to 'shade object'. I expanded the structure to include shading objects (singular trees or poles, overhead wires, and/or a full stand of trees, fences, equipment pads, etc)

All that now to say...

You can add another layer of calculations to look at the Z component of the AutoCAD points. As long as the grade is relatively consistent across this array/subarray then Z components can be added to the row definitions in the PVSyst file. I defined a virtual plane by manually measuring the N-S slope and E-W slope in CAD using a straight line formula [m=(y2-y1)/(x2-x1)]. From here, I calculated the Z-components of the N-S and E-W slopes. I added these Z contributions together based on the location of each row and bingo -- 3D scene.

This really only worked for basic topos -- max 2-3 slopes per site. If a row spans two topo planes then you break the row into 2 rows.

Not sure if this helps. It's dense so let me know if you need clarifications.

[gall9488]

I should also add that this method will copy the array exactly as shown in CAD. This is accurate down to the fractions of an inch.

[kandersolar]

Hello, just dropping by to mention a project I came across that might be a good point of comparison: https://github.com/IEAWindTask37/ontology

[gall9488]

I was considering this PV optimization/automation last weekend so it's interesting you reached out when you did. Are there any additional questions or clarifications from earlier?

[kandersolar]

Hello, here is my second annual "I stumbled upon something that seems relevant" comment ;)

https://github.com/OpenEnergyPlatform/ontology and https://doi.org/10.1016/j.egyai.2021.100074