smeredith

FYI I think this threshold loss is based on minimum current. Several simulations that I've run show a threshold loss below a certain minimum IArray. What that IArray is, however, remains a mystery. Just frustrating that PVsyst's behavior is unexpected and doesn't follow its own documentation.

I ran a simulation and noticed that there are certain hours where the inverter is flagged as offline and the power loss is assigned to the "IL_Pmin" category, which is supposed to be because array power is below the threshold of the inverter. However in my case, for the hours that are lost due to inverter threshold, the input power is actually 5-6x the inverter threshold. This is sort of a "double whammy", because not only are those lost production hours, but there is also nighttime inverter loss associated with these hours. See the below example, in which an inverter with a 2500 W (2.5 kW) threshold is losing power. For reference, just a single central inverter (2200 kW) is being used for this project. Power units are in kW. Can someone explain why this is happening? The result is a lower yield than I would expect.

This was calculated from the 8760 CSV. Before running the simulation, I changed the circumsolar calculation to be included in the diffuse component in order to get a more accurate calculation of the rear sky diffuse factor, as I understand that it is by default removed from the diffuse component and added to the direct component. Then I calculated the rear sky diffuse factor as DifSBak/DiffHor, and plotted the view factors for both positive and negative PhiAng. The above graph is the result of that.

Does anyone from PVsyst have thoughts on this? Is this a bug or intended behavior?

I noticed something about bifacial simulations for trackers that I think is an error. If you calculate the sky diffuse view factor on the rear side, you'll notice that the view factor is different depending on whether the module has a positive or negative tilt (PhiAng). Below is a graph showing the view factor as a function of tilt for GCR = 0.5. As you can see, the view factor is always higher for negative tilts compared to positive tilts. This behavior seems to be consistent across all GCRs. I was wondering if this was intended behavior or if this is an error - to me, it doesn't make sense that the view factor would be different depending on if the tracker was facing east or west.

Hi, I've been comparing the rear irradiance model published by Marion et al. ("A Practical Irradiance Model for Bifacial PV Modules", 2017) to the PVsyst 2D bifacial model. There are some differences, such the fact that PVsyst doesn't include irradiance reflected from the front of a row to the rear of another row, and the fact that the Marion model considers 1-degree slices of surface (ground, sky, or module row) instead of discrete ground points when calculating view factor and IAM factors. One difference I'm trying to understand is the diffuse IAM correction factor as a function of ground point. Marion prescribes an IAM correction factor curve as a function of one degree surface slice, shown below. When using the values from this curve I obtain a view factor profile that is similar to, but noticeably different from, the profile shown in PVsyst. Below is a PVsyst view factor profile for a system with zero degree tilt, 0.5 GCR, and 1 m height (blue curve), overlaid with one calculated using the Marion correction factors from the curve above (red dashed line). The curves are similar but noticeably different. I was wondering how PVsyst is calculating the IAM correction factors that are used, as they appear to be different from what was derived from Marion et al.

Hi, I am running PVsyst 7.2.10. I'm encountering an error which I'm not sure has been fixed in later versions, but I wanted to make you aware of it regardless. When running a fixed-tilt simulation, on a specific day the profile angle is going to zero at a time when the irradiance is not zero. Perhaps not coincidentally, at this time the sun azimuth is exactly -90 degrees (I have also seen profile angle going to zero when sun azimuth is exactly +90 degrees). This is causing the energy production to be much lower than it should be at this hour. The array is fixed tilt, with a tilt of 25 degrees and an azimuth of 0 degrees (directly South). See the screenshot below:

I understand that your algorithm to determine default values has evolved. But there is a difference between generating PAN files differently from version to version, and actually using the PAN files differently. The problem is if default values are set, then PVsyst uses the PAN file differently depending on PVsyst version. This leads to potentially different module temperature/irradiance losses than what was calculated in the version that the PAN file was generated in. For example, the attached screenshot shows how the same PAN file can yield different temperature and irradiance losses. The example PAN file used in this instance was generated in version 6.87. The project run was a simple fixed tilt project with no shade scene defined. Why is this a problem? Manufacturers and third party labs expect that when they generate a PAN file that the performance of the module will be the same regardless of the version that it's used in. But in PAN files where default values are used, that's not the case. I strongly urge you to consider implementing a method in the next release such that PVsyst uses the same single-diode parameters that are defined in the PAN file, as opposed to re-calculating these parameters if they are defaults.

