Michele Oliosi

Hi, Actually we check the areas orientation by orientation. Hence, it is really important that the orientations are well assigned in the system part. First of all, you can choose either to use the mixed orientation on a single sub-array. Or split into two sub-arrays, one assigned to each orientation. - Mixed orientation: at the bottom of the system window, you should assign strings (using a scrollbar) to this or the other orientation. Make sure that the number of strings has been assigned correctly (wrt the 3D scene) - Subarray per orientation: be sure that the orientations are well assigned. This is done at the top left of the system window. If you still experience issues, you can send us the project at support@pvsyst.com, we'll be sure to check it out. You can export a project via the main window > File > Export projects.

Dear julmou, thanks for the feedback, it is noted.

The conversion GHI / POA is not only geometrical, in that you have to decompose into different irradiance components: direct, diffuse, circumsolar, and so on. Each of these components will be transposed differently. Please read: https://www.pvsyst.com/help/models_meteo_transposition.htm Therefore, depending on the diffuse/global ratio, the transposition will yield different results.

Yes we are aware of these potential differences when the sub-hourly variability of irradiance is important and the Pnom ratio/Grid limitation clipping is high as well. Thanks for the article reference by the way. We are presenting a model to take this into account at https://www.wcpec-8.com/. The idea is to implement it into PVsyst.

Hi thanks for the info. Another post was already mentioning this kind of recomputing issues. We are investigating the matter but we haven't been able to pinpoint the exact issue yet. Regarding differences between unlimited sheds and 3D scene, yes, an example would be valuable. If you have such a project with an earlier calculation and a newer one, you can send it at support@pvsyst.com. It could be very useful for us in terms of tracking possible bugs. In terms of shadings there mostly have been bug corrections (as far as recent patches are concerned), hence the robustness has mostly improved. But the calculation itself has not changed. For complex tracking scenes, we have added the possibility to change the 40 tracker cap, above which the diffuse shadings calculation was simplified. This simplified calculation sometimes leads to incorrect results, whenever there are patches of trackers instead of a single homogeneous patch. If you are in such a situation, we recommend you check out this advanced parameter:

Please also check the time shift in minutes (open the meteo file). This may have an impact here.

Hi, The time step in PVsyst is taken in the middle of the hour. This means that for the 7:00 entry the sun is positioned at 7:30

Hi Michele, The ticket is assigned, but we are clearing some other issues at the moment. It may take a few patches for an update on this. The mismatch loss may change when there is aging (we use a statistical model to change the impact of aging on the mismatch). Apart from that and since it is such a small difference (0.01%) this is maybe due to some other edge effect of a rounding. I will keep an eye open about it.

I see it is not very practical at the moment. At the end of the day, the losses are ohmic losses, so a workaround could be to increase the length of the cable (here you could multiply by 6) to account for the higher current in reality (loss ~ RI^2). By computing the effective resistance of your cables you may get to a more accurate workaround.

Hi, Within PVsyst, the fastest way is the "Auto attribution" tool. Here are two options that you can try and consider: This first option allows you to put strings from a same MPPT on the same table: The second option allows you to put strings from a same MPPT on different tables and on the same "height":

Hi Jose, You can import the CSV by going to Databases > Known format. See: https://www.pvsyst.com/help/meteo_import_meteo_data.htm In the dropdown menu you should look for the correct source. If you cannot find the source, you can import the file as a custom format, so go instead to Databases > Custom file https://www.pvsyst.com/help/meteo_ascii_import.htm In the case of PVGIS I think the first option is not available I think, so go for the custom file.

Hi Stijn, That 14% seems quite correct. This is the gain you get from being on a tilted plane (22° tilt, 14° azimuth from your project) medium latitudes, with respect to being on the horizontal plane. I am not sure where the 0.7% value comes from, maybe this is the case at other latitudes.

Hi Arnaud, In the orientation management tool (3D scene : Tools > Orientation management) you can change the tolerance. If you reduce it you should have more average orientations. Not sure if that answers your question though?

Hi Arnaud, For E-W trackers (rotation axis along the NS line), yes it is possible to use the bifacial model. However for fixed dome-like EW structures, no it is not possible yet. Usually the bifacial gain is not very high, since the structure geometry reduces the light available on the backsid.

Hi, usually you would expect a mention in the datasheet looking like the one below with two MPPT input configurations (here A and B). In the example A corresponds to the one accepting more power (4 strings) and B is the lower power one for just 1 string.

The estimate for the time shift, when you import meteo data, is based on a comparison between the clear day model and the best days. You will find more details here: https://www.pvsyst.com/help/meteo_notes_timeshift.htm

@dtarin I raised a ticket we will see what we can do. I believe it won't be that easy (trackers at different altitudes complicates some calcualtions) but it would be a good feature.

Hi Julien, In this case I think SMA provides the curves in a detailed way, you can check this document (see screenshot) on the same page you sent, "downloads" tab. For your second question I cannot answer, maybe someone else on the forum will be able to

Hi ! The "ouput file" option is a way to export monthly / daily / hourly results. https://www.pvsyst.com/help/output_file.htm

Hi, after reviewing the scene, I have a better view of the situation. Basically, the auto-altitude tool is not working as you think it does. At the moment it is not possible to have an array of trackers that has trackers with different altitudes. What I mean is that because of the misalign, your array has trackers that are more or less distributed along the NS axis. In your case, you want the northernmost trackers to be lower in altitude than the southernmost, in order to follow the slope. However this is not what is happening in PVsyst, which has all trackers stay at the same altitude. For example for the array in red: now the horizontal view: For this specific case, I would suggest to try to work with zones, which produces single trackers instead of arrays of trackers. There are a few ways to do this, see for example :

Hi, Basically there are two situtations: One string per MPPT input. In this case, the optimizers allow for the current to remain the same as Impp, and you "recover" your electrical mismatch losses (i.e. the loss due to shading is mitigated). This is formally equivalent to the case where you connect several strings to the same MPPT input, but they are all shaded in a similar way. Several strings per MPPT input, but not all are shaded. This leads to a voltage mismatch between strings, which prevents you from recovering your electrical mismatch losses due to shadings. I'll try to slightly change the formulation in the help to make things more clear.

Hi, Thanks for the feedback. At the moment a workaround is to run the simulation first. Once you save the results, you should be able to go back to the horizon page and print it correctly.

Hello ! PVsyst will check whether the irradiance values seem realistic. It has happened for certain specific locations on earth (e.g. high altitude dry climate like in Chile and neighboring countries) this verification fails. If you think you are in one of these cases, you can change an advanced parameter.

Yeah that seems a good notion of GCR.! I will file a ticket to assess this change ?

Hi ! For us -10° is "just" the default value, and indeed I agree that in several places in Europe you may want to choose something lower than that. Of course in the end it is the responsability of the system designer to ensure that there is no issue, so being more conservative seems best (i.e. 20 or 10 years rather than 5). It is all a matter of how much risk you consider acceptable. Of course, economic considerations however will tend to pull the value upwards... but at the cost of increased risk.