André Mermoud

PVsyst applies the default values (for getting -3% relative efficiency @200W/m2) to the PV modules of the internal database for which the Rserie is not defined. Now for the PAN files defined by the users, this doesn't make sense: the user should be able to define its own Resistance values. Therefore PVsyst doesn't modify these values anymore, except when these are not compatible with the one-diode model (i.e. Rserie > RsMax).

Sorry, this is an error in the translation tool. The first sentence should be read as "The PV array operating voltage (XX V) is over the required voltage for direct charging (YY V)" This will be corrected in a next version.

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. For each association Optimizer - Inverter, there are limits, namely on the number of otimizers in series and the Maximum power. For this association, the Minimum number of optimizers is specified as 14. I don't lknow why. Please ask SolarEdge people.

Since V 7.4.6, the Rshunt and Rserie are normally kept as read on the file. However PVsyst ensures that the one-diode model can be applied. Namely, if the RSerie is greater than RSerieMax (the max. value for wich the model can be established), the RSerie is restricted to RSerieMax. If desired, you can modify these values in the dialog (for example, increasing RShunt will allow a higher Rserie).

I don't see what you mean. I have just tried with the version 7.4.6 and this works quite well. Please send us the PAN file which is not correctly read (to support@pvsyst.com) NB: The Rshunt may indeed be modified, as it is rounded to something like 50 or 100 ohm, I don't remember. This is not significant in the model.

The BTR file is meant for use within PVsyst. It is not meant for external use. We don't provide support for it. These variables are internal to the model. For defining batteries in PVsyst, you should use the dialog within PVsyst.

Sorry, this is not possible in PVsyst. You cannot specify an heterogeneous string this is a simulation.

This "Euro efficiency" weighted average was proposed by the "Joint Research Center" (center of the European Communities) in the years 1990. These weighting parameters were evaluated from the weather data of their location (Ispra, north of Italy). Another weithing is proposed by the US (CEC), based on the californian climate. It doesn't make sense to redefine these weighting parameters, as this is a "standard" distribution which defines the behaviour of many inverters.

Yes, same answer: PVsyst applies the rules edicted by SolarEdge. Please ask them. Now for the odd number of PV modules in a string of SolarEdge optimizers, this is indeed a weakness of PVsyst, that we have to correct in a next version.

The Voc value as a function of the temperature is calculated from the one-diode model. See the help “Physical models used > Standard one-diode-model” This temperature coefficient muVoc (usually called Beta in the datasheets) is usually not equal to the value mentioned on the datasheets. If you really want to use the value of the datasheets for your sizing, you can define it explicitly in the PV module’s definition, page “Additional data / Secondary parameters”: And specify this option in the project’s settings, page “Design conditions”:

Sorry, your understanding about GlobInc seems erroneous. In the simulation, GlobInc is the result of the transposition from the horizontal plane (i.e. from GlobHor and DiffHor, taking the Albedo contribution into account). GlobEff is the resulting irradiance on the PV modules, after several optical losses like shadings, IAM, soiling, etc. Now when defining the PR from the measured POA data, you should make sure that these losses (especially the mutual shading on the diffuse when tracking) are not affecting your POA measurement. For this you should ideally position your solarimeter on the tracking axis, but far from the PV system for avoiding shades of the neighbour trackers. If not, the measured POA will be underevaluated, so that the PR will be increased. NB: The POA measurement may indeed be affected especially by the shading loss on diffuse/albedo. If needed, your final PR calculation result should be evaluated by correcting the measured POA. i.e. by adding the shading losses calculated by PVsyst.

Yes, this is a limit of the one-diode model. The one-diode model (Shockley equation) cannot be applied when the Vmp/Voc ratio is too high (greater than about 84% or slightly more). This is a limitation due to the diode exponential shape. In PVsyst we consider that the Voc is not important (not significant during the simulation). Therefore we have sometimes to increase the Voc value at STC for applying the model. This is especially the case for the STC data of new technologies like HJT or TopCON (nothing to do with n-type or p-type). Modifying this Voc value doesn't have a significant impact on the simulation results, whch are always operating around the Vmpp value.

The Voc value as a function of the temperature and the irradiance is calculated from the one-diode model. See the help “Physical models used > Standard one-diode-model” This temperature coefficient muVoc (usually called Beta in the datasheets) is usually not equal to the value mentioned on the datasheets. If you really want to use the value of the datasheets for your sizing, you can define it explicitly in the PV module’s definition, page “Additional data / Secondary parameters”: And specify this option in the project’s settings, page “Design conditions”:

Your variant VC3 is indeed very strange. I don’t know how you got this situation. For correcting this: open “Strings configuration“. Execute “Reinitialize inverter list” and then “Adjust sub-arrays”. Then you come back to the Sub-Arrays definition. You have now at the end of the list: Delete each sub-array with a number of strings = 0 (use the bin in the menu of this frame), beginning by the last one. Then the situation becomes correct. You can add new subarrays if necessary (button “Copy selected subarray”). NB: this way of defining subarrays is not quite correct in PVsyst. As all the inverters are identical, a better way would be to define one only subarray for each concerned configuration (i.e. Number of optimizers – Orientation). Then choosing “Strings configuration” => “Reinitialize inverter list” will reattribute a string to each Inverter input in a more comprehensive way. You should then execute “Adjust sub-arrays” if PVsyst requires it before exiting this window.

Please open "Strings configuration" and click "Adjusts sub-arrays".

You are using SolarEdge optimizers. In the inverter’s list, you have probably modified the Inverters inputs, and the concerned sub-array is not connected to any inverter anymore. If this is the case, please suppress this subarray.

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.