All Activity

@Michele Oliosi Thanks for the response. I'd like to also add some observations about how this factor changes with number of rows. The fewer rows there are, the more "scattered" the factor is for both negative and positive PhiAng. See below some graphs generated in PVsyst 7.4.8. Though these were generated in v7, the scattering is also observing in v8. I'd like to know what's causing the scattering and if this is intentional.

Dear Nikoloz, We recommend using a maximum of 50k polygons for the ground data. Exceeding this number will make PVsyst slower without significantly improving the accuracy of the simulation results. The import ground as CSV provided by PVsyst has an option to simply the geometry to meet with the 50K limit, you can either use this tool or find a way to reduce the number of polygons in your 3DS file. Regards

@nicolasrata indeed I think you have answered correctly here.

Hi @smeredith sorry for the late response, and thanks for reviving this thread. I have made a ticket we will be looking into this possible issue soon.

Why do you divide by two ? I am not sure I am following. No, Imp RMS dispersion are not comparable to a degradation factor. You should first translate into a degradation of the Pmpp. This is done stochastically by PVsyst. The following is really important remark. In PVsyst we consider that the warranty is not equal to the actual degradation ! Therefore what you enter under "Module warranty" has no impact on the simulation. If you want to model the unrealistic scenario in which modules age according to the warranty, then my advice is the following. Simply enter 0.35% per year as average degradation factor, 0% for both RMS dispersions, and put 1% in LID loss (in the tab "Module quality - LID - Mismatch") (almost the same as you did in the screenshot). The lower warranty on the first year is often times due to the LID.

Hello Kadi1, Indeed the simulation will be done for maximum a year, thus the weather data can not contain data for more than a year. The simulation will be done with hourly time steps, so to use the custom file you need to have hourly values. Do you have daily averages? You could possibly create monthly averages based on all the years of data that you avail, and create a synthetic data file based on the monthly averages. This can be done but creating a new site and fill in the Monthly weather data:

Hello, i have similar question In my data i have all avg temperature and GHI from 2022 to 2024 i noticed that i can only import one year my second question is in my data the cell of date only have MM/DD/YYYY i dont have the hours and minutes can i do that conversion without them ?

Nevermind. I figured out the problem.

I'm trying to load a project I recently ran in v.7 into v.8. I follow the usual procedure: Click on "Import project," then select the project's zip file, as exported. A new window comes up that tells me to "Please choose a zip file containing projects." Why would I have a zip file containing projects inside a project zip file? Do I need to zip the zip file? This makes no sense and doesn't conform to the old procedure. Using 8.0.9. Thanks, Laura

I don't think that fully answers the question. Swonno is saying that projects that s/he already worked on in v. 8 don't show up in the list on v. 8. Why should this be? Thanks, Laura

Ok, after doing some trial and error I can answer to myself. Difference between module quality values. The default value in detailled loss is shown at -0.7 but might be round at -0.8 in the results. Need to change it manually to-0.7. Do batch simulation work with multiple inverters ? Yes but you cant make change on the chain or inverter in the params file because it will apply to all the inverters. Is it normal to have variation between batch simulation and manual simulation ? If the parameters are correct there is no variation.

Resurrecting this thread since I've noticed the same thing happening in PVsyst v8. The main difference between v7 and v8 seems to be that circumsolar is separated from the rear sky diffuse in v8, regardless of whether the user chooses the setting that separates it from the diffuse or includes it.

No..... CSV file is not a solution it took an ugly terran. I have converted obj file to 3ds fil , which was 7 MB in size , imported it to 3d shading scene as a groung data but there is another big problem PVsyst is not situable to work with high quality objects (the 3d terran what PVsyst imports by default those maps are too old) and it stucked , frezzed and didnot respond.we are working with huge landskape about 1.4 square kilometers . This is a serious problem when your customers are working on big farms like 150-200 MW and if PVsyst freezes all the time

Hi, I'm planning to do a batch simulation to test a setup in different cities. Before that I did a test with a batch of only 2 variants to check the results against a manual simulation for each of the variant. The 2 variants : Same plane, same orientation, same modules, same parameters One variant with a 100KTL One variant with a 50+40KTL 100KTL 50+40KTL The losses in the batch params are the same as the ones in the detailed loss. Do you have an idea about the following things : Why is there a difference between the module quality for the 100KTL variant ? Do batch simulation work with multiple inverters ? Is it normal to have variation between batch simulation and manual simulation ? Thank you

