Michele Oliosi

Hi, Unfortunately, in v7 it is impossible to have both trackers and fixed structures in the same variant. You should simulate them separately instead. This limitation will be lifted in v8, to be released sometime in 2024.

which settings in particular ?

Yes, that would be the correct way to proceed. If the irradiance is already reduced by a horizon of some kind, no need to account for it a second time in PVsyst.

In this case, we expect that batch simulation and regular simulation agree. There are however a few reasons for which batch simulation and regular simulation may disagree: The unavailability losses may be randomized again by the batch mode ? Do you have unavailability losses included in your variants ? Aging mismatch losses may be randomized again if they were not “saved as template”. Please check your aging losses. If neither of these are active, please send us an example project and batch parameter file. By the way, you mention 1-20MWh but what is the relative error ? Anything below 0.1% might also be due to rounding errors.

Indeed, 7.3.X was significantly underestimating the losses in some situations. 7.4.X is much better, although we will make a further adjustment for trackers in version 7.4.6.

Hi ! The height above ground is indeed crucial if you are using bifacial modules or large tilt values. For monofacial modules, solely oriented towards the sky, it does not matter too much. Therefore, the height above ground is a parameter in the bifacial model for the backside irradiance. It is available in System, as soon as you choose a bifacial module. The button Bifacial system allows you to parametrize the bifacial modeling.

The date 1990 is an indicator in PVsyst and not an actual year. It means that the year is generic, i.e., you are using multi-year averages or a TMY. If you import your own time-series data, e.g., via the custom import file, you can choose to use the dates specified in the file. If you then use the MET file created by this procedure, you will be able to choose dates according to your time-series.

Apart from unlimited orientations, the orientation choices do not allow specifying the distance between trackers. In these cases, the distance between trackers is specified solely by the 3D scene. It is however relatively easy to create an array of trackers in the 3D scene, and the EW pitch i.e., the distance between trackers is one of the parameters.

Hi, The axis tilt spread does not impact the simulation results. It just lets you choose what is the maximum tilt difference in your scene. If you don't want to see the error, you can just put a large value in the advanced parameter. Note, however, that the more differences you have in tilt in your scene (independent of the advanced parameter choice), the less the transposition calculation will be precise because of the averaging error.

In this case, it is often best to go through the advanced object selection: https://www.pvsyst.com/help/near_shadings_advancedselection.htm If the tilt column is not present, you can right-click on any column header to see the selection of columns:

There is no impact of increasing this number. It simply allows simulating situations which are not well modeled by the bifacial backside irradiance model.

Please check the following help page: https://www.pvsyst.com/help/bifacial-conditions.htm This is not a bug but the current limitation of the bifacial model. It is possible to extend the modeling to situations with an inhomogeneous pitch, via the advanced parameters described in the help page (increase the threshold pitch RMS deviation value). The simulation will run, however the results may be somewhat inaccurate for the backside irradiance.

Hi, This recent publication may be useful to you. https://www.pvsyst.com/wp-content/publications/2023/2023_PVsyst_OneDiodeModel_EUPVSEC.pdf Actually, we fix Rs according to low-light data, i.e., there is no temperature or irradiance dependence in this parameter. Let me know if I misunderstood your question !