This post is old, but I think is still relevant. I can give some background to those that are experiencing this error. PVsyst is constantly changing the way that it determines the default values for the single-diode parameters Rseries, Rshunt, and Rshunt at g=0. The implication is that you may get a different default value for a parameter if you open the PAN file in version 6.88 vs. if you open that same PAN file in a later version. This is not a problem if you are opening the PAN file in the same (or a similar) version that it was created in - but I would argue based on the wide variety of versions I've seen used to create PAN files - that this is rarely the case. This is why I argue in a different post that PVsyst needs to either do away with default values for these parameters or else come up with a consistent methodology for determining default values regardless of PVsyst version. Because if you don't, you're going to end up with a different module model for the same PAN file depending on what version you're using.

I'd like to provide feedback about how PVsyst handles default values for the single diode parameters (Rshunt, Rseries, and Rshunt at g=0). From what I've observed, PVsyst might (but does not always) choose different default values for these parameters depending on what version of PVsyst you're using. At first I thought this was just a difference between version 6.88 (the last version of 6) and all versions of 7. But looking at the previous versions of 7 that I have, it seems to vary unpredictably within 7 itself. The following is an example of how different versions are choosing different values. I have a PAN file with the following module characteristics: Isc = 13.76 A Voc = 49.20 V Impp = 12.83 A Vmpp = 41.35 V muIsc = 6.7 mA/C or 0.049 %/C Pmpp temp coeff = -0.390 %/C Rshunt exponential = 5.5 Number of cells in series = 72 This PAN file has certain values for Rshunt, Rseries, and Rshunt at g=0. When I open this PAN file in different versions of PVsyst and enable the "Default" checkbox for Rshunt, I get a variety of changes to Rshunt and other single-diode parameters depending on the PVsyst I'm using. See the attached screenshot for the comparison. I have a couple pieces of feedback. 1. Over the last couple years, too many changes have been made regarding how default values for these parameters are chosen. This is resulting in some modules behaving differently in different versions of PVsyst, if the PAN files were generated using one or more default values for single diode parameters. This is not a problem if the PAN files did not use default values. 2. Even though recent PVsyst help documentation has explained why these values are changing, it is not specific enough to describe how different versions are choosing the default values that they are. In my opinion, PVsyst needs to either stick with a convention for choosing default values or get rid of default values entirely. My preference would be for default values to be eliminated - that way there is at least consistency in module performance between each version of PVsyst.

The default DC ohmic loss for my PVsyst is 2%. If I enter a value that is "close enough" to this default value (in this example, anything from 1.96% to 2.05%), PVsyst will change this value back to 2% and the "Default" checkbox will get enabled. This becomes a problem when other users open the project in their PVsyst, and if they have a different default DC ohmic loss, the value that is shown may end up being quite a bit different than what the original user entered. FYI, I am using PVsyst 7.2.4, but this bug seems to have happened at least in 7.1.x as well.

I'd like to add some information to this topic. I'm a performance engineer responsible for reviewing models produced by other engineers. I recently came across a tracker project that was run in 7.2.3 and had some significant errors with regards to calculating POA and shading. These errors were corrected when the project was re-run in 7.2.4. Some background: -Project located in Maine, USA -The project is single-axis tracker with one module high in portrait. Backtracking is enabled. -The project is modeled with a shade scene consisting of tracker tables and tree-like objects (polygons that resemble trees, but not actual tree objects). The shade scene includes a ground object representing the topography of the site. The tracker tables conform to the topography with an average axis tilt of about -0.8 degrees. -Average row-to-row spacing is about 6.09 m. What happened: -Initially, a simulation was run in 7.2.3 (Variant 1). There was a problem with the string partitioning (specifically each table was partitioned one string wide and one string high, when it should have been two strings wide and 2-3 strings high) that required the model to be run again. -The partitioning was corrected and the simulation was run again in 7.2.3 (Variant 2). When it was re-run I compared the loss diagram from the two simulations and found that the POA and near shading losses were different, despite the fact that only the partitioning changed. As read from the loss diagram, POA gain increased from 24.4% to 26.8% and near shading loss increased from -4.18% to -4.89%. Other downstream losses were affected as well by these two changes. -I opened the raw variant files for both of these variants and found that for Variant 1 only, within the PVObject_Ombrage=pvShading section, the pitch was listed as 6.6 m. Variant 2 showed the correct pitch of 6.09 m, which leads me to believe that Variant 2 is the correct one. -I updated my PVsyst version to 7.2.4 and re-ran the original simulation with the incorrect partitioning (Variant 3). I found that the POA gain was 26.8% and near shading loss was -4.87%, nearly matching Variant 2. So it seems to me there's a problem in 7.2.3 that is causing POA and row-to-row shading to be incorrectly calculated. And string partitioning may have something to do with it?

