André Mermoud

The correct definition of the time stamp in imported data is a very important issue when importing external data. It is explained in detail in the Help: Meteorological data > Hourly meteorological data > Hourly meteo data quality check Meteorological data > Hourly meteorological data > Time shift The time stamp beginning or end specification is defined in the importing format of the "Import ASCII meteo files" option.

Some answers to your questions • Assuming that the “fans and auxiliary” value is power over and above that characterized in the power threshold value….? The loss is indeed accumulated at each time step, as soon as the instantaneous power delivered by the inverter exceeds the "Power threshold". • Are these losses subtracted from EOutInv, or maybe EArray? They are substracted from EOutInv, as shown on the array loss diagram. • Is the “Fans and auxiliary” value subtracted during hours of operation (once the power threshold is exceeded)? Yes, Is “Night consumption” subtracted during the other hours? It is substracted when the inverter's output is 0. • We don’t understand the “... from output power” field. What happens if this isn’t set to the power threshold value found under the main parameter tab? This field has nothing to do with the "Power thhreshold" of the main parameters, which is the minimum array power at which the inverter begins to produce.

This arises sometimes, and we still don't understand well why. This is usually due to the fact that you have defined big fonts in your Windows installation. Please try to choose little ones. You can do that in the "Control panel" / "Display", or on the Windows desktop, right-click and choose "Personnalize" or "Preferences", "Display". Now sometimes you already have little fonts selected: choosing medium ones may solve the problem. However in some very rare cases, this doesn't work. In this case please contact support@pvsyst.com.

For this example, please send me the whole project in order that I can analyze the situation (using "Files" / "Export whole projects" in the main menu). You can send it to support@pvsyst.com. For the second question: I don't think the simulation behaves as you describe. During the hour of simulation, the battery voltage is evolving according to the energy balance. If a regulator threshold is met (regulator switching), then the part of hour is accumulated as such, and the simulation begins again from this instant according to the new regulation state. This is only possible once in the hour; however it is probably sufficient if the thresholds have been defined correctly (i.e. if the hysteresis is sufficient).

You can simply download the version 5.73 from www.pvsyst.com, and install it over your existing PVsyst. You will find this version 5.73 at the bottom of the PVsyst downloading page.

The estimation of the Battery capacity is a rough calculation of course. It is computed with very uncertain parameters, like the admitted DOD, or the ratio of the C100/C10 capacity definition, or even the capacity specification itsef ! Now for taking the efficiency into account, you are partially right. The capacity is indeed related to the State of Charge (or vice-versa). Now when charging, you have a loss due to the internal resistance, and also the gassing at high SOC. When discharging, you have a loss due to the internal resistance. Both are strongly related to the instantaneous charging or discharging current. For the required capacity evaluation, we should indeed take the discharging losses into account.

The losses are computed using a fixed resistivity, corresponding to a temperature of 50°C (see the help "Glossary > Metal resistivity"). By default, it is supposed to be copper (i.e. 22 mOhm·mm²/m). For the array, this value may be modified in "Detailed Losses" / "Ohmic losses" / "Detailed computation" / "Wires". For the AC losses, the resîstivity is taken for copper, as specified in the Hidden parameters, topic "System design parameters", item "Copper resistivity". The losses displayed in the dialog are computed for STC conditions. But the loss is accumulated at each simulation hour according to the real current of course. The current is taken according to the real power as managed during the simulation, it doesn't change with a different CosPhi.

I don't know this problem. Please send us the concerned MET file (to support@pvsyst.com)

This was an accidental error in the version 5.72, when reading the file. Please update to the version 5.73. Perhaps you will have to redefine correctly the Phi limit if the file was written by the version 5.72.

