beta GUI and new internal geometry handling
GUI: Graphical User Interface
Finally! It's here! And it will help you make all your modeling dreams true! Or most of them at least. The GUI reads configuration files with input variables, saves configuration files with input variables, helps you set the necessary variables for the type of simulation you want to run, and finally runs it for you! Check it out and send us feedback, we need some beta testers!
modelChains
Powering the GUI, and as an option to simplify your own simulation-needs, we have bundled functions for the fixed and tracking simulation options into a modelChain available in modelChain.py. This modelChain covers all input parameters and options currently available as procedures on bifacial_radiance.
Installation and Tutorials Video
Installation video!
And tutorial video on how to install bifacial_radiance available here
Keep an eye out for more videos describing bifacial_radiance inner workings, how to use the journals, the modelChains and the GUI soon!
Dictionary gallore.
The program options have grown so much, we have started to agglomerate variables into dictionaries. This are plenty useful with the modelChain and the GUI, and you can find an example with ALL of the possible inputvalues in data/default.ini.
Also, some of the functions on load.py help load saved dictionaries saved as *.ini files and validate that all of the necessary inputs needed by the simulation desired are present, so you never forget a variable anymore!
cell Level Module
In order to evaluate the importance of the packaging factor of a module (which was expressed as transmission factor in bifacial_vf for example) or in other words the effect of varying cell spacing / cell size in a module, makeModule now can take a dictionary that defines the sizes of the cell (xcell and ycell) and the spacing between the cells (xcellgap, ycellgap, and zcellgap).
axis of Rotation TorqueTube
This was bugging us, so we added the option to rotate the modules around themselves (which was the default case before) or around an axis of rotation, defined usually as the center of the torquetube.
The post marks the 0,0 location. The star marks where the rotation axis is at. For the image in the left, it is in the center between the 2-UP modules, so when they are inclined to this 45 degree the torquetube gets moved off from the X = 0 axis. On the image in the right, the rotation is around the torquetube's center.
clearance_height and hub_height distinction.
Before, we were using 'height' to define both clearance_height and hub_height, and the program internally decided how to interpret that depending if it was a fixed or a tracking system. Now, functions accept clearance_height and hub_height and generate the geometry based on that. Don't worry, height is still an option, although it might trigger some warnings to let you know how it is being interpreted as.
new internal Geometry Handling
makeScene and makeModule were re-built from the ground-up for this version. Exciting, I know!!!!! Now, an array gets created so the center of the center module of the center row (or the round-down module if it's an even number of modules/rows) coincides with 0,0, regardless of tilt, azimuth, array size, etc! This allows for simpler visualizations/animations of the visualizations if you want to, but more importantly: it enables easier analysis / sensor location options.
new/improved SENSOR
Speaking of the new sensor/location options:
And, it's more easier than ever to define your own sensor locations / hack the location. check out the carport journal for examples on this!
Multiple Scene Objects for Fixed tilt:
And, if you wanted to do a scene with different types of trackers/racked objects, you can do this too! check out multipleSceneObjs:
new Journals: carport, multipleScenes, and Mismatch.
Have you ever wanted to make a carport on bifacial_radiance and evaluate the rear-irradiance? Have you wanted to add posts to simulate the structure holding your carport up? Have you wondered how to add 'car' surfaces that reflect more light during certain periods of your simulation, or perhaps grass and ground albedos on the same scene? And how to sample the whole structure, not just the center of a specific module/module slope?
Check our new carport journal to learn how to do all of this!
And if you are worried about mismatch, check our development journal on mismatch (and our forthcoming oral presentations/outreach events listed in the Wiki ~).
gendaylit fix with tracker angle
Weatherfiles hour values represent the accumulated irradiance received during the hour before. I.e.: 11 AM, it is the irradiance received between 10 and 11 AM. Therefore, bifacial_radiance follows the standard of calculating the sun position (and tracker position) for 10:30 AM.
However, this is problematic for the sunrise and sunset hours. For example - if there is DNI / DHI vlaues for 7 AM, but the sun rises at 6:40, when the sky was generated for 6:30 the sun position was negative and the program didn't like this. We've fixed this by doing a correction of the sunrise/sunset times, and adjusts the sunposition angle for the midpoint between the hour and that sunrise/sunset time. So for the example of the sunrise at 6:40 AM, the sunposition would be calculated at 6:50 AM. The tracker angles also get calculated for this sunposition. The new changes also handle hours that are before/after the hour of the sunrise/sunset cases (there are some!) avoiding NaN values for the trackers.
Now you should be able to run yearly tracking simulations by hour! (Be warned: this takes us ~4 days on a good computer.)
High Performance Computing:
If you have access to an HPC, several of our functions have HPC capability, and there are working examples in the main.py function as well. Most of the hpc inner-code changes are waiting for files to be created; the runJob() for HPC and HPC example show how to call the bifacial radiance functions and assign them to specific Nodes/Cores. It runs a whole year of hourly tracking simulation in less than a minute on NREL's Eagle HPC!
We do not offer HPC support at the moment, but feel free to try this sections.
still under development but worth mentioning:
analysis and cleanup functions are still being developed, mostly to fit our needs of research. If you have any suggestions, we'd like to hear it on our issues tracker!
Current cleanup functions remove ground, torquetube and side of the modules from results files.
Analysis has some functions to tie with PV Mismatch and calculate electrical loss and shading losses. (There's a journal for this too!).
def some code examples here....