Michele Oliosi

For most practical purposes, this is already available in the latest 8.0 version. Indeed, PVsystCLI has been made compatible with batch files. In other words, you can call a batch of simulations from PVsystCLI using a batch parameters file. You can find some more details on this page: https://www.pvsyst.com/help-cli/reference/index.html#run-simulation The command that you should look at is --batch-params-file

@Yvano I see. Thanks for the clarification. Indeed, as mentioned by @André Mermoud the only way currently is to use the automatic attribution instead of the manual one to reach these overlapping modules. I will record this issue for future improvements.

Hi please make a new post in English or translate this one (including the title). Following the language rule will allow us to help more efficiently and also help other users 🙂

Hi @James Barry Thank you for the feedback. This comes in very timeline as we are currently assessing models for the decomposition of irradiance from GHI for minute data. We are aware that diffuse fraction models such as Erbs can be biased when applied on sub-hourly scales. Providing an alternative to Erbs is thus a necessity.

The simulation models both the location and the temperature, provided you have parametrized these properly. If the inverter malfunctions, you could also derate the inverter in PVsyst. Moreover, it is important to import the historical weather data corresponding to the monitoring period. Can you confirm whether you are using the corresponding time series for your simulation? If you are using a compatible time series as input for the simulation, it is then worth to compare the measured and simulated time series to understand whether the discrepancy correlates with any factor. Usually comparing the yearly PR and measured PR is not very telling per se. I think you should use the standard PR. However, it depends on how you are calculating the PR for the measured performance data. You should match the definitions of simulated an measured PR.

Summarizing what we found with the data: the diffuse was not the same depending on the time granularity. This is likely a problem that the weather data provider should address. In PVsyst if the diffuse data is different, then the simulation results will be different.

It is not in our most urgent priorities, but it is in our roadmap. Indeed, it would make the reverse transposition when importing POA data more reliable. However, to our knowledge, it does not address the bias inherent to applying the Perez model to sub-hourly data.

Yes this is what I meant ! However, the differences seem to be small, I do not think they would account for the transposition difference. Another possibility that could exacerbate the effect of small GHI differences could be if DHI was not included in the file or not used at import ? Is there a chance you could send the weather data files (MET) or the raw data over to support@pvsyst.com? This would make the analysis a bit simpler.

Glad to help ! I see, however I still fail to see the purpose of this request, sorry. If the inverter clips at a given time, this means that at that time the PV production reaches the clipping threshold at that time. If you model the PV production based on the measured data (not from a TMY), the clipping time should at least roughly correspond to the reality. Same thing with the module temperature, if you were to model using the real historical weather data, the temperature of the modules, measured and simulated, should at least roughly match. Let us know if I missed something about your intentions with the simulation.

Dear JStief, This is puzzling, especially because PVsyst will average data to 1-hour steps anyway, meaning that the modeling should be identical. The first thing that springs to mind is that the 1-min, 5-min, and 60-min files are not simply related by averaging. In other words, if you average the 1-minute data, you won't obtain the 60-min data. Is there a chance to check that ?

Hi, these two factors are directly related to the components in your system as well as the weather. Directly setting a clipping time or a maximum module temperature would be unrealistic, and is not possible in PVsyst. Instead, you can consider changing the components such as changing inverter model or PV module, or also changing the system layout.

Assuming that the statistics of the yield of a PVsyst are only influenced by the climate, as a first approximation, the PR will not change. This is because as a first approximation, the yield is proportional to the average irradiance (from which the climate variability is taken). However, at second order there will be other effects, that are too complicated to track down. Indeed, there is no definite definition of a P90 year useable for a simulation, only the statistical meaning that the yield should be better 90% of the times. I.e. you cannot exactly pinpoint whether this or that combination of entries in the time series has led to the reduction of the yield. However, since the very definition of P90 production also assumes a linear relation between irradiance and yield, it should be okay to consider the PR as constant.

Hi, this is strange. NS axis trackers (whether 3D scene or using the “unlimited trackers” optimization) should work without issue. Can you send your project (use the export button in the project window to generate a zip archive with all necessary files) over to support@pvsyst.com ? Or share a snapshot of the disposition of your 3D scene. This will allow us to look into it further.

Indeed, I confirm that this is the case and is quite misleading… and also not consistent with how PVsyst usually works. You should not be able to keep the spectral correction checked if it cannot be used for some reason. Thanks for this feedback @LauraH

It depends on the layout of the strings in the field. We don't have a rule of thumb, but you could do something along these lines: you can make some simple assumptions concerning your field. For example, if your trackers are 2P (two in portrait), then you could assume that there are two strings per tracker, i.e. 1529 strings total. Then you could also assume that the trackers are roughly arranged in a square terrain, with GCR 0.4. And that modules are 1x2 m^2. Let's say x is the number of trackers on a single line along the axis and y is the number of rows. Roughly, y * 2 (# modules in table height) * 2m (module height) / 0.4 (GCR) = 24 (# modules in table length) * x * 1m (module width), i.e., y = 2.4 x. The total number of trackers is 1529 = y * x = 2.4 * x^2. Solving, that you get roughly x ~ 25 and y ~ 60. So 60 rows should be roughly it. Note that above 10-20 rows, the impact of the number of rows becomes quite small, so for systems of this size the exact values are not important at all.