All Activity

Hi, I am getting the following error while trying to get PVGIS TMY data from the weather data import: Anyone with the same problem? Thanks.

To compare with baseline pvlib, I would rather remove 2 cm to the "Sensitive width". Might be 1 cm, I am not 100% sure if 2 is double counting.

Indeed this is a limitation we still have. The electrical shadings in general in PVsyst are further explained in the following video:

Hi Michele, thanks this helps! To confirm, how would I best account for this added width? By increasing the backtracking pitch like below by 2cm?

Hello, At the moment, small shades at the center of pv modules are not treated and do not create electrical shadings. This is something we hope to improve in a future version. Kind regards.

There is indeed a baked-in 1 cm addition to the effective width of the tracker (both sides) when using backtracking in PVsyst. This is meant to account for possible inaccuracies in placement. When this was implemented, it was expected that such precautions (leaving a margin of error) are applied in the field. Probably it is still the case?

Dear sir： Recently, when simulating cell-level shading of PVsyst 8.0.19, I placed the shading object about 1-2 cm away from the PV module surface to simulate the bird droppings shading. Simulation results showed that the percentage of electrical shading loss was almost zero, Yet the 3D modeling confirmed that shadows were cast on the module surface. What might be the cause of this? Thanks！

Dear Jun Lei, The SIT data included in PVsyst is provided by Meteonorm. You can use the interactive map to select a location anywhere on the planet, import the meteorological data, and save it. This will allow you to run a simulation at your chosen location. Regards,

Hello, I'm comparing the tracking angles from a simple PVSyst simulation with the tracking angles given by pvlib.tracking.singleaxis(), and I expect a very similar result between them. I do get a near-perfect match during the middle of the day, however I see the angles deviate significantly during backtracking times. The angles match only when I slightly modify the GCR in the pvlib function (from 50% to 50.25%), which suggests to me that the backtracking GCR in PVSyst may not be what I set myself (50%). Am I setting up the PVSyst simulation properly to compare with the pvlib function? I understand that there are "hidden parameters", but I haven't found one that changes the backtracking angles. My PVSyst setup is as follows: - 5 single-axis trackers defined on flat ground, 150 modules total, 1P orientation - module length: 2000mm, module width: 1000mm - unlimited trackers, pitch: 4m, GCR: 50% My pvlib inputs are: pvlib_tracking = tracking.singleaxis( apparent_zenith=90 - df["HSol"], apparent_azimuth=df["AzSol"] + 180, axis_tilt=0, axis_azimuth=180, cross_axis_tilt=0, max_angle=60, backtrack=True, gcr=0.5, ) I compare pvlib's "tracker_theta" output with PVSyst's "PhiAng" output. The plot below shows the yearly differences (up to 5-6 degrees during backtracking times): When I change the pvlib GCR to 0.5025 (corresponds to a ~0.02m difference in the pitch), the discrepancy goes away: To better match the pvlib function at GCR=50% I tried setting PVSyst hidden parameters such as "Shed field default frame margin" to zero, but I didn't see a change in the resulting angles.

Why is there no information about North Korean regions in the site files?

This is not a precise science and can be site dependent. In order of magnitude, one could consider that a site within 10km distance can use the same .MET and .SIT without issues.

If I were to do multiple simulations of different facilities, but they are in the same area, meaning they are on the same block, and I will import a weather data from meteonorm, can I just use the same .MET and .SIT file for all of them?

Yes, I used trackers, with backtracking (same as the actual system):

One of your answer above I read that, you say I will write no of sheds relate to no of rows mean if I install 4 panels in a row and have 4 rows then no of sheds will be 4, but one thing confusing that I'm installing a 10.32KW system for installation with 645W panel capacity, but there is no limitation of no of sheds mean when I increase no of sheds my end from 16 to 60 then also pvsyst simulate and give less production result.

i don't understand the logic, one thing I'm understand is that I make a mind that 16 panels 16 rows that's why I use 16 no of sheds but at the end this thing confused me that why by increasing the no of sheds from 16 simulation run it should be stop by the software bcz in system design we only use 16 panels bcz it affects on production, plz understand me the logic of no of sheds plz

In the detailed losses window, you can set 1% for the first year degradation as a LID loss in the "Module quality - LID - Mismatch" tab and 0.44% as an average degradation factor in the Ageing tab.

How can I account for the degradation losses in PVsyst 7? What I want to input are the following: 1st year degradation: 1% Succeeding years' degradation: 0.44% loss per year

Hello, For a current project we are exploring using the module temperature from the pvsyst for contractual purposes. I tested the advanced simulations with all of the module temperature related features turned on. the TExtON or average ambient temperature during running produces an answer of 0,0 every time meaning that the other temperature items that check the module temp compared to ambient temp also do not work. This is all seen in the latest version of pvsyst, with both linear and detailed electrical projects and when using multiple different sources for the TMY file.

Hello Carlos, PVsyst simulations are limited to a maximum period of one year. Accordingly, the associated weather data file is also limited to one year, and any data beyond 365 days in a custom-imported file are ignored. If your dataset covers more than one year, you will need to run separate simulations, each using its own corresponding weather data file. Additionally, since your measurements contain missing data, I would recommend isolating the reliable and consistent measurement periods into separate files using a text editor. These cleaned files can then be reimported using the Import and Generate Custom File tool. Best regards, Eric

Hello. To better assist you, please send your project to support@pvsyst.com (File / Export projects) and be specific about the name of the orientation with wrong values. Regards

After the latest PVsyst update, I can no longer find the auto-detect orientations tool. When defining orientations from the selection, the software creates nominal values that differ from the average values of the selected objects, and these nominal values cannot be edited. I would like to understand: Why the nominal values differ from the average values of the objects, How to correct or align them, And how this difference affects the energy yield and overall model results. Any guidance would be appreciated.

Hi, LID is a degradation pathway, which you can see as a definitive change in the module performance. It occurs in the first hours of exposure to sunlight, but then the effect remains. Degradation is modeled as a fixed ratio for the whole year, but in reality this loss should increase throughout the year. This is why we choose the mid-year mark as representative for the yearly degradation loss factor. Hence the 50% applied on the first year. Module array mismatch loss is different from degradation, you find its value in "Detailed losses > Module quality, LID, mismatch"

What are the testing conditions for Arev? thanks!

thanks！