All Activity

Hey everyone, I need to know the effective energy produced per each set of PV arrays plus the irradiation on various surfaces even without including pv panels. Is it possible?

Hello, Have you found answer for this matter?

Good morning, I would think it is linked to the separator options. Double check the fields format and the decimal separator before exporting the output file and verify the format in your excel settings so that they match.

Good morning, I have created a project in PVSyst version 8.0.14 using the PVGIS meteorological file. My problem arises when I try to export the Hourly File from the project, as the data in the file is not consistent with the Report generated by PVSyst. This seems to be because in the Hourly File, some values appear without decimals (in red) while others include decimals (in green). I don't think it's a separator issue, since, as I mentioned, some values seem to be correct and consistent, but others are not. Is there any way to fix this problem?

2x28 = 4 vertical, 1 horizontal for half-cell module

@VanoV23 Since this is a safety issue, it is important to consider the worst case and not only standard operating conditions or some compromise between. If the default definition of the worst case in PVsyst seem too conservative, they can be overridden as explained in my previous post.

Thank you Sir. Now it's clear. I’ll apply this logic to my system.

Hello Aidenn, I first notice that the power sharing has not been equalized in your print screen. All sub-arrays has the same Pnom/MPPT, though different installed PV power in each sub-array. This results in unequal Pnom ratios across the sub-arrays. You can toggle the "Auto-equal. Pnom option", or clicking on the weight icon for the specific configurations concerned. This will distribute the Pnom/MPPT values proportionally according to the installed PV power in each sub-array, thus equalizing the Pnom ratios. The production begins as soon as the MPP power is over the power threshold Pthresh of the inverter. The MPP power below this threshold is accounted as IL_Pmin loss. The Pthresh power may be understood as the power required for the Inverter internal circuits consumption. These losses might be reduced if activating the power sharing, since certain sub-arrays have rather low Pnom ratios. You can read further about in the following help pages: https://www.pvsyst.com/help/project-design/grid-connected-system-definition/inverter-array-sizing.html#difference-with-the-hourly-simulation https://www.pvsyst.com/help/physical-models-used/grid-inverter/inverter-operating-limits.html

Hi Michele, thank you again, everything is much clearer now. Just to confirm: For the 2×14 structure (a single string across two vertically stacked modules), this matches the 2TU configuration, so I’ll use 2 vertical × 1 horizontal partitions. For the 2×28 structure, with two strings (one per module row), this corresponds to the 2T configuration, so I’ll use 1 vertical × 2 horizontal partitions. That said, would subdividing further (e.g. 4 partitions in height) in the 2T case meaningfully increase accuracy, or is the standard 2‑partition approach sufficient given the partition model’s approximations? Thanks in advance.

OK，thanks very much！

Hi PVSyst team, Can someone explain how do PVSyst determine the clipping loss on these periods? I attached also the setting for the MPPT sharing applied for the system. Please let me know for any other files needed to identify these losses below. Thank you!

Dear Zaki We do not cap negative values in the Perrez model when computing the circumsolar brightness. They arise when implementing the model and we keep them to avoid biasing the result towards positive values. This term is added to the isotropic component and the irradiance itself is never negative. The horizon is not implemented as a band. The horizon component is calculated using the Perez/Ineichen's 1990 model, but it is directly added to the diffuse irradiance. Horizion shadings are applied as a fraction on the diffuse irradiance but not to the horizon irradiance component separately. For the air mass, we use the the Kasten model described in Ineichen's thesis "Mesures d'ensoleillement à Genève", which is corrected for altitude as well (exp(-0.00013*altitude)) https://unige.swisscovery.slsp.ch/discovery/fulldisplay?vid=41SLSP_UGE%3AVU1&search_scope=MyInst_and_CI&tab=41SLSP_UGE_MyInst_CI&docid=alma991006463789705502&lang=fr&context=L&adaptor=Local Search Engine&query=sub%2Cexact%2CKANTON GENF (SCHWEIZ)%2CAND&mode=advanced&offset=0 I hope this helps you in your study

