André Mermoud

This is indeed an error: this verification doesn't apply to the "Lake or River" configuration. This will be corrected in the next version 6.53. In the meantime, there is a workaround: in the "Hydraulic Pumping circuit" definitions, you should choose for Pumping system type "Deep well to storage", modify the parameter "Max. pumping depth" to a high value, and come back to your "Lake or River to Storage" option.

Thank you for your project. I have indeed found the error in the simulation. This affects the way of distributing the losses (some part of oveload is transferred to the efficiency loss), but doesn't affect the final result. I have corrected for the version 6.53.

The definition of the parameter "Limit overload Loss" has been moved to the Project's parameters (button "Albedo&Settings") since a long time. The value in thew Hidden parameters only acts as initial value for new projects.

The spectral effects are not considered for Crystalline modules. They are considered negligible. With amorphous modules, you have indeed an evaluation of the spectral effect, i.e. the deviation with respect to the AM1.5 conditions.

I don't know. Please attach an image of what is wrong.

Importing DXF files is not yet possible in PVsyst. The *.SHD files are meant for internal use, not for public modifications. You can sometimes modify something with some success, but the format has a strict structure suited for the internal organization in PVsyst. It is closely related to the object's defined in the 3D scene and their interactions. It is not possible to describe it in a simple way, and we don't intend to do so.

PVsyst tries to read your data in the american format MM/DD/YY instead of the European one DD/MM/YY. You should specify this format in the Format protocol.

Sorry, we have just discovered an error in the TArray evaluation: the averages of TArray in Daily or Hourly values don't work correctly, as the operating time is not well registered. If you want significant values of TArray, the only way is to analyze them in hourly values (in the CSV file). This will be corrected in the version 6.50.

This tool is behind the button "Miscellaneous tools". This will automatically be apparing on the Report as soon as you correctly define it (no red warning).

The fog is in principle included in the meteo data. There is no possibility of explicitly modifying the meteo data within PVsyst.

In the version 6, the "Module Layout" construction and calculation is based on the 3D shading scene. You cannot add customized shades.

This is also named "Irradiance loss". This represents the beam deficit due to shades. See the help "Project design > Shadings - General" and also "Project design > Shadings > Near Shadings: Main dialog > Shadings treatment of Beam, Diffuse and Albedo"

When the "Minimum voltage for PNom" is specified in the inverter's parameters, this corresponds indeed to an input current limitation. This current limit corresponds to the value I limit = PNom / VmppPNom Now when the Impp of the array is higher than this current Limit, the loss with respect to the available Pmpp is accounted in the IL_VMin loss.

A model for treating bifacial systems will ba available in the next "major" version 6.60, hopefully before the end of this year. However no manufacturer has submitted Bi-facial modules for the database up to now.

This sentence is meant for the irradiation, as the PR is referenced to GlobInc. The PR is obviously related to the temperature. But this is a second-order variation when comparing systems in different locations (same region) or different orientations.

You can use a not-null longitude value. Remember that 1 minute represents less than 2 km. This is completely negligible for the use of PVGIS values.

Yes you can import POA measured values in PVsyst. Please use "Databases > Import ASCII meteo Files", and press F1 for the procedure. The format protocol includes the possibility of reading Global Incident values and PVsyst will perform a retro-transposition.

The difference between Central and distributed inverters is not quite clear. An eventual cloud effect difference is probably completely negligible, as the mismatch between strings under different irradiances (different currents) is very low. In the present time, PVsyst doesn't show any difference between these 2 options, except if you carefully specify the DC wiring losses in each configuration. A difference may perhaps occur because of a mismatch due to the string's lengths in central configuration. This problem is under investigation.

It is no more possible to create a site for your project from the Project's dialog (button "Site and Meteo"). PVsyst now requires that you create and save your Project's site within the database ("Database > Geographical site").

This error message "The shading table has not been computed" appears here by mistake. In fact the shading table is correctly computed at the beginning of the simulation, which arises after this check. This should be corrected in the next versions.

This is quite normal. If you have a grid limitation, the inverter works more often in the lower part of the powers, where the efficiency is different. When analyzing your hourly values, you will see that hours without power limitation have the same efficiency.

This is indeed a limitation of PVsyst. You can only define a sub-array with Mixed orientations for the Orientation #1 and #2. I don't see any workaround except trying to avoid the use of mixing on a third orientation, by distributing the strings differently on your MPPT inputs.

When creating a new calculation version, the voltage drop in the series diode is initialized at a null value. The default value of 0.7 V only appears if you ask for this (click the checkbox). In old installations people used to include a blocking diode in series with each string, for avoiding reverse current from neighbour strings in case of mismatch. However this is useless as even when a string is almost completely shaded, its voltage remains close to Voc. Moreover, these diodes were subject to failures, which were not always detected. To my knowledge, nobody uses such diodes anymore nowadays. These diodes have nothing to do with the by-pass diodes, which are quite necessary for the protection of modules against Hot-spots. All crystalline modules do have such diodes. These diodes are completely inactive in absence of serious mismatch conditions (partial shadings).

You can use the Batch Mode, and perform a simulation with different Site and Meteo data files. However, it is not possible to start a simulation just by specifying the Latitude/Longitude. You have to explicitly construct each geographic Site and each Hourly Meteo file in the database.

The data specified at the beginning of the loss diagram is the Irradiation on the Horizontal plane. This is taken from your Meteo hourly file *.MET The data in the orientation of the optimizing tool is the Irradiation in the plane of the array. It is normally different. But in this particular case the plane is horizontal, so that it should be identical. For technical reasons, the Meteo data used for this optimization tool are taken from the Meteo data of the site you have specified in your project. As I understand you have imported data from Meteonorm and from NASA. Probably the Project's site data are from one source, and the meteo file *.MET is from the other. NB: the values provided by the orientation optimizing tool are marginal in the software: they are just here for an estimation of your orientation with respect to the optimal, not for an absolute irradiation evaluation.