André Mermoud

In the Orientation part, you choose "Tracking, tilted or horizontal tracking axis". If your trackers are horizontal, you set "Axis tilt" = 0. You can check "Backtracking" if you want to use this strategy. You define your system (array with PV moudles and inverter(s). Then in the "Near shadings" 3D editor, you create your array by choosing "Object > New > Tracking PV planes", and you define the same parameters as in the "Orientation part. You can follow the tutorial present in the software (just below the "Help" in the menu), especially the part dealing with the shadings scene construction. This doesn't concern a tracking system, but the principles are the same.

Make sure that this file is issued from the program Meteonorm, with the correct mention "Output for PVsyst" chosen at the export time. We didn't have any complaints about the import of hourly files correctly created by Meteonorm since more than 15 years.

PVsyst supposes that you use an image which is a plane view. You cannot use an image seen from a not vertical view. I don't see the problem for getting such an image from GoogleEarth.

No, we have not scheduled such a training.

With a Helios3D scene, the orientation taken into account by the simulation is always the average of all "real" orientations. However we don't have any way for quantifying the error due to the orientation distribution in the present time.

Are you sure that your noon corresponds exactly to the "solar noon" (i.e. sun's Azimuth = 0)? This cannot be the case along a full year. Therefore you always have a slight tilt of your trackers, which may explain this difference.

Have you checked the head for these operating conditions ? There may be many parameters for explaining the behavior of the pump during the simulation.

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