Michele Oliosi

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.

After analyzing your project, I have found that most of the sub-arrays in your system are in an erroneous state, i.e., they do not have the “power-sharing” flag activated. This may happen, for example, if you defined the “power-sharing” once but then switched to not using the multi-MPPT feature at some point. An easy way to correct the state of all sub-arrays is to go to the “power-sharing” window, and click twice on the power-sharing checkbox to deactivate and reactivate it. This will reset the flag for all concerned sub-arrays. On our side, we will try to fix the program to make sure that these situations do not happen anymore.

This is the loss on one day (the selected day). No, the shading factor table represents the loss for a particular sun direction. There is no temporality involved. It cannot be easily converted, you need to run the simulation to convert it to a yearly loss. It is the solar azimuth angle (negative for east, zero towards south).

Electrical shading losses are the total losses due to shadings. Beam linear loss is the loss of irradiance due to shading the beam irradiance. This latter is accounted in the "electrical" loss.

This error message was meant to be present in the previous versions of PVsyst but a bug prevented it from appearing. This has been fixed in the latest version of PVsyst, that’s why you see the error message now. To get rid of the error message, you can go to the advanced parameters, search for “spread” and modify the following value: I hope this helps. Note that cases which have a very large tilt spread may induce a certain uncertainty in the transposition calculation.

Regarding the “Lower temperature for absolute voltage limit”, since this is a safety condition, we make the hypothesis that the cell temperature is the ambient temperature (which corresponds to the highest possible voltage). It is customary to put the lowest possible ambient temperature over several years. The other temperatures are usually not very constraining, so it is okay to put a rough estimate there.

At some point, yes. But it is not too hard to correct the error in the current version. Instead of using the mixed orientation, you can define two subarrays with one MPPT and one string each. Then you can combine them in the string configuration, I think.

Hi, and happy new year as well ! This is a missing feature with our Huawei optimizer string configuration interface. At the moment, it is not compatible with the mixed orientation feature. Without optimizer, this would work. I will file a ticket for this missing feature.

Hello, Are you running the latest version of PVsyst ? If yes, if you can send your project at support@pvsyst.com, that would greatly help us in figuring out the issue or bug. Thanks in advance

Hello, No, at the moment it is not possible to have two bifacial orientations. This will only be possible in version 8, to be released at some point (in principle in the first half of) this year. The annual yield will not change much if you use only one orientation, though, unless you are overloading your inverters. However, the hourly distribution will change, of course.