André Mermoud

The SolarEdge architecture obeys very strict rules, established by SolarEdge. PVsyst strictly applies these rules. These rules namely define the compatibility conditions between the optimizer and the inverter models, as well as some maximum sizing and operating limits. These limits are fixed by SolarEdge, specifically for each association Optimizer – Inverter. Here the problem is the maximum power admitted for this string with this inverter. Please ask SolarEdge.

No sorry. The results of the simulation concern the whole system. It is not possible to extract such specific data.

The muVoc as result of the one-diode model is indeed not equal to the muVoc (beta parameter) of the datasheets. When establishing the one-diode model, it is indeed impossible to specify simulatneously the muPmpp and the muVoc temperature coefficient. By default, PVsyst uses the muVoc result of the one-diode model for the sizing voltage limit. However in the PV module definitions, you can specify the muVoc of the datasheets (page "Additional data => Secondary parameters", item "Specified mVoc). And for using this value during the sizing process, you have to choose this in the project's settings, page "Design conditions => muVoc values"

If you have 2 cables of 240 mm², you can indeed choose 500 mm² in the box. The red values indicate that the cable section is "slightly" undersized with respect to the norms. PVsyst doesn't allow to use too undersized cables. NB: If you want to really define 480 mm² instead of 500, you can do this correction by increasing the cable length, in order to get the same Resistance.

The wiring loss basic parameter is the resistance of the wires. I.e. the Lenght and section, as well as the metal. Now the percentage definition is only another way of defining loss (i.e. the resistance). It is not absolute: the percentage loss is relative to the operational power, and we can calculate that it is proportional to this power (see the Help). Therefore when defining a loss in terms of percentage, you should specify at which reference power. For this reference, PVsyst proposes 2 options: either the PNom of the inverter, or the PNom of the PV array. So that for a same loss (same resistance), the percentage parameter will be lower for the PNom of the inverters than for the PNom of the PV array. This is fully explained in the Help "Project design > Array and system losses > Array ohmic wiring loss"

Thank you for your project. This is indeed a bug. This arises with very little powers, i.e. when the charging power is below the DC converter efficiency threshold. The simulation does not correctly take the efficiency limit into account (the efficiency becomes negative). NB: this is particularly apparent in your system, where you have defined a DC converter of 500 MW (!). The threshold for the efficiency profile is 1%, i.e. 5 MW. In your system, the maximum power necessary for charging the battery is 150 MW. I have corrected this for the next version 7.4.6.

The battery ageing is not fully implemented in PVsyst yet. - The lifetime is indeed taken into account by evaluating the number of cycles and their depth during operation. This gives an evaluation of the battery replacement necessity, which is mentioned in the "Aging tool" results. - The capacity decrease is not yet implemented. Usually, the battery is considered "to be replaced" when it has lost 20% of its capacity. Please note that such a capacity variation has a low effect on the final yield of a usual storage system. - The increase of the internal resistance is also not taken into account, we don't have reliable information about this. It is obviously never mentioned on the datasheets. This will have an effect on the efficiency of the battery. NB: Improving this model is on our roadmap, but it wil not be done before a rather long time.

First observe that the option "Electrical shadings according to module strings is an approximation, under strong hypothesis. This is valid especially for sheds-arrangements, where you have the shade of the previous row on the full length of the row. This is not valid for specific shadings like yours. In this case only the "Module Layout" can give a reasonable evaluation of the electrical shading effect. This is the reason why you have a parameter "Fraction for electrical effect": this should be 100% for sheds, but allows to correct the result of the irregular shading objects. The only way of evaluating this parameter is to perform the "Module Layout" calculation, and adjust if for getting the same electrical shading loss result. Please carefully read the help "Project design > Shadings > Electrical shadings: partition model". In the graph of this page, when you are shading one only module you are at the very beginning of the graph. Now in the option "Calculation by module strings", when defining a partition with your system, the rectangle should be the rectange corresponding to the full string, i.e. the width of the module by the number of modules. You should not define 3 rectangles because there are 3 submodules. With Twin half-cut cells modules, when these are in landscape they behave exactly as usual modules, and when these are in portrait, you should indeed define 2 rectangles, one for the lower half and one for the upper half of the module.

This was a bug (arising in rare situations), which has been corrected in the version 7.4.3. Please update.

The bifacial model is specific to the sheds (or trackers) arrangement. It cannot be used for multiples orientations. However this doesn't have much interest, as the usual E/W systems cover the ground at almost 100%, so that there is no light for being reflected on the rear side of the collectors. The bifacial gain will be completely negligible.

Answer #1: I can't say anything as I don't know how this is claculated in PV*SOL. Answer #2: The orientation is a geometrical property of the tables of the 3D scene. It is obviously not a parameter that you can specify explicitly, this doesn't make sense. If you want to modify the average orientation you should modify each table as really installed on the terrain (probably unfeasible). NB: The orientation of the plane of each table in PVsyst (when following the terrain) is usually different than the nominal orientation specified in AutoCAD. See https://forum.pvsyst.com/topic/30-with-sheds-on-a-tilted-roof-pvsyst-changes-my-orientation/?do=getNewComment Answer #3: You can always define a new PV module (PAN file) by yourself, using the datasheets. See the video tutorial for that: https://www.youtube.com/c/PVsystTutos

I don't know the kind of grid storage strategy you have used. However the grid storage treatment has been completely reviewed for the next version 7.4.6, namely securized for extreme parameters like very little or very big battery pack, very high load powers. This will be released at beginning of February 2024. In the previous versions, the definition of some intermediate variables was not so clear, namely EAvailB and EDirUse. In the new version, the final results should be close to the previous ones.

In the present version 7, you should gather some close orientations in order to not exceed 8. In the next version 8, to be released this spring, the number of orientations will not be limited.

The "Multi-orientation" option concerns full strings only. Although this would be possible with optimizers, it is not possible to define several orientations within a same string in the present time. This possibility involves a deep modification of the PVsyst simulation, it is on our roadmap, but will not be available before several months. Therefore in your first subarray with one only string, the "Multi-orientation" doesn't make sense. This should not appear in the possible options, we have to correct this. For the second question, the inverters list (specific to Huawei optimizers) only mentions the inverters equipped with optimizers. However this very special case of equipping one MPPT with optimizers and the other one without is not foreseen. It is not possible in PVsyst.

Don't worry, there is no impact on you other data. - The parameters concerning the Meteo data just enlarge a little bit the acceptability of data for exceptionnally sunny data. - The "inverter power is strongly oversized" allows to define systems where the inverter is very badly sized (more than 50% of the PV field). - The conditions on the P90 values for components uncertainty are indeed not very pertinent, we will put these default values at null in next versions.

First of all, this fraction doesn't make much sense. This completely depends on the system area you are considering for the shading loss fraction. It is not the same if you have a turbine on a field of 1 hectare or 10 hectares. The comparison should be done on the loosed energy itself (KWh loss). Now there is indeed an additional loss due to the flickering on the MPP tracking. But we don't have any information about this; this highly depends on the inverter's technology and tracking dynamic performance. It

The transposition model is obviously applied with the exact specified orientation. The values by 15° are simply for the table or plot presentation. However if you want an exact calculation of the GlobInc for your Meteo data file, you should use "Databases > Meteo Tables and graphs". Here you can choose "Tables" and the variable "Global tilted plane".

We don't have much references about the I/V curves degradation. The different publications are very contradictory. The Voc degradations is often reported as very low, but the Vmp is affected namely by the increase of the Series resitance. However it seems indeed that the degradation is mostly to be applied to the current Imp. In PVsyst, you may modify the Current degradation sharing in the Advanced parameters, topic "System design loss parameters, losses, shadings", item "Long term Pmpp degradation, current sharing" (#611). The value is now 50%, we will consider putting a value of 70% or 80% for this parameter in a next version.

If you want to measure the irradiance in the POA, you should choose an orientation for the solarimeter, corresponding to the average orientation of the concerned set of tables. However in your case it would be much better to measure the irradiance in the horizontal plane. In this way you only need one only solarimeter, and you can put more attention to the maintenance of this device. You could also consider measuring the diffuse component (DHI) as well, for improving the transposition. The accuracy of the transposition model in different orientation is sufficienly accurate.

No sorry. You should perform these simulations explicitly without batch. NB: As the variations will not be very hight, you can just do 2-3 simulations and interpolate for missing years. I put this option on our roadmap.

Yes, this is what I said.

You can define a PV module by activating the Bi-facial feature, and specify a bifacial factor = 0. There is indeed a difference when simulating with the bifacial model (and Bifacial factor = 0) and without. The bifacial calculation includes a contribution for the reflexion of the near ground in front of the PV modules (named "Ground reflexion on front side" on the loss diagram). This uses the whole "mechanics" of the 2D bifacial model. This contribution cannot be calculated in a simple way. It depends on several parameters like the ground albedo, the height above the ground, the pitch, etc. It is neglected in the usual monofacial simulations.

These parameters are applied to the MV wiring, at the output of the transformer. The wiring before the transformer is defined in the frame "AC wire loss Inverter to Transfo".

No, this is not possible in the version 7. The bifacial model is calculated for the whole system. This will be possible in the version 8, to be released in spring of the next year 2024.

This optimization tool provides a coarse evaluation for the estimation of your situation when you are choosing your plane orientation. This evaluation is depending on the period, and the season months are chosen as function of the hemisphere (sign of your latitude). However the seasonal dependency is much lower at subtropical latitudes. It is perhap more related to the mussons. If you need a more accurate optimization (and explicit choice of each month), you should use the dedicated tool "Tools => Transposition factor". NB: you are living in a strange region, where the summer is covering the whole year (April to March).