dtarin

Hello, Similar to the Aging tool where we can save each year as a new variant, it would be great if we could do the same for batch runs.

It may have run, but did you check that the results in the waterfall reflect a change in pitch? It's been my understanding one needs to use an array of trackers for this to work.

This should be under "how to" or another forum category fyi. If you are using a shade scene which has individual trackers (like from a PVC import), you cannot vary pitch in batch mode. Varying pitch in batch simulations only works on regular arrays (in shade scene, go to create > array of trackers) or using unlimited sheds. If you have multiple arrays of trackers, you will likely need them all at the same X coordinate as well or with enough spacing that they wont run into each other. If you're running GCR analysis, these two methods should be sufficient. When using the array of trackers, specifying the tables in backtracking management is not needed.

Export the 8760 and create a custom weather file then reimport.

rotate 180 degrees

Another place to check is under advanced parameters setting the default value. But looking at it from another perspective, rounding in either direction is a difference of < 0.05% at the meter, and a second decimal might imply some level of precision that may or may not be there.

Have you defined LID only under detailed losses? If you define LID in the PAN file, it should stick; used 7.2.21 to test. Select "take value from module spec" in detailed losses.

I have imported data and added a timeshift definition in the weather file. It shows graphically under the meteo file, but it says that the data is shifted by 0, even though it is defined and showing. Is this an issue with the software? Running 7.2.21

This looks like it is showing an "effective" azimuth. You see there it shows nominal at -100.3, but due to the terrain for the site, PVsyst is calculating something different. This is typical. When you have certain topography, you will not have the same azimuth/tilt as the nominal.

When running simulations with fast enabled under shading, PVsyst uses the shading table to calculate shading losses. When selecting slow simulation, if I understand correctly, it is calculating shading losses hourly from the shade scene. If the latter is correct, when first initiating a simulation with slow method enabled, can PVsyst skip generating the shading table if it is not used? This would reduce the time for the simulation. Users can always go back and generate a table later if they want.

Example: 700kWdc, 650kW inverter nameplate @ Pnom, 600kW grid limit Pnom ratio = DC capacity/Inverter Pnom: 700/650 Grid limit Pnom ratio = DC capacity/Grid limit: 700/600 Generally, the grid limit is less than the inverter nameplate, so the DC/AC ratio is higher here. In the PVsyst report, the Grid lim. Pnom ratio is found under System Summary, and the Pnom ratio is found under PV Array Characteristics.

That is correct.

Irradiance is not considered when calculating string lengths - Module Voc_max = Voc x [1 + (Tmin - T_STC) x (Tk_Voc/100)]. Temperature has a small impact on current, but it is mostly voltage that is affected. One note to make here, a TMY file is an average of expected conditions and may not be suitable to define a "worst condition" scenario. Time series data over a historical period would be more informative.

Typically by users. It is a custom field, so use it as you need to. Whether or not there is a specific label in the software does not matter. The software takes all uncertainties entered and combines them (square root of sum of squares). The label you give it shows up in the report.

This is typically added under the custom field and renamed. All fields should be set by the user, and not dictated by the software as it is site and project specific.

The justification is that when performing calculations, as you have found, a negative number can lead to negative generation. While PVs plants do have negative generation at night (i.e. transformers, fans, etc.), it is not coming from irradiance or the modules. The last part was with reference to the forum topics and organization. This is a general question and would be better suited for the how to or meteo data forum categories.

Irradiance sensors sometimes (or often) report negative values. Set these to zero to resolve your issue. Also, this is the suggestion thread for suggesting features or changes to PVsyst.

Hello, It would be useful if PVsyst output an 8760 variable which shows whether backtracking is activated or not for each hour. This is used for analysis outside of PVsyst. Thanks.

As you approach the equator, the sun is more directly over the modules. This is to be expected. Not only will the optimal tilt reduce as you move closer, but as you have identified, so will the transposition gain.

For low values, this is expected. A screenshot would help provide more information.

I don't know this inverter specifically, but with other string inverters I have worked with, the inputs can be 'jumpered', so that power is shared across all inputs. Power sharing emulates this behavior. Select "use the sharing...." and select all four sub-arrays onto one Inverter config, then press All PNom ratios identical. Since it looks like you have done that (all have Pnom ratio the same), you should be good.

After having a second look (and since I can't edit), use power sharing for sub arrays 2-5 and balance the DC/AC ratio across all inputs.

The DC/AC ratio is very high, to the point that the inverter manufacturer may not warrant the product in a PV-only system. The maximum DC/AC ratio according to the datasheet is around 150%, or 1.5, which is fairly common. Is this a DC-coupled battery system?

My comment for #1 is that 0.02% is in the noise. I don't much for #2, but you can always rename them in windows explorer without having to rename one at a time in PVsyst.