All Activity

Hello, 1. In version 8.0.19 we have been improving the orientation grouping function. Which version are you using? What tolerance is set in the project settings? 2. The issue could from the fact that you can define multiple gaps for your tracker in PVcase, motor gap, joint gap, horizontal gap between modules and vertical gap between modules (though normally this would lead to the opposite issue, that more modules are placed in the 3D scene than in the system definition). PVsyst we handle only horizontal gap between modules and vertical gaps between modules, so the PVC file doesn’t contain the other information. The PVC file only contains the total length/width of the trackers and the horizontal/vertical gaps between modules. Did you check the "Terrain following trackers" checkbox in the "Frame creation" tab in PVcase? This setting should break the PVcase trackers into multiple smaller trackers for PVsyst (according to the defined gaps), placing the modules at the correct location. In this case, PVsyst will divide the tracker where the motor gap is. I also notice that 163 tables are not defined by modules, potentially the mismatch comes from these tables. Kind regards

There is a known issue where the total AC power in the report is not accurate with SolarEdge subarrays. This is due to the way the total is computed in the report, based on individual MPPT powers. With SolarEdge and its specific way to attribute (and distribute) strings to inverters, the computation is sometimes incorrect. This issue is on our roadmap, but as it does not impact the simulation results, it has been scheduled for a later version.

Hi, I'm modeling quite a large project where there are 18x SolarEdge SE100KUS inverters, all using C651U optimizers. I've modeled a total of 54 total units (33.33 kW each). The Global system summary accurately calculates 1800 kWac. However, after running the simulation, there is a very large discrepancy where total ac power comes out to 1699 kWac. How can this discrepancy be fixed? Thanks!

Hello, I'm having some issues after updating from PVsyst 7 to 8: 1. Orientation management issues once the scene is imported from PV Case in .pvc format Once I import the .pvc file, in the Orientation management tool I always have 2 orientation groups. Is there a way to avoid this to happen? 2. Mismatch of tables between 3D scene and PV system scene I always have a number of modules different from the number of tables

We also have a comparison of different data sources available here, although we cannot possibly cover all countries: https://www.pvsyst.com/help/meteo-database/import-meteo-data/data-source-comparison.html#comparison-between-several-data-sources-for-different-continents If you need a more precise estimate for the locatiosn of your choice, I advise to get dat from different providers and compare the weather files using our comparison tool https://www.pvsyst.com/help/meteo-database/compare-meteo-data/index.html

Curious why you have included the +1 there. You can simulate a tracking system at [X,X] for min and max to lock the tracker for all hours to a single angle. If you need to more than one angle, this can be done with batch simulation easily.

@Michele Oliosi would you please be able to comment on this? Thanks

Hello, I have a question about annual variability. I have read the information available in the PVsyst help section and have seen that you have a table with the percentage variability according to different locations, their climate, latitude, and global solar radiation index (GHI). I mainly work with simulations for countries such as Honduras, Colombia, and Mexico, among others in this region. Where can I find the variability for these countries? Best regards!

The production is mainly determined by the system capacity (10.32). The "number of sheds" = number of rows is only used for shadings calculations. Increasing the number of rows means that for a larger proportion of rows the row-to-row shadings will be present. This is why the production decreases, because shadings are a bit larger.

It is easier to transform fixed tilt structures to trackers in the 3D scene, using the Transform menu. The other way around can be more of a hassle. The wind stow option is a good option. it necessitates however to import weather data from a file in which you prepare a wind speed time series > some number. Another option is setting the tracker limit angles to e.g. min X and max X+1° if you are okay to fix the tracker to this 1° range. X and X might work too, though I would double check the output with the X, X+1 to make sure it is consistent.

yes this is because of the ratio of width and pitch (GCR) which ultimately controls the tracking algorithm. In your case the GCR is .5. which explains that these two modifications are equivalent (approximately). I would still suggest the remove 1 cm option as better since it mimics most correctly what pvsyst does and is more general to other GCR ratios.

It seems I get the same result whether I add 2cm to the pitch or subtract 1cm from the sensitive width:

I would like to know whether it is possible to use an already existing PVsyst simulation configured with single-axis trackers and simply lock the tracker rotation, keeping the modules fixed at a single tilt angle (for example, by using the stow position). Specifically, is there a way in PVsyst to block the tracker rotation and manually define a fixed tilt angle for the modules while maintaining the original tracker-based geometry and layout? Or, alternatively, if the intention is to simulate the system with a fixed tilt, is it necessary to rebuild the entire model using fixed structures with the desired tilt angle instead of trackers?

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.