André Mermoud

Yes it is still difficult. I have established a model (i.e identified 3 main modifications of the standard one-diode model) which works quite well, and matches the real modules behaviour with a very good accuracy. The problem when using this model in PVsyst is to find the good parameters, as the information provided by the manufacturers is usually not sufficient. However the default parameters proposed by PVsyst seem to give good results. See my paper Performance Assessment of a simulation model for PV modulesof any available rechnology, ( 25th EPVSEC – Valencia, 2010), available on our site http://www.pvsyst.com.

In the version 5.73, the night losses are the iron loss of the external inverter. In this version, night loss of the inverter output or auxiliary losses had not been implemented yet.

For the PAN "proprietary" format: if you want to reproduce the old DELPHI encoding of reals on 6 bytes, and modify/update your reading according to all specific parameters defined (or not) for each PV module, I can give you the format. You will probably spend several days (or weeks) for using it. I really don't know any model specifying the effects of the humidity on PV modules, and I can't imagine which phenomenons could affect the PV module behaviour (except morning condensing effects). Please explain. However the meteo data of PVsyst don't include the Humidity information in the present time, and I don't intend to include it unless very strong reasons. Now for the comment of the W7 cell, you should indeed read: "For crystalline modules: if not specified, will be a result of the one-diode model, which is very close to the usual reality".

For the shading loss changes: If your system involves unlimited sheds: in the version 6.13 to 6.18, there were an error when reading the VCi file. The plane tilt used for the evaluation of the shading effect on the diffuse part was not read correctly, which underestimated the shading loss. This error didn't occur with new calculation versions, or if you opened the "Orientation" dialog before the simulation. This problem has been corrected in the version 6.19. On the other hand, the diffuse model is the same in both cases: just the denomination on the report has been changed. "Measured" was used previously for any values read on an hourly file (whatever the origin, which is not known by PVsyst). Now for most meteo data, the diffuse is indeed issued from a model. Therefore this denomination is not correct. In the new versions we have tried to put some more accurate description when we have an idea of the origin of the data. When creating synthetic data (which uses the Meteonorm algorithm), the diffuse is constructed by the Meteonorm software, using a Liu-Jordan or similar (Erbs) model.

The PAN files are written in a specific binary format, only readable/writable by PVsyst. If you want to manage PAN files explicitely, you can use the Import/Export facility to an EXCEL document. You have a template of this EXCEL document in your \PVsyst6_Data\UserData\. The Import/Export procedure is explained in this document. However it is of course not possible to add your own parameters in the file, besides the "official" format. How would they be recognized by PVsyst ???

If so, this is indeed a bug, and I will investigate this. However in the "Detailed Losses" part, if you define the IAM explicitely by unclicking "Uses definitions of the PV modules", the IAM is now specified for the sub-array itself, and will be kept if you change the PV module.

The 6.1.9 version is indeed the 6.19. I don't know why you cannot install it. Please explain what happens.

Each array connected to a given MPPT input should be "homogeneous" (i.e. identical PV module and number of modules in series). You should define one sub-array for each kind of "homogeneous" array.

Yes, if there are several inverters, the section managed by PVsyst is indeed the sum of all individual sections of all inverters. The minimum section proposed by the program corresponds to the section allowed (by usual practice or regulations) for the concerned current.

I don't know. Which version are you using ? Please send me you full project, using "Files" / "Export whole projects" inthe main menu (mail to andre.mermoud@pvsyst.com).

You are right, the grid limitation is applied to the PNom(ac) of the inverters in the present time. The losses after the inverter are not taken into account. In a first try, I just foresee this for a simple case. This is the easiest way for programming. However I have to do some improvements and give some further possibilities to this grid limitation for a next version. - As you propose, the limitation at the injection point: not easy because PVsyst has to perform the calculation twice for each concerned hour. And I'm not sure that the inverters will operate in this way in the reality: this would require a continuous measurement of the injected power, and a return of this information to the inverter software. - If you have several sub-systems (not in the same orientation) the limitation should indeed be applied to the injection, and will act differently on each sub-array. Again this involves the re-calculation at each concerned hour, and is not simple to include in the simulation.

This is an error within your shading construction file: a parameter set at an unexpected value (I don't know why). I have protected the program against such cases, for the next version 6.19.

The wiring resistance is defined for each sub-array separately. It is the equivalent resistance of all wires, as seen from the input of all inverters of the sub-array in parallel. You have just to put all the string resistances in parallel, and add the resistances of all connexions from the roof junction boxes to the inverter inputs. This is straightforward for any electrician engineer. The tool "Detailed computation" helps you for this calculation. Now the resistance is around 5.5 mohm/m for 4 mm2, and 8.8 mohm/m for 4 mm2 (listed in PVsyst, button "Wires"). As an example, If you have 40 m of 4mm2 cable for one string, this will represent 220 mOhm/string. I.e. 22 mOhm for 10 strings in parallel. I don't see how you can get 0.005 mOhm except for a multi-100 MWp instalation (this would represent 44'000 strings).