Dear Andrés, I suggest grouping your PV array based on the electrical layout you have planned with the inverters. It can add complexity to your project, so if you have a varying base slope, it's better to use a single orientation. PVsyst has implemented a new tool to estimate the percentage of losses due to slope variation. Go to the Near Shadings > "Orientation Management", then click on the "Orientation Distribution Analysis" tab. Choose the plot type "Base slope deviation, absolute errors". In my example below, you can see a loss of -0.02% due to averaging the base slope into one orientation: Regards,

Hi, I just figured out what's wrong and it turns out it is a file name issue that is why the .VC file is not under the .PRJ file. Thanks.

Hello, I'm having some problem importing a variant (.VC) file. The variant file and the project file are provided separately. How do I open/import the variant file? It shows that the variant file is not under the .prj file so pvsyst cannot read it as I import it because the import button on the variant only allows to import from other .prj file.

The Average degradation value obtained from the the module warranty interface is 0.38%/ year. Is 0.38% used in the PV module ageing parameters input settings interface？should we change 0.35% to 0.38%？thanks!

OK，we assume that the degradation given to the user is achievable, that is, in the first year, each solar panel power degradation will not exceed 1%, and starting from the second year, the maximum degradation per year will be 0.35%（the minimum degradation is 0%）. According to the upper limit of warranty. "maximum average degradation factor"="1/2 of yearly warranty"="0.175%", right？ So at the end of the first year, the minimum power of the module is still 99% of the initial level, and at least 98.65% at the end of the second year, can the average degradation rate from the second year be equal to 0.35%? The worse possible annual degradation rate we assumed in the warranty is 0.35%. "Average degradation factor"+2*"Imp/Vmp RMS dispersion" ＜ "The worse possible annual degradation rate (the upper limit of warranty is 0.35%) " ； so that "Imp/Vmp RMS dispersion"="0.0875%" ，( 0.35% - 0.175%)/2= 0.0875% Thanks for your time!

Got it, I understand this would be done in the near shadings scene. My question was more about whether the plane-of-array irradiance was correctly estimated, considering that both the tilt and the base slope vary. Would the standard practice in this case be to define multiple orientations? That is, grouping different arrays based on their real tilt and real azimuth? Thanks for the support.

Also, when I tried to switch it from "custom tracker" to "all trackers", it did not correctly save this change when running the model. The report still shows "custom tracker" and the shade losses are still lower than the prior model because that custom tracker is on an edge of the mask.

In version 8.0.9, I found that when I run a model from version 7.4.8 that had a good "custom diffuse" tracker selected, it is now not masked correctly (it is on the edge). Even if I go in in version 8.0.9 and select one that masks properly, after running it, it is on an edge again. See image below. This appears to be a bug with the custom diffuse tracker masking in version 8.0.9. Can this be fixed? It is not practical to always use "all trackers" for large arrays. The problem may occur specifically when the trackers are tilted on the terrain. This problem results in erroneous production jumps close to 1%, because the diffuse shade is only half accounted for. Thanks in advance for the help PVsyst.

The degradation in PVsyst compounds the average degradation rate, and the fact that there is an RMSD in this degradation rate. The worse possible degradation rate is therefore AVG + 2*RMSD. A warranty is in principle below the worst case (because manufacturers need to play safe with these numbers). Therefore, you could estimate an upper limit for the degradation model by saying: WARRANTY > AVG + 2*RMSD (PMPP degradation). Note that given the first year degrading differently, this is not entirely correct. I also note that this warranty seems too good. But in this case, I do not think you should set "Vm RMS dispersion be set to 0.35/2 = 0.175 %".

Dear PVsyst User, If you can reproduce these PVsyst crashes again, please press the <Send bug report> button of PVsyst error dialog and send us the prepared email (including the attached files) so we receive all the information needed to analyse the crash. A description with the list of actions you performed to reproduce it is also very useful. Best regards.

The 2 sigmas is approximately 65.26% of the hits？