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".