Further information. First of all, on your table you don't mention the differences (in percentage), so that the visual analysis is very difficult. Now in PVsyst the PR is computed from the whole simulation process. This involves other losses which also vary along a day. These are mainly the IAM loss, eventual shading effect, module efficiency according to the temperature, wiring resistance loss. Other effects of second order may also occur.

For a row installationm if the cell strips are in landscape (not necessarily the modules: in some modules the cells are along the little side) this is indeed the worst situation and you will have a full electrical loss as soon as the bottom of the modules is shaded.

This may probably be due to a dissymmetry between morning and evening in your meteo data. Or an horizon shade if any. I don't see other explanations. However such low differences are not necessarily very significant

I don't know if this error is due to the size of the plant. However the "Module Layout" part is not suited for such big plants: see our FAQ How to use the Module Layout with very big plants?

In PVsyst (as in the reality) the overpower conditions is indeed achieved by a displacement of the operating point on the I/V curve (towards higher voltages). But in the present time PVsyst doesn't take the possible overpower (defined by some manufacturers) into account. See the FAQ How PVsyst treats the specified "maximum" power of inverters ?

The design of the PV array (namely the number of modules in series) uses a set of design temperatures, used at the design time only for parameter suggestions or system configuration checks. These temperatures may be specified for your project (button "Albedo-Settings"), and their default value for any new project may be specified in the Hidden parameters, topic "System design parameters". - TMin: Lower temperature for Absolute voltage limit: The Voc(Tmin) requirement corresponds to a safety requirement: The array voltage Voc should never overcome, in any case: - neither the inverter's VabsMax (absolute input voltage, corresponding to the input electronics circuit voltage limit), - nor the absolute array maximum voltage admitted for your PV modules (usually 1000 or 1500V). Therefore the reference temperature for this evaluation is the lowest temperature even observed on this site. - In middle-Europe climate (and not in altitude), a usual best practice is to choose -10°C. But this should be decreased for high altitude or northern regions. - In other situations, you should take the lower temperature ever observed during the day (eventually with an irradiance superior to 10 W/m2) for this site. Choosing 1000 W/m2 means that in worst case, in winter the sun may suddenly appear on the array (cloud), and in this case the cell's temperature may be the ambient temperature. Remember that the Voc is very slightly dependent on the irradiance. These conditions are a common practice, adopted by everybody. They are specified in the norm IEC TS 62738 (2018), paragraph 7.2.1. Now if you want to overcome these constraints (which is really not recommended), you can: - modify the reference low temperature in the Project's parameters (button "Project Settings"), - modify the muVoc coefficient if you don't believe the PVsyst's model value (in the PV module definition, page "Additional data > Secondary parameters" ). - artificially increase the maximum voltage limit in the Inverter's and/or PV module's definitions. NB: These modifications will alter the warranty of your PV system. If you do that this will be at your own risks. - ToperMin and TOperMax: the usual operating conditions of your array, during winter and summer (cell temperature). ToperMin will be used for the maximum number of modules in series, in order to stay below the VmppMax input value of the inverter. ToperMax will be used for the minimum number of modules in series, in order to stay above the VmppMin input value of the inverter. These values are not critical, and may usually be let to their default values. Slightly overcoming the voltage limits doesn't induce important losses (in case of doubtful sizing, you will observe an "Inverter loss over nominal voltage" or "Inverter loss due to voltage threshold" in the loss diagram of the simulation). - TOper: Usual operating (cell) temperature under 1000 W/m2, is an intermediate value, only used for the display of a usual "operating power" in the sizing dialog (and the report). In the version 6, these definitions are part of the parameters of your project, button "Albedo and Settings". They may eventually be modified according to your climate. The default values (initializing value for each new project) may be redefined in the Hidden Parameters, topic "System design parameters". These parameters are used for design only. They are not involved in the simulation in any way.

In the next version 6.18, there will be an "Hourly-Monthly" table of E_Grid, i.e. the production of each hour of the day for each month. You will be able to export it in EXCEL, and associate your specific tariff to each hour of each month.

The mismatch effect with strings in different orientations is indeed taken into account in the simulation with Heterogeneous fields "mixed orientation". However the mix of 2 strings in 2 orientations will have different currents, but about the same voltage: this doesn't produce a significant mismatch loss.

This is just a pedagogical tool, for understanding the mismatch phenomenon on one I/V curve. You can evaluate the mismatch loss between 2 different sub-arrays with strings in different orientations, connected on a same MPPT input, by performing a full simulation using the option "Heterogeneous fields - Mixed orientation", and compare with the results of 2 different systems in each orientation. For parallel strings, the mismatch effect due to different orientations is usually very low.

I can't reproduce this problem. It works quite well on my machine. Does it arise for any system, or just for a particulat one ?

This is a feature of the Forum engine. We don't know how to manage it.

In stand-alone (or pumping) systems, the Unused energy is the energy which could be provided by the PV array, but which cannot be used because the battery is full. I don't understand "Horizontal Global Orientation". This doesn't have any meaning. The Global horizontal irradiance is determined by the meteo data of the location. The orientation of the collectors is your choice. The irradiance in this plane is indeed dependent on the azimuth of your chosen plane orientation (through the "Transposition" model). The output of a PV module is the EArrNom value "array virtual energy at MPP", calculated from the one-diode model.