Michele Oliosi

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.

No the batch mode doesn't allow to modify the horizon at the moment. It could be implemented at some point. The horizon line values are indeed truncated to the 1st decimal number. We consider this precision sufficient: note indeed that the sun moves of about 15° per hour. For the horizon: the 4th decimal number is what is used for all latitude/longitude evaluations. This means a localization of your PV plant to about 10 m, which is small enough for most systems.

Hi @VUG, In the "module layout" mode aka "detailed electrical calculation", the half-cut technology is accounted by PVsyst automatically. However in the "partition mode" aka "according to module strings", you have to define the partitions as half the string by yourself. A string on one row should indeed be setup as two partitions.

Dear Hossam, the cell temperature is calculated with the ambient temperature at each specific hour.

In other words: The graph selected (Yearly, Summer, or Winter) has no impact on the simulation. What matters for the simulation are the Azimuth and Tilt values you have entered in Field Parameters. The graph shown by default (e.g. winter for stand alone systems) is not a recommendation. It just reflects what (we think) most stand-alone users are interested in. If you want to choose the tilt and azimuth that optimize the yield for the whole year, you can do so.

@laurahin indeed my bad, i was using the term reemitted not really carefully..

10 times the size of the system: it is an approximation of course. By size of the system you can take the distance between the two PV tables that are furthest apart. No sorry there is no tool to calculate the horizon profile. You would need to consider these objects in your horizon line manually, for example after having made some measurements. Example: there is a high rise building but quite in the distance, you can calculate the height above the horizon that the buildng would appear at.

Hi since there are 7 inverters and 6 inputs of type 1 / 8 inputs of type 2, it is not clear for PVsyst how these are to be arranged. Here a possibility (but there could be others!) would be for example: - 6 inverters with one input of type 1 and one input of type 2 - 1 inverter with two inputs of type two. In this case you can prepare the following sub-arrays: - subarray of type 1, with 6 inputs -> assign to configuration 1 - subarray of type 2, with 6 inputs -> assign to configuration 1 - subarray of type 2, with 2 inputs, does not need the power sharing.

Hi, Just a small comment on points 1 and 2: as a rule of thumb in PVsyst we consider that whatever obstacle that is at a distance of about 10 times the size of your system (or more) can be included in the far shadings. Since this depends on the size of the system, you can see how this also will make the point (2) less problematic.

Hi, You are looking at an average/accumulated curve for the whole month, if I understand correctly. Simply put: on some days the available energy is not sufficient for the user. Some other days the energy is more than sufficient for the user. On average, there is more than sufficient for the user, but still some days the user needs to consume from the grid.

In the bifacial model the working assumption is that the axis is in line with the table. This is an approximation, and the impact of it is very minimal compared to other sources of inaccuracy. Indeed, sometimes the axis center is a bit lower than the back of the modules in the horizontal position. In this case, for the "height above ground", you can take the average value of axis center and back of module height, that should give you a good compromise.

Please read https://www.pvsyst.com/help/bifacial-conditions.htm Your average tilt is likely too high for an accurate backside irradiance evaluation. You can change an advanced parameter (Main window > Settings > Edit advanced parmeters) to proceed anyway.

Hi, Indeed I think your supposition is correct, i.e. PVsyst does not recognize well the power sharing relating to this error message. We need to correct this bug. Note however that you can modify the inverter to disregard this error message: PVsyst will handle the simulation alright. The error you obtain is just a message telling you that the contractual conditions are not satisfied, it doesn't affect the simulation.

HI ! The tables seem too small for the module size. If you see the text in bordeaux red, you can see that the tables are 2.26 m by 1.13 m while modules are 2.278 m by 1.134.

Please read https://www.pvsyst.com/help/bifacial-conditions.htm This is likely due to your average axis tilt being too large to guarantee a very acccurate modelling of the backside irradiance. You can change an advanced parameter to pursue the simulation nonetheless, as explained in the help page above.

At the moment PVsyst will allow to work in "bifacial mode" only when there is a single orientation. There is no way around it at the moment. The best, if you can, is to split your system into several sub-systems (different variants) that have only a single well defined average orientation (if the topography is too complex, you can use the tolerance). Now for domes it is difficult to split the system into two separate orientations (because usually they are connected to the same inverter) and averaging the orientation is usually not very realistic. However for domes, since not much light arrives on the backside of modules, I think you can approximate the situation by staying monofacial, i.e. not activating a bifacial model.

IAM losses and transposition: Yes, the average is used. Until now, trackers always have a single average orientation. I assume you are talking about the backtracking strategy. In this case, yes the same pitch and width information is given to all trackers in the scene. There is only a parameter which is defined for each tracker independently, the axis tilt. Trackers with different axis tilts will move a bit differently under backtracking. Regarding the pitch and width, they are defined in Tools > Backtracking managament. In fact the "up to 8 orientations" is only the maximum limit for fixed tilt orientations. It is not related to the shading scene nor to trackers. In all cases, the shadings are computing taking the full complexity of the shading scene into account, including the topography. Basically yes, the calculation of the backside irradiance uses an idealized flat and regular model of the tracker positions.

The above information only concerns version 6. Versions 7 and above work along a novel premise altogether. The parameters "Threshold shading factor from.. " do not exist anymore.