PVsyst is not importing the last day of an hourly SolarGIS weather file when the timestamps are stored as decimal values. This problem exists in both version 6 and 7 (I was using 6.8.7 and 7.0.17). Below is a detailed description of the problem: A customer provided me a SolarGIS TMY weather file containing hourly data. The columns included the day of the year (1-365), the time of day (in decimal format), GHI, DNI, and other parameters. I imported this file using the hourly SolarGIS format. After importing, I did NOT get a message saying the file had been created or an additional message asking me if I wanted to view the hourly meteo file. Next I went to view the monthly GHI and DHI totals for the meteo file. The table looked normal except for the month of December, which was highlighted and showed "(30 days)" next to the month of December (screenshot attached). I then looked at the daily totals and confirmed that the GHI and DHI were both zero for December 31st. I then opened the source CSV file and confirmed that the dataset was complete, having data for 8760 hours and 365 days. I totaled up the monthly GHI from this file and confirmed that the December GHI from the CSV was higher than the December GHI from the PVsyst meteo. To figure out what was going wrong, I compared the SolarGIS file that wasn't importing correctly to a different one that had previously been imported successfully. I found out that the good SolarGIS file had timestamps that were specified as hours and minutes (e.g., 0:30, 1:30, 2:30, ... , 12:30, 13:30, 14:30, etc.), while the bad SolarGIS file had timestamps as decimals (0.0208, 0.0625, etc.). I changed the decimals to hours and minutes, and was able to import the file successfully. I think this is an issue with PVsyst as opposed to SolarGIS. As far as I'm aware, the customer did not modify the SolarGIS CSV file prior to sending it out. Additionally - if PVsyst wasn't able to import data with decimal timestamps, you would think that it would fail to import any data at all, as opposed to importing all the data except for the last day.

Hi eye4u, No, unfortunately this problem has persisted at least through 7.0.17. I haven't downloaded 7.1.0 yet, so I can't say for sure if the problem has been fixed in that version. For now, I need to use PVsyst 6 to edit any PAN files.

Just wanted to give an update. Today I was opening a manufacturer-provided PAN file in 7.0.16, and I noticed that PVsyst again changed a parameter when I opened it - this time it was Voc (went from 53.5 to 31.2). Additionally, I noticed that when I went to change the number of cells in parallel from 1 to 2 and the cell area from 328.9 to 165, that PVsyst also changed the following parameters: 1. RSerie (went from 0.255 to -2.781) 2. Gamma (went from 1.151 to 4.620) 3. muGamma (went from -0.0004 to 0.0200) I updated my PVsyst version to 7.0.17 and the error still persisted.

Hi, First off, I'm using PVsyst version 7.0.16. I'm trying to modify a PAN file based on a third-party PAN file that I was provided. When I opened the PAN file in PVsyst, I noticed that the RSerie parameter got changed from 350 to 500. As an experiment, I didn't make any edits to the file and immediately closed it in PVsyst. I then opened the PAN file in a text editor and saw that the value was still 350. But then I re-opened the PAN file in PVsyst, made some edits to the PAN file (I didn't change RSerie), then saved the file as a new file. When I opened the PAN file in a text editor, the value had changed to 500. This seems like a bug that's unique to version 7, because I did the same things in version 6 and I had no problems there.