André Mermoud

The angle difference is the angle between the normal vector of each plane. In the version 5, we put a 25° limit as the shadings are only calculated for one orientation, and may be very erroneous if the orientations are too different. In the version 6, the shadings are calculated for each orientation and there is no problem anymore (no limit).

With this kind of mounting you have probably less air circulation (and therefore less free cooling) than with usual row arrangements. Therefore the U-value will be lower. But sorry, we can't give a value for any configuration. The only way would be to measure the U-value on site (long-term measurements).

No. We consider that this NOCT approach is confusing, and not reliable in a system (doesn't take the installation mode into account, and concerns modules in open circuit). PVsyst uses an energy balance, which is fully explained in the help "Project design > Array and system losses > Array Thermal losses".

The Losses for the system indeed may use the inverter's specified losses if available as default values. But you have to define them explicitely. The idea in PVsyst is to give sufficient flexibility for defining these losses in the best possible realistic conditions for your system. Therefore we propose different possible strategies: - A constant loss (all fans "ON") from a given produced power (it is sometimes not necessary to cool the inverter if they work at 10% of their power). - Auxiliary loss proportional to the instantaneous operating power (for example fan's speed controlled by the real temperature increase, i.e. the power, or cooling installation which will have more heat to extract with higher powers). - Night losses of the auxiliaries (fans, controllers, monitoring, etc). The night loss of the inverter itself, as specified by the inverter's manufacturer, is accounted independently in the simulation and presented independently in the loss diagram (if significant).

The effect of the wind on the PV array temperature is expressed as the Uv [W/m2K / m/s] factor, which is a proportionnality factor for the Wind speed. Now PVsyst cannot provide reliable values for this factor, as we don't have reliable measured references. Therefore the only way to get this value is to measure it on site (long-term measurement). Now if you determine this factor with a reference wind velocity measurement at 10 m from the ground, you will get a Uv value. If you admit a scaling factor for a measurement at another altitude, you will obtain a Uv factor scaled (inversely) by the same amount. An (old) study of the WMO proposes a scaling facor (Hellmann model) as: Vh = V10 (0.233 + 0.656 log10 (h+4.75) ) With this expression, the speed at 1.5 m will be 25% less than the speed at 10 m. Therefore the Uv value will be 25% more for a same result.

By introducing a Power factor, you have changed the PNom value at which the inverter will clip in case of overload. Now this only affects the operating conditions when the Power will overcome the PNom value. In other words you have diminished the PNom effective value from 60 kW to 51 kW (real power). The effective loss will only intervene when your system will overcome this value (51 kW instead of 60 kW). The overload losses are not proportionnal to the overload value. The addifitonal loss will be strongly related to your over-sizing of the PV array: if you don't have any overload, there will be no effect at all.

You cans define an Load profile as Hourly values (CSV file in EXCEL). You can see the help " Project design > User's needs ("load") > Load profile: ASCII file definition"

Yes, we have to extend and modernize the definitions of the AC losses after the inverter, and define several transformers. I hope we will have time to do that within some few months.

In a normal distribution, 68% of the "events" are between -sigma and + sigma. But 16% are above + sigma. Therefore above the value (Average - Sigma), you have 68% + 16% = 84% of the event. This corresponds to P84.

For the horizon shading calculation, PVsyst analyses the time at which the sun crosses the horizon line. And applies the shading effect (i.e. suppression of the beam component) only on the concerned hour fraction. Therefore the result is not directly related to the hourly step.

I don't understand what you mean. The PNom ratio is not an input parameter in PVsyst, it is the result of your definitions for the PV array and the inverter. Now you can have some limitations, concerning the accepted overload loss. By default it is 3%, but you can increase this limitation in the project's definition, button "Albedo & Settings".

In the "Domestic uses", you simply define an appliance of 120W, used during 10 hours, and click the corresponding hours in the day circles. H stand for "Hour". 10H is for the period 10:00 to 11:00 AM.

There is no special operation for defining an overload. This is just the result of the definition of your PV array with respect to your inverter. We usually define the PNomRatio as the ratio between the Pnom(PV) of the array, and the Pnom(AC output) of the inverter.

There is indeed a limit, the number of elementary triangles should not exceed 8'190, i.e. about 8'000 points.

This has nothing to do with the previous discussion (about batch mode). However please see our FAQ With sheds on a tilted roof, PVsyst changes my orientation

You can only use the background image in the Plane view in PVsyst. Therefore importing images which are not a plane view doesn't make much sense.

The behavior of this system seems indeed strange. But the information about the system is not complete. Please send your whole project (using "Files => Export projects") to support@pvsyst.com.

The shading table concerns the beam component, for the instantaneous position of the sun. By definition of the backtracking, the shading factor is null. However for each position of th modules, you have a shading factor on the diffuse part (coming from all directions of the space). The final diagram shows the corresponding loss on the diffuse part. See How is calculated the shading loss on diffuse for tracking systems?.

The Irradiance units are not correct. However it is not possible to import POA data in daily values. The retro-transposition model only works on an hourly basis.

In PVsyst, an horizon line below 2° is not taken into account. By the way this would not be significant, especially in sub-tropical climates.

The "Availability" parameter defines periods of Failure (which may be generated randomly if desired) They could be defined for example by night, therefore leading to no loss. Please check that in your "Detailed Losses" the failure periods really occur during significant production times.

This error has probably been solved in the version 6.41. Please try. If it doesn't work, please send your whole project to Support@pvsyst.com, using "Files > Export project" in the main menu

Yes, the format for importing Hourly Load data has been changed. You have now to prepare a file in the "Standard PVsyst format" as described in the help "Project design > User's needs ("load") > Load profile: ASCII file definition". Sorry for the inconvenience, it was necessary for a modernization of the PVsyst Load management. This format will also be useful for importing other parameters in Hourly values in future versions. You have a template of this file in "c:\ Program Files (x86) \ PVsyst6.x.x \ DataRO \ PVsyst640_Data \ UserData\ Hourly_Parameter_Template.CSV" (or ... \ SubHourly_Parameter_Template.CSV). Your own data file should be placed in your workspace \ PVsyst640_Data \ UserHourlyParams \ NB: Thank you for your example file: I tried it and it works correctly (see the graphs after importing). Just the file Preview does not work correctly: it doesn't recognize the comma as separator. I will correct this.

I just tried and everything works correctly. However in the version 6.40, the Variables to be written were not well recorded on the Calculation Version (VCi) file. So that when reopening a VCi file of the version 6.40, when outputtting an ASCII file you have to explicitely redefine the variables to be written before simulation.

No, we don't organize training sessions elsewhere than in our offices at Geneva (except sometimes for the team of a company).