The wearing state has two parts: - a constant wearing according to the time and the battery temperature: the static lifetime diminishes by a factor of 2 for an increase of 10°C, - a wearing due to the use of the battery, i.e. the number of charge/discharge (according to the specification in the battery's parameters). The simulation calculates the wearing state at each simulation step, according to the IN/OUT current and the instantaneous depth of discharge. You can find it in the simulation results. For example in the monthly results, table "Battery operation and performance", variables WECycle and WEState

This error has been corrected since a long time. Please update to the latest version.

Yes of course. You can read files of the version 5 with the version 6, but not the inverse (upwards compatibility).

No, you cannot define explicitely a PID loss in the present time. You can define a LID loss. For other losses related to the PV moudles, you can use the parameter "Module quality loss".

Hi Shy There were indeed an error in the simulation when using the "Module Layout" option, up to the version 6.19, affecting the inverter efficiency (in fact the EArray value). - Does this strange result still occur if you update to the latest version ? If yes, please send me your whole project. Yes, the Il_VmppMin may result of voltage drop due to shadings in the Module Layout part.

As you mention, when tilting the base of a table its orientation changes. See our FAQ With sheds on a tilted roof, PVsyst changes my orientations With the Helios3D scenes, PVsyst performs an average of all table orientations. You can get detailed information about this distribution and the averages in the 3D editor, menu "View" / "Orientation analysis (Hekios3D)". You will have the list of all tables and their orientations, different distribution plots, and the average calculation.

Let's consider row arrangement (sheds) systems only. In this case when one row puts its shade on the next one, the bottom cell row is primarily shaded. Let's call submodule the set of cells protected by one by-pass diode. In most modules (60 or 72 cells), there are 3 by-pass diodes and therefore 3 "sub-modules", usually disposed in length within the module. Let's suppose that the modules are disposed in landscape, and all modules of the bottom row belong to the same string. Now it is often believed that when the bottom cell row is shaded, the by-pass diodes will limit the electrical loss to the sub-module row, i.e. the string electrical production will remain 2/3 of the normal production. This is only true (about) if you have one only string per MPPT (violet curve). If you have more than 2 strings in parallel, the electrical shading factor is shown on the next figure: this shows that as soon as 1/3 of the sub-modules are affected by the shade, the electrical loss is 100%! Electrical shading factor according to the number of shaded submodules in a string (this plot may be constructed point by point using "Tools" /"Electrical behaviour of PV arrays") Therefore in rows arrangements, the protection diode don't recover any electrical loss: the full string width (module with) should be considered as electrically inactive as soon as the bottom cell is shaded. With the calculation "according to string" in the 3D model, this means that with row systems the Fraction for electrical loss should always be set to 100%. With "Unlimited sheds", the width of the full string should be considered. The next figures show how the I/V curves are affected: the first shows a not-shaded string One only string without shadings and when 1/3 of sub-modules are shaded: we loose in voltage, but the current remains the same. If the string is alone in the array, the Pmpp loss is proportionnal to the number of shaded sub-modules. One string with 1/3 submodules shaded Now when there are other strings in parallel, the MPP is chosen on the resultant I/V curve, and the voltage Vmpp is the same for all strings: for the shaded string, only the diffuse contributes ! 1/3 shaded string in a 3-strings array

In the "Module Layout" calculation, PVsyst always takes the best MPP point indeed. I don't see how to do differently: how to decide which maximum is really taken by the inverter ? By the way this represents a very low energy uncertainty: - the shading situations with 2 MPPt are not very significant: they only concerns the situation when the diffuse component is higher than the beam component, due to particular shading dispositions. - for usual systems, the full electrical shadings loss (module layout calculation) is less than a very few percents during the year. The additional loss would be a fraction of this loss. - the power difference between both points is not necessarily very high.

Yes of course. In this case you define different sub-arrays, one for each array kind.

This has been corrected in the version 6.20.

I don't know any well-established consensus for the simulation of the degradation of a PV system. The usual way is to take the module efficiency degradation into account. Manufacturer's warranty usually corresponds to about -1%/year, but the very few experimental studies about this subject indicate a lower degradation rate (around -0.3%/year on 25-years installations at Supsi - Switzerland). Usually the yield diminution is assumed to be directly in accordance with this degradation. But a recent study pointed out the fact that all modules don't degrade identically, but with a spread around the average, so that the mismatch also increases along the years. In PVsyst, we intend to provide a tool for the estimation of this phenomenon soon. The performances of other parts of the equipment (like inverters) probably don't degrade significantly, but may be subject to failures. The "instantaneous" loss may be accounted by the "Unavailability" during the simulation, and provision for the repair or replacement should be included the maintenance costs.

Yes, in the present time PVsyst is not able to import POA values measured with a tracking sensor. And I don't see any possibility to do this "manually": the transposition factor depends on the GlobHor, but also on the DiffHor irradiance values. When importing POA data, PVsyst performs an adjustment for retrieving a set of (GlobHor, DiffHor) values, which will exactly represent your POA data when transposed to the tilted plane (with the Hay model). We intend to extend the importing tool for tracking systems in the future. But sorry, I don't know when we will have time to do that. This requires that in the importing format, all Tracking parameters (including mode ans stroke limoits) should be carefully defined.

Each Power optimizer works on a different mode, so that it needs a specific development in PVsyst. I have worked closely with Solaredge for elaborating the SolarEdge architecture. I'm on the way just now to develop other power optimizers, with the help of their manufacturers. The TIGO technology should be available soon (within 1-2 months).

In the present version, the electrical shading effect is supposed to be null (or negligible) with the SolarEdge architecture. This is one of the main advantages of the SolarEdge technology, due to the fact that all modules operate with a common current within a string, and all strings operate at fixed voltage. Therefore I don't think I will extend the Module Layout possibilities to the SolarEdge system: I would not know how to do that. However I'm working on other power optimizers, and there may be some residual electrical shading effects, that I'm just investigating now. The results of these studies will be published with a future version of PVsyst, within hopefully 2-3 months.

Don't try to find an explanation. This is indeed a bug. I big bug, that I have never seen. Please check the Efficiency curve in your Inverter's definitions. However this should not arise of course. Please send me your whole project, using "Files" / "Export projects" in the main menu. (andre.mermoud@pvsyst.com)

The OK button stays grey until you have entered full valid data for defining your site (i.e. at least valid Global horizontal and temperatures monthly values). This prevent defining erroneous sites in the database. Now you can define these values either by importing them, or by hand (you can also paste them from EXCEL). The dialog should tell you what is incorrect. Now the sites for the US are stored partially under "USA" and partially under "United states" according to the country definition which have been made in each SIT file.