Michele Oliosi

The option "external ambient temperature with shift", allows to define that the inverter temperature will follow the ambient temperature, plus or minus a constant value in degrees that is defined as the "Temperature increase". For example if you define a temperature increase of 5°C, and at a given time the ambient temperature is 38°C, then at that time in the simulation the inverter temperature will be 43°C.

@herminator are you sure that it is only in the report? As mentioned these values should come from the 3D scene > Tools > Backtracking management, and these are important for the simulation. I woudl suggest double checking that.

To be precise, you could choose either "unlimited sheds" or "fixed tilted plane". However since in your case you would have 3 orientations, you would have to use "several orientations" and that is not compatible with the bifacial model. At the moment therefore, the only way is to make two different variant simulations, one for the bifacial part, another for the rooftop two orientations

It may be related to a new bug that affects PVsyst when importing 3D scenes: the backtracking parameters are not always updated. Until we have corrected the bug, you can go to the 3D scene and open Tools > Backtracking management. There you can select a tracker in the list or enter the values manually.

The behaviour above will be retained for all 7.3 patches, including the latest one 7.3.4. As mentioned we are working on an overhaul but it will be made avaiable in a new sub-version: PVsyst 7.4.

We have an article on this topic if you want to go further ! https://www.pvsyst.com/wp-content/uploads/2022/11/Article-PVSEC-2021.pdf

Hi ! In fact the interpretation of partitions (or as they are called in this window "rectangle-strings" which I think we will change eventually since it is confusing) is a bit more complicated than a string. It's worth going back to the factual definition. These partitions represent a group of PV modules (or submodules even), whose power is lost, effectively, when part of it becomes shaded. The concept of partition mostly makes sense when the shadings are regular, i.e. they tend to cover all modules within the same group in the same way" Typically this is the case with mutual shadings, or shadings from "wide" shading objects (e.g. a row of trees, a fence, a wide parallelepiped). This is because when the shade falls on the PV tables in a regular way, then one can by simple considerations find out whether the power is lost or not. Take for instance a string of modules in portrait: if all the bottom cells are shaded, then all submodules are limited in current because of the shaded cells. By extension, the whole string can only support as much current as the shaded cells allow. In this case part of the partition is shaded, then the whole string becomes inactive. Now, even if you split the above string of modules in portrait into three tables (like in your example but with modules in portrait), as long as the shades that cover the tables are similar (usually because they form regular rows) the situation is the same: when all the bottom cells are shaded, then you will lose the power from the three tables. For this reason, in the case of regular rows, no matter whether the string is split among tables, you can still safely define one partition in the length of the table, as though your strings were shorter. In the partition framework, there is usually no need to define fractions of partitions. There can be more complications when using the partition framework to define electrical shadings. In some situations, for example for half-cut modules in portrait, or for any modules in landscape on one module-wide tables (such as your example), one should not define a single partition per string, but rather two. This is because a shadow on the bottom cells does not invalidate the power of the whole string. Due to the bypass diodes and cell layout, about half the power is retained. TLDR: in your case, I would put two partitions in the height of the table for all of your tables. The reasons for this are: when the modules are positioned in rows, the shadings are usually the same for all the modules. You therefore don't need to define fraction of partitions if your strings are split across tables. your modules are in landscape so you can define two partitions in the height (axis Y in your screenshot) of the table. Btw this is usually beneficial to the yield.

Hi, You can check your inverter night consumption (System > View inverter details), transformer night losses (Detailed losses > Ohmic losses), or auxiliaries (Detailed losses > Auxiliaries). All these may consume some power at night. Since there is no solar energy production, this can lead to a negative value of E_Grid

Hi, if reverting back to a previous version did not change the simulation speed, it probably is related to some parameters in your project. We'll gladly have a look at what is causing the slowness. You can send us your project for review at support@pvsyst.com.

Very good question. Indeed in PVsyst the view factor calculation incorporates the IAM factor, according to the Fresnel smooth glass model.

Hi indeed, I think you don't need to add up voltages, the strings are basically in parallel.

The horizon model has been improved in 7.3.3 and it should also cover the bug we mentioned. The results may still differ a little from 7.2.21 but this is due to the improvement: we now consider more correctly, within each hour, the fraction of the sun trajectory that is behind the horizon. Please let us know if you experience anything strange agin.

Thank you for your comments! Okay, thanks for the remark. We will then have to review again the different data sources and see what usable data we find. We'll see to keep up to date on this. Indeed physically it is not so complex (although one needs to be careful with a few models, for example the thermal one as you mention). But purely in terms of code we would have to change a lot of things. As mentioned, we are actively working on the subject of subhourly clipping, since there are still few questions to be elucidated. We will present further conlcusions of our studies at PVPMC2023, and the poster should be made available online. With these studies we are gaining a lot of new understanding that should also help in the longer term to transition to sub-hourly simulations, if necessary.

Hi, The Orientations management works in the fixed tilt tables case, but not for trackers. At the moment in PVsyst, you can have only a single tracker orientation. If you want to proceed by considering the average tracker angles nonetheless, you can change the following advanced parameters (home window > Settings > Edit advanced parameters): This should help you bypass the error.

Glad I could help !

Glad I coud help ! In the release notes: Basically there was a correction to the way the horizon is accounted for, in the hours in which the sun passes behind the horizon line. Consider hypothetically a tall mountain peak, behind which the sun passes in less than one hour. Before the update, the corresponding hour would have had no far shading losses. Indeed one considered the beginning and the end of the hour to verify whether the sun passed behind the horizon. We now account for the time span behind the horizon. even though it is only a fraction of the hour.

Indeed that is correct.

I agree with @dtarin Since you have selected "limit applied at injection point", if there are sufficiently high losses between inverter and the injection point, the power will be too low to be limited.

it's the colloquial name for a hourly output file (8760 hours in a year) see https://www.pvsyst.com/help/output_file.htm

If you have a .MET file, you can use Main window > File > Import components > From a folder.

Only in the presence of irradiance. By definition there will be no thermal losses at night.

Hi the help page will be updated after our upcoming patch 7.3.3. Hopefully it will make things more clear. The basic idea is that any partition that is partially shaded will contribute as if it was completely shaded. That's what is meant in the text when saying "become inactive". There is no notion of "shaded string" when using the partition model, only of shaded partition. If you have only half the modules in the string that have the same shading, the resulting electrical shading loss is difficult to model with the partition model. There are two cases: the string is on a single table in a 2x15 configuration. This is in general fairly well modelizable with the partition model. Depending on the type of module (half-cut cells or not) and its orientation (landscape or portrait) you may need to put a different number of partitions to model this properly. the string is on two tables in a 2x(1x15) configuration. In this case, there is not much you can do with the partition model to model this accurately. In general however, this situation is marginal on your whole system, so it is okay to assume that in "most cases" the shading is the same for the two trackers.

This should be fixed in the upcoming update !

Hi, I assume that the .pvsyst format is the same as our standard format: https://www.pvsyst.com/help/meteo_pvsyst_standard_format.htm I think you can just add the extension .CSV to your file name. You can then import it via the home window > Databases > Known format, and choose PVsyst standard format in the list. You should be able to import your file.

By thermal losses we only account the losses due to the loss of efficiency when the module heats up during the day. Unless you are concerned with infinitesimal variations of temperature, since the thermal inertia of modules is about 10 minutes, you don't need to merge the heat transfer throughout the year, day and night to simulate in hourly steps. Considering the heat transfer within the hour is enough.