André Mermoud

I had a look on your file: it is not an .OND file, but a copy of the EXCEL line representing an inverter. You could import it in PVsyst by "copying" the file contents, and importing it in the Inverter's definition (button "Paste from Table"). But you file is not valid: the Voltage definitions for the 3-voltage efficiency are missing.

For an update of your license, you have to contact our administration admin@pvsyst.com.

Yes you can easily import SolarGIS data into PVsyst. In "Databases", please choose "Import Meteo Data" and then "SolarGIS". The help gives a summary of all meteo data sources which you can easily import into PVsyst. Please see in the help "Meteo Database > Import meteo data".

This is a problem with the domes manipulation. We have corrected it for the next version 6.43, to be released on March 16th, 2016.

The Rule of thumb remains valid: if your system size is less than around 0.2 miles, you can use the Far shadings option. Now you can also use both options, and analyze the discrepancies.

The Solar geometry calculations are fully described in the help "Physical models used > Solar Geometry"

Please send us the concerned controller file (to support@pvsyst.com).

Everything is fully explained in the Help: "Project design > Grid-connected system definition > Power optimizers > SolarEdge Architecture".

The Hay model is fully described in the help: "Physical models used > Incident irradiation models > The Hay transposition model". For the Perez model, it is more complicated, you have to follow the original article: R. Perez, P.Ineichen, R. Seals, J. Michalsky, R. Stewart: Modeling Daylight Availability and Irradiance Component from Direct and Global Irradiance. Solar Energy 44, no 5, pp 271-289, 1990.

Please see our FAQ When starting PVsyst I get: "The application can not start because it is not signed by PVsyst SA."

This not yet possible. We are working on this. However if it is for example a factory rooftop, you can record a plane image from your Sketchup construction, and use it as a background image in the 3D construction tool of PVsyst.

Sorry, it is a "youth" bug in the version 6.42. You can use the tool "Degradation" only with a new calculation version, not with a calculation version that has been read on a file. This will be corrected in the next version 6.43.

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.