Open bt- opened 4 years ago
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:
A couple of unanswered questions I have:
is_row_in_front
and is_row_in_back
fields?is_at_edge_of_array
field for each layout?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.
@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.).
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:
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.
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.
Hello, just dropping by to mention a project I came across that might be a good point of comparison: https://github.com/IEAWindTask37/ontology
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?
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
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:
I will plan to come back to this for a closer look.