It depends on the layout of the strings in the field. We don't have a rule of thumb, but you could do something along these lines: you can make some simple assumptions concerning your field. For example, if your trackers are 2P (two in portrait), then you could assume that there are two strings per tracker, i.e. 1529 strings total. Then you could also assume that the trackers are roughly arranged in a square terrain, with GCR 0.4. And that modules are 1x2 m^2. Let's say x is the number of trackers on a single line along the axis and y is the number of rows. Roughly, y * 2 (# modules in table height) * 2m (module height) / 0.4 (GCR) = 24 (# modules in table length) * x * 1m (module width), i.e., y = 2.4 x. The total number of trackers is 1529 = y * x = 2.4 * x^2. Solving, that you get roughly x ~ 25 and y ~ 60. So 60 rows should be roughly it. Note that above 10-20 rows, the impact of the number of rows becomes quite small, so for systems of this size the exact values are not important at all.

We have calibrated the number of partitions based on the module layout calculation. Therefore, all these effects are taken into account in the partition model. The partition model per se is an approximation that will not always reflect the details of the electrical effect of partial shadings, but that should recover a plausible loss value for a long term (e.g. a year) simulation. However, for the case of the 2x14 structure, it should not be a partition that traces through the middle of the modules. That would be correct for the case 2T. Instead, this 2x14 structure is in the case 2TU, which has two partitions with size 1x14.

I am currently working with PVsyst version 7.4. Thank you for your response. In my case, I only have the total number of strings and the number of modules in series per string. Could you please guide me on how to calculate or estimate the appropriate number of sheds from this information? Is there a rule of thumb or a formula to follow based on the electrical layout (e.g. 24 modules per string, 3058 strings in total)? I would like to make sure that the "Number of sheds" I enter corresponds realistically to the physical arrangement of the system in the field. Best regards, Laila Raouane

Thank you Michele. To make sure I fully understand the implications for my specific case: Since the modules are connected in series (one string per 2x14 structure), shading on the bottom module would affect the performance of the top module as well, even though the top one remains unshaded. If I simply divide top and bottom modules each into two partitions (totaling 4 vertical submodule partitions per string), I am concerned this may miss the fact that shading on the bottom module electrically impacts the top module through the series string connection. How would you recommend managing this configuration? Thanks again.

Hi ! Which version are you using? I am asking this because in the current version this is not stated, as far as I know. The unlimited orientations do always include mutual shadings. The shadings calculation is inherent and is not related to choices in the "Near shadings" window. The number of rows (with the frenchism "sheds") is actually quite important for the evaluation of mutual shadings: it does affect simulation results.

Hi ! Yes, in general it is necessary to define partitions whenever you want to perform electrical shading calculations using the option "according to module strings". However, if you use the mode "Module layout" then the partitioning is not necessay as the submodule and structure is defined in the PAN file. No, in general the partitioning is not = to 1 string, sometimes you should count several partitions per string. For example, the half-cell parallel structure usually means doubling the number of partitions. You can find various examples here: https://www.pvsyst.com/help/project-design/shadings/electrical-shadings-module-strings/partition-in-strings-of-modules.html. Your cases are the 2TU and 2T respectively.

Dear PVsyst team, In the Orientation → Unlimited sheds section, it's mentioned that the "Number of sheds" is only for visualization and does not affect simulation results. However, I noticed that changing this number (e.g. from 5 to 12) slightly alters the energy yield and PR, even when mutual shading is disabled and all other parameters (pitch, tilt, GCR, etc.) stay the same. Could you please clarify: How should we choose or calculate the number of sheds? Why does it impact the results if it's only for display? Could internal parameters (like edge effects or area estimation) be influenced? Thanks in advance for your help. Best regards, Raouane Laila

Dear PVsyst Team, I’m reaching out to ask for your support regarding a 3D scene I’m simulating using trackers in a 2-portrait configuration. In this model, I’m defining the partition on two types of trackers: One with 2×14 modules, corresponding to a single string. Another with 2×28 modules, corresponding to two strings (one on the top row and one on the bottom row of the structure). I have two main questions: In general, is it necessary to define the partition if the module is already specified as a twin half-cell with 3 submodules in the PAN file? If so, how should the partition be configured? In my specific case, where there is only one string per structure, the partition would logically be 1×1. However, if a partition is still required due to the module’s half-cell architecture (as per question 1), how should I define it in this scenario? Thanks.

Hello ! This is normal. Since there is very little irradiance as a total on the PV cells, the efficiency derate is on the low end of the curve that Luca showed. You also must take into account that the loss diagram is an average over many irradiance conditions (probably ranging between 0 and 200 W/m^2). Once you put everything together, the average loss of efficiency may well be 11% (below what you would get by just examining the loss of efficiency at (21 + 0.75*168.1) W/m^2.

Dear sir： Can you take a look at this problem? Why is the backside mismatch loss calculated separately from the front side, rather than being added to the front side like irradiation. thanks！

When I completely shade the front side of the module and allowed the back side to receive light, I found that the loss due to weak light was relatively high.

this is also happening. all after update .14

Hi all, my colleagues and i are having errors when printing reports in the newest update. .14. the reports are either blank or the loss diagram is jumbled.