All Activity

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.

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.

I have defined the exact scene and system but it still gives orientation is far larger error. Kindly tell me about this error.

Thank you

Hi PVSyst Support Team, I have the same problem and the bug persists despite trying to save the variant and reopen it. have you found another way to solve the problem please ?

Hello, I advise you to start with the videos "My first Project" Regards,

Hello guys, I am planning to self-learn PVsyst 8 but when I check PVsyst youtube channel’s playlists and PDF tutorial documents, I could not decide where to start and what could be the order of the videos/documents to study. Could you recommend a path for me to follow so that I can start from the scratch and learn all content? Thanks in advance!

I observe that on the left, you have defined an iron loss fraction of 0.06%, which is reasonable (the usual values are around 0.1% of the nominal power). On the right, you have defined 0.77%, which is extremely high.

Sorry, this storage strategy - i.e. storing PV energy for a restitution in the evening - is not yet implemented in PVsyst. This should be done within some few months. I the meantime, if the battery has full priority at the beginning of the day, or charges with a fixed power, we can propose a workaround for at least evaluating the result. You could use the "Self-consumption" option, by defining a consumption corresponding to your foreseen reinjection power from 6pm, for a sufficient duration in order to discharge the whole battery (and null the rest of the day). Then you can consider the energy delivered to the user as the energy to the grid. You can ignore the missing energy.

Dear Sofia, Yes indeed, this is a bug we have in the current version. The bifacial model does not handle 0° tilts anymore. This will be fixed in the next patch 8.0.14. Sorry for the inconvenience..