3.1 Model Development
3.1.5 Direct and diffuse components
Gathering the radiation data only in the form of global horizontal irradiation might lead to mistakes when the solar angle is very small because there might be some diffuse radiation during the sunrise time but, since the data resolution is one hour only, it might occur that the software registered a radiation larger than zero but the solar angle is negative, and according to the method before, a negative solar angle gives a TE equal to zero, which would result in a zero harvest. Moreover, the method presented above neglects the fact that the azimuth angle of the surface may vary and does not consider the incidence angle between the sun rays and the surface. An alternative method discussed in the literature review will be applied to the model following the solar radiation and angles theory in . The meteorological information was gathered from PVGIS . Unlike Soda, PVGIS allows to download a typical meteorological year data set that can discriminate the radiation into its direct and diffuse components. A typical meteorological year data set consists in choosing for each month of the year the most typical month over a 10 years period, offering a more reliable climate insight on a certain location, avoiding the bias of choosing a year that was more or less sunny than the average . From PVGIS,
that will substitute GHI*TE in the PV harvest equation. In this way, the radiation components can be analysed separately from the beginning and the contribution from the diffuse radiation is independent from the solar angle but depends only on the tilt angle of the surface.
220.127.116.11 Comparison between the methods
The solar radiation data gathering method utilized by Ericsson, based on the software Soda and the method described in , based on the software PVGIS were compared in this chapter, to verify if splitting the global radiation into its component and including the angular relation between the surface and the position of the sun in the sky would lead to better results. In order to do so, seven different locations around the northern hemisphere were taken under examination. These were:
Maracaibo, Venezuela, 10,7 latitude north.
New Delhi, India, 28,6 latitude north.
Los Angeles CA, USA, 34,1 latitude north.
Milan, Italy, 45,46 latitude north.
Frankfurt, Germany, 50,12 latitude north.
Copenhagen, Denmark, 55,69 latitude north.
Stockholm, Sweden, 59,34 latitude north.
For each location, the radiation data were first extracted from Soda and then from PVGIS, for the same year (2015). Then, the data were applied to the two different methods in two separate Excel files, both considering the same type of energy system, in terms of load, type and number of PV panels and batteries. The system was made of 36 monocrystalline 455 Wp panels, 5 Li-ion batteries with a total storage capacity of 48 kWh and no wind turbines, pure solar mode was chosen, for a 1.8 kW constant load. For Maracaibo and New Delhi, the two locations at the lowest latitudes, a PV array of just half the number of the panels was chosen, because the 36 array was too large and already covered 100% of the yearly load, making impossible to understand if any improvements would be gained, when using a different method. Then, two main results were registered for each case. One was the total annual PV production, including also the excess PV power, so to have a more valid picture on how much was gained or lost, simply in terms of photovoltaic performance. The other was the hours of backup needed in a year.
The latter is more interesting because it gives an insight on how much the performance of the system as a whole varies, since it represents the level of self-sufficiency reached by the combination of solar PV and batteries. In fact, instead of just the amount of hours of backup needed, it is the difference between the total number of hours in a year and the hours of backup needed that was taken in examination. Next, the total yearly incoming radiation registered by the two software for the same year was calculated and the two main outputs were weighted accordingly. The results were divided by the total incoming radiation, producing a parameter that describes how effectively the input is translated in output, no matter what value the input is, it can be considered as the method’s conversion efficiency. This way, the performance of the two methods could be compared in a more reliable way.
The results are shown in Table 5 and illustrated in Figure 30.
Table 5 - Results in terms of yearly production and self-sufficiency for seven different locations in 2015, using SODA and PVGIS
The plotted results show the weighted yearly PV production and self-sufficiency of the system in seven different cities, obtained both from the methods based on SODA and on PVGIS. For Maracaibo and New Delhi only, an array of 18 panels was chosen, instead of 36, therefore, the results are much lower than the rest. The most significant finding is that the results obtained with the method based on PVGIS are better for any locations.
34 Figure 30 - PLotted results of the comparison between SODA and PVGIS. The weighted PV production and self-sufficiency
obtained with SODA are shown in blue and red. In grey and yellow, the same parameters obtained with PVGIS.
In particular, large gains are recorded for the self-sufficiency. Table 6 compares the weighted self-sufficiency parameters and shows their improvement in percentage in the column “improvement(%)”. For instance, in Stockholm, latitude 60 in the graph, the method’s conversion efficiency grows from 47.6 to 54.9, with an improvement of 15.5% in the self-sufficiency weighted parameter.
Table 6 - Comparison of the weighted self-sufficiency parameter and improvement in percentage Self-sufficiency
Latitude SODA PVGIS improvement (%)
To quantify more easily the improvements in the total production, the conversion efficiency parameters for the production were corrected even further by multiplying the total incoming radiation for the PV area. Each panel is 2,1 𝑚 and 36 panels have a total area of 75,7 𝑚 . In this way, we found the ratio between the total incoming radiation on the whole PV area and the total production of the whole PV system, similar to the standard efficiency of a module. The results are shown in Table 7, only the cities above the 30th parallel were examined, since those are the cases were the panels were 36. An average improvement of 1,7% is registered.
Yearly PV production and self-sufficiency weighted on the total radiation registered for Soda and PVGIS
Table 7 - Conversion efficiency from the yearly incoming radiation on the total PV area to the total yearly production for the two methods and their comparison.
Yearly efficiency (%)
Latitude SODA PVGIS improvement
34 20,1 22,5 2,4
A challenging aspect of the model development is that the Excel file reached an important size of around 10 Megabytes and the computation time is slow, making it difficult and tedious to add new parts or to change inputs and checking how the results change, for instance to perform analysis and make comparison between different equations or methods. The reason for this lack of quick response lies in the fact that a solar model is designed on a hourly bases throughout a year, therefore, for every parameter needed in the calculations, there are more than eight thousands number to be calculated. This would not be a problem for a computer program but in the case of Excel, these numbers are printed in one cell each. Printing a number in a huge amount of cell is what takes the most memory space in an Excel file.
To make the model smarter and easier to handle, a Python version of it has been built during the thesis work.
After extracting the meteorological data from a csv file downloaded from SODA, the code creates an array made of 8760 components (one for every hour of the year) for each of the parameter needed, computes all the calculations and assign the values to the arrays. The code saves these values and does not have to print all of them, but if needed, a simple line command can print any component of any array or plot a graph. The results obtained on Python were compared to the ones in Excel, when inserting the same input data, to validate the code itself.
There are several benefits of having a Python version. Firstly, the file size is incredibly smaller, the current version is only 18 kilobytes, making it easier to send and store in the memory. Secondly, the computation time is much shorter and the file is very easy to handle, allowing the code developer to add parts and modify it quickly. Thirdly, in the future, it would be much easier to perform optimization by repeating the computation of the entire model varying the value of one input each time, for example to find the best tilt angle or the best combination of number of panels and batteries and to compare different set-ups for future analyses.
Another aspect of the model that was making it not very user-friendly is the fact anyone who wants to use the model for a site of his interest, has to firstly open the software for the meteorological data, download a .csv file from there, import the .csv into another Excel sheet, copy the data and paste them into the file of the Model and see the results. A way to make this process quicker was studied and an API was the right answer.
API stands for “Application Programming Interface” and it is a software intermediary that allows two applications to communicate with each other. With an API, the database of a software can be accessed directly from a python script, via internet. The major contribution of the API is that it allows the program to automatically access the meteorological data by just reading the latitude and longitude inputs.
In order to do so, a research online was made . Firstly, the python libraries “json” and “requests” had to be downloaded and implemented on Jupiter. Then, a URL given by the software has to be found in its website. On this regard, the software SODA still does not offer an automatic access through API for Python nor for Excel, whereas PVGIS gives the possibility to utilize this service for Python free of charge. Next, through few lines of code, the script automatically access the radiation data, in TMY format, from the server with only the information of latitude and longitude, which will be the only input that the user will have to give, together with the other characteristics of the Power System. A visual explanation of how the process works is summed up in Figure 31