Hello, This sounds like a great research. Are you going to publish it? If so, we'd gladly go through it once it's out there. In PVsyst you can always (and it is recommended to do so) import DHI or DNI in addition to GHI. This means that we do not need to rely on DirInt or Erbs for diffuse estimation. Currently, it is also possible to import POA data as part of the custom file import (https://www.pvsyst.com/help/meteo_convdialog.htm). What this does is that it uses Hay for reverse transposition to get both GHI and DHI, and then uses these values for the simulation (as well as the Hay transposition). This means that the POA used in the simulation will be the imported one, however the decomposition in different irradiance components will be according to the Hay model. We could add more decomposition / transposition models if necessary. We will establish this type of developments by first having a thorough look at the literature. I think your research would help us as a first step to assess the need to implement other transposition / decomposition models.

Indeed, please look here https://www.pvsyst.com/help/output_file.htm you want the variable ShdElec

Yes, we differentiate between mismatch caused by shadings (= electrical shading loss, ShdElec) and other types of mismatch (MisLoss), e.g., due to the quality of the modules. If you use “mixed orientations”, i.e., strings that have different orientations connected in parallel, there can also be a mismatch due to that (MixLoss). All these variables are given as hourly values, if you run a simulation with output file https://www.pvsyst.com/help/output_file.htm

Why 0°? Southern facing side will have an azimuth of -90° (E) + 42.2° = -47.8°.

Hi, I see. I don't think you need the batch mode for this. The batch mode allows you to change programmatically system and geometric parameters. But since you have just a single “weather file” (equal to or including your 5 days) you just need to run the simulation once, so no need to vary parameters. You probably would like to produce an hourly output CSV (https://www.pvsyst.com/help/output_file.htm), or a daily output CSV (same interface). There you can choose output variables such as PR, temperature corrected PR, etc. The most important step is to import your weather data. This works better if your whole weather data has more than 5 days. Just import all the weather data (up to one year) with the custom file import https://www.pvsyst.com/help/meteo_convdialog.htm to create a MET file. Then define your hourly/daily CSV output, and run the simulation. Do you need to import array temperatures as well, or should these be modeled? In the MET file creation procedure, you can also import array temperatures. To then use them in the simulation, you should then go to the Detailed losses > Thermal parameters. There you will find a checkbox that allows using imported TArray values.

Eastern side of roof azimuth = -90° + 6.1° = -83.9° Western side of roof azimuth = 90° + 6.1° = 96.1°

In the 3D scene in PVsyst you can import trackers that follow complex slopes, or create such a scene for example with the zone tool. At the moment, PVsyst will calculate the average orientation and apply this orientation to all trackers for the tracker rotation determination (including backtracking), irradiance transposition, and incidence angle modifier. This leads to small averaging errors. However, the shading determination, as shades are projected on individual trackers, is quite precise. With backtracking, the assumption of all trackers moving with the same parameters forbids simulating more advanced “terrain-aware” algorithms. Usually, these algorithms are proprietary and terrain-dependent, which has made them difficult to model in PVsyst (but this may change in the future, hopefully). The backtracking algorithm in PVsyst is therefore comparable to more advanced algorithms only as a first approximation, and is by nature more conservative since there will be more remaining shadings than with a more advanced algorithm.

Hi ! I am not sure what is the intent in using the batch mode. Do you have several years of operation so that you need to run several simulations? Regarding the CSV, you can check the location of your workspace. There should be a sub-folder “UserBatch” in which the batch mode CSV parameter files are stored. If you don't get a new message each time, I assume this is because you have chosen the option “Existing file” in the first tab (which defines the parameter file): Note that you need writing permissions for this folder on your system to create files in this folder. As mentioned before, I am a bit puzzled as to why you require the batch mode. But assuming you want to enter “measured” input data, you can do that by changing the MET file via the batch mode. A prerequisite is to import the measured irradiance and temperature data into a MET file. See this page for more information: https://www.pvsyst.com/help/meteo_convdialog.htm In the batch mode window, you should look for the option “Specify different meteo files” on the second “Simulation parameters” tab. In the parameter CSV, you can then enter the name of the .MET file in the corresponding column.

Hi, I am not sure how you count your degrees (where is 0?, what is the direction of positive angles?), but I am sure it should be easy to figure out using a drawing.

Note, in your situation the strings that are on two orientations are not connected in parallel, because they are connected to separate MPPTs ! Their voltages are independent. So the mixed orientation is not the correct way. The following is correct, you have checked the multi-MPPT feature checkbox. But you should not use the mixed orientation here. You should instead define four sub-arrays (one for each orientation, with 1 string each, and 1 MPPT each). You should then use the orientation power-sharing (https://www.pvsyst.com/help/powersharing.htm) functionality.

In the Northern Hemisphere, South is Az. = 0. In the Southern Hemisphere, North is Az. = 0.

Mixed orientations can only put different orientation in parallel, not in series. So it is not really equivalent. We will work on this limitation in the future but I cannot give you a definite schedule.