All Activity

Continuation... Actual Condition (COM Losses: string voltage limited by the smallest) Module 705 Wp 710 Wp 715 Wp Module Config. A B C Total Imp (A) 17.55 17.59 17.63 Vmp (V) 40.2 40.2 40.2 Electrical Configuration P (Wp) 705 706.6 708.2 String/Inv 8 36 37 81 Mod/STR 30 30 30 Arrangement Vmp String (V) 1205.1 1205.1 1205.1 Imp config (A) 140.4 633.2 652.3 P config. (kWp) 169.2 763.1 786.1 1718.5 In the first table (ideal condition), the total power is 1729.7kWp. In the second table, the total power is 1718.5kWp. The difference between these two power outputs is 0.65%. I'm considering applying this loss to the mismatch simulation. Is this analysis correct? I tested a second methodology: using the Detailed Study tool in the Mismatch Losses tab in PVsyst. In this analysis, the Voltage Difference between the 715Wp and 705Wp strings is 11.5V (1216.7V – 1205.1V (Table 1). Applying a voltage difference to the string of 11.5V, PVsyst returns a mismatch of only 0.05% (Figure below). Why is the loss calculated by PVsyst so low? What is the best way to model this project and a loss to be applied due to the power difference of the modules?

I'm working on a project with 3 different modules (705, 710 and 715 Wp) connected to a single MPPT inverter: Ideal Condition (No Losses) Module 705 Wp 710 Wp 715 Wp Config. A B C Total Module Imp (A) 17.55 17.59 17.63 Vmp (V) 40.2 40.4 40.6 P (Wp) 705 710 715 Electrical Configuration String/Inv 8 36 37 81 Mod/STR 30 30 30 Arrangement Vmp String (V) 1205.1 1210.9 1216.7 Imp String (A) 140.4 633.2 652.3 P config. (kWp) 169.2 766.8 793.7 1729.7 An alternative modeling approach is to change the .OND to 3 MPPTs and use the MULTI-MPPT tool. This will allow me to model all three module types in the same inverter. Will making this change to .OND cause other problems? I did the simulations below to test: Simulation 1: 3 inverters with original .OND (1 MPPT per inverter). Each inverter is configured with a different module, totaling 5,176 kWp. E_grid = 11261 MWh Simulation 2: 3 inverters with modified .OND (3 MPPTs per inverter), only to allow modeling in PVsyst. Each inverter is configured with 27 strings of the three types of modules, totaling 5,176 kWp. The PVsyst MULTI-MPPT tool is used to group the 3 MPPTs on the same inverter. E_grid = 11261 MWh The energy result (E_Grid) is the same in both cases. I understand that PVsyst doesn't consider any differences between the models. Therefore, we must calculate a loss due to this electrical configuration. I understand that this electrical configuration will result in a greater mismatch. One way I found to calculate the electrical losses of this configuration is to consider that "the array voltage is always limited by the lowest voltage string." In this case, the voltage of the 710Wp and 715Wp strings will be equal to the voltage of the 705Wp string. I calculated the power of each configuration (P config. (Wp) = Vmp String (V) X Imp config (A)):

Thank you for your response!

I'll post the answer here for other users as well: this is not a bug, horizon profiles below 2° are not considered in PVsyst: https://www.pvsyst.com/help/project-design/shadings/far-shadings-horizon/index.html

Dear Auriane, I'm using 8.0.13. I will send an email with the information.

Hi @Cole Noble, If you import hourly GHI data into PVsyst meteonorm or DirInt are not used for DHI. Instead, the Erbs model is used. However, the meteonorm generation is likely used for the ambient temperature if it is not present in your data?

Good Morning PVsyst Support Team and PVsyst Community, I would like to know if there is a possibility from the software to define in the export output file a specific sub-system (or all of them separately) instead of results combined for the global project. The objective would be to check the behaviour of each configuration define for a project within the software to evaluate specifically the overload losses over the inverters for example. Thank you in advance for your answer. Best regards David

Hi @tommm, no indeed, as you have understood, there is no way to organize per inverters in this interface. However, the solution you hinted at should work. I.e., you can define different inverters and open the window “Multi-orientation daily sharing” from sub-arrays with the three different inverters respectively. Make sure everything is checked.

I am importing GHI into PVsyst and need to rely on the decomposition model for DHI. From what I understand, PVsyst uses the DIRINT model (Perez-based) for decomposition and then uses a Meteonorm algorithm for creating the synthetic (hourly) data. This would explain why "Diffuse Perez, Meteonorm" shows up on my reports (even if I am not using any Meteonorm-related irradiation). 1. Is my understanding correct? 2. If my understanding is correct, if I am importing hourly GHI data, why would the Meteonorm synthetic model still be used? The GHI data is at an hourly granularity already; why not just use DIRINT? Perhaps PVsyst uses the label "Perez, Meteonorm" for DIRINT? Even if no synthetic hourly data is created? 3. I don't see a way of changing the decomposition model in PVsyst to Erbs instead of DIRINT. Is this not possible? Thanks! Cole

The SolarEdge SE50KUS uses SolarEdge so-called "synergy technology". It basically makes the inverter behaves as 3 separate inverters. In PVsyst this feature has been modeled by having this inverter set as a 1/3 of the total system. It means that you should always have a multiple of 3 for the total number of SE50KUS inverters if you want to use the whole real system.

Hi, I have a question about the Multi-orientation daily-sharing tool. I’m working with three identical inverters, each with 12 MPPT inputs, and 4 different orientations (one for each direction). I’ve already built all my sub-arrays with the correct number of MPPTs, and the Power Sharing window works fine. Since my inverters are heavily oversized (400 kWp for 250 kVA), I assume that power sharing is a crucial aspect of this design. The Multi-orientation daily-sharing window seems to be exactly what I need, as it allows the inverter to dynamically share power between MPPTs with very different orientations. However, I’ve encountered a problem: in this window, all MPPTs appear to be grouped under a single large inverter, and there doesn't seem to be a way to group MPPTs by inverter, like in the Power Sharing window. Is my understanding correct? Is there really no way to organize MPPTs by individual inverter in this interface? I also tried duplicating the .OND file to create another inverter type, hoping it would help. But now, in the daily sharing window, I only see the MPPTs corresponding to the inverter selected in the system definition (not all MPPTs from the project). Thanks for your help! Best regards,

I think you missed my previous answer, three days ago. I wrote : "this storage strategy - i.e. storing PV energy for a restitution in the evening - is not yet implemented in PVsyst." Is it not sufficiently clear ?

The Solar Edge SE50KUS inverter Three Phase Inverter with Synergy Technology has the output power rating of 50kW, however, in PVsyst its output power rating is indicated as 16.7kW... Could you please look into this?

is it possible in PVsyst now? if yes, how?

I think you missed my question. How do i specify in my PVSYST model that the battery is capable of being charged by both the PV and via AC electricity from the grid?

Dear Haseeb, Can you please send your project to support@pvsyst.com so that we can analyze the issue? Please follow this process to export your project as a ZIP file: Regards,

Yes, in this case, this is the ratio of the annual values. In fact, the P50/P90 statistical evaluation only make sense when you compare yearly results. These notions don't apply to hourly or daily values, and hardly on monthly values. For example for evaluating the P90 of the results of, say, January, you should avail of a list of January values from many years, and calculate the standard deviation of this sample. This will obviously be far larger than the yearly variability. This doesn't make sense. Now applying the P90 factor to each hour of a climatic data file is not correct. This would mean that each hour of a clear day would be diminished by this factor, which is obviously not the case. The P90 factor will induce a difference in the distribution of the bad and good days, not the absolute values of irradiances. The only way to get P90 hourly values is to use a TMY weather datafile specifically constructed in this way. I.e. choose periods for the TMY construction which result in a P90 predefined yearly sum. This file may be completely different than the original P50 weather file.

Dear Rob, I cannot reproduce your error in version 8.13 (current latest version). Could you please send an email to support@pvsyst.com with the concerned project so I can investigate this issue? And could you confirm which version you are using?

@dtarinDoes P90 factor mean Annual generation P90 / Annual generation P50 ?

Your questions: Why is the “Produced Energy” (and PR) so much lower in the no injection scenario when the PV array performance and load supply remain the same? You have a system of 3.4 MWp, this probably produces more than 17 MWh during a clear day. Now during this day the internal consumption is 4.8 MWh and the possible storage is 3 MWh, therefore 7.8 MWh. If you don't reinject into the grid, you will have more than 9 MWh lost ! Is PVsyst not counting excess PV generation as “Produced Energy” when it is curtailed (i.e., when the battery is full and there's no injection allowed)? In this case the energy is indeed not used (it is even not produced), it is quite logical that it is named "Unused energy" Is there a better way to represent "total generation potential" in a self-consumption system without grid injection, so that I can compare energy yield more realistically? Why a better way? The "Total generation potential" is indeed the sum of the used energy and the unused energy, this seems quite clear for the user.

With the latest versions of PVSYST, I noticed that when adding a Horizon profile (for instance, using PVGIS), saving the variant, change variant and go again to the inicial variant, the horizon profile is gone and it is required to add it again. I think this was not the case in previous versions and this may cause mistakes, since now you have to remember to always check the horizon when doing a simulation.

Dear Mikhail, The aging tool is a general tool to represent several situations. Unfortunately, the literature is a bit scarce on aging (real aging tests need years of field testing and there are a variations among technologies and climates - new technologies still need to be monitored more extensively) and on our side we don't have at the moment a clear literature review on the topic to hand out on to give clear recommendation on our side. However, here are a few additional clarifications: First recommendation: if provided, input the aver. degradation factor from the data sheet of your module (/!\ this is not equivalent to the warranty!). Know that average degradation factor lies between 0.2-0.6%/year. So you can adapt it if you want to see a more or less optimistic/conservator impact. The Imp / Vmp contribution is set by default to 80/20 %, to represent the fact that often the first impact on the long term are first of optical nature (=decrease the current), for example due to encapsulant yellowing. But this is to adapt with what you find in the literature about your technology or what you observe in the field. The Imp and Vmp RMS dispersion are tuning parameters of the model. If you set them at 0, all the PV modules will have the exact same degradation rate and your system will follow the blue curve. Set to higher values, the PV modules will have mismatch among them and an additional loss occurs because of this (mainly driven by the PV module whose current degrades the fastest). There is not really literature to advise what parameters to input here, but you can use this parameters to visualize the extra impact of this mismatch or tune it to make it correspond to existing measurements of a PV system.

Hello, I’ve run two PVsyst simulations for the same rooftop PV system on a warehouse in Malaysia. Both simulations have identical parameters: System size: 3423 kWp (6339 × JinkoSolar JKM-540M-72HL4-TV) Inverters: 12 × Sungrow SG250-HX (total 3000 kWac, Pnom ratio: 1.141) BESS: 2 × Huawei Luna2000 (2936.4 kWh usable capacity) Orientation: 6 fixed tilts (e.g., 13°/-20°, 13°/160°, etc.) User load: Fixed profile, ~4800 kWh/day (1,752,000 kWh/year) Self-consumption strategy with battery charging from PV surplus and discharging to support load The only difference between the two runs is: Case 1: Grid injection allowed (Grid reinjection: Yes) Case 2: Grid injection not allowed (Grid reinjection: No) However, the annual "Produced Energy" output differs dramatically: Case 1 (Inject): ~4.97 GWh/year, PR = 82.27% Case 2 (No Inject): ~1.74 GWh/year, PR = 28.81% Other metrics like EArray, E_InvOut, and load-supplied energy (E_Solar = 1.74 GWh, SF = 99.26%) are identical in both cases. My questions: Why is the “Produced Energy” (and PR) so much lower in the no injection scenario when the PV array performance and load supply remain the same? Is PVsyst not counting excess PV generation as “Produced Energy” when it is curtailed (i.e., when the battery is full and there's no injection allowed)? Is there a better way to represent "total generation potential" in a self-consumption system without grid injection, so that I can compare energy yield more realistically? I want to ensure I'm interpreting these results correctly, especially for techno-economic reporting under self-consumption-only policies (e.g., Malaysia’s SELCO guideline). Thank you!

Sorry there is no workaround. This will be corrected in the version 8.0.14, to be released mid-July. In the meantime, you should reinstall the previous version 8.0.12. You can install it in parallel with this version 8.0.13, both versions may coexist without problem.