André Mermoud

This was indeed a bug, that we have fixed but not yet published. Please don't use the axis orientation around 180°.

The horizon line is considered as negligible when all the points have a height less than 2°, and is not used/shown in the simulation. Now after several requests, we will put this limit in the advanced parameters.

OK, well noted. We will suppress this stupid behaviour in batch mode. And put an option for suppressing it also in other situations.

Yes, the Web service has been changed. Please see our FAQ "My Interactive map doesn't work",

On August 5th, 2020, the web access to the interactive map has been changed by the providers without notice, so that all PVsyst versions cannot use this service anymore. We had to publish a new version 7.0.7, as well as a version 6.88, for reading this service. Therefore the only way of getting the interactive map is to update your PVsyst program to these new versions. However please notice that this Interactive Map is a "comfort" tool, it is not necessary for creating a new site. You can do that by opening the first page "Geographical coordinates", and define explicitly the Site name, the country and the GPS coordinates. Then you import the meteo data in the same way as previously.

This is done in the "Module layout" part. You can put your modules in portrait or landscape, and attribute each string to inverters with a great variety of strategies.

In fact in this tool, we don't need the full one-diode model as the addition of I/V curves is only done at STC values. Therefore PVsyst simply performs a scaling of the I/V curve in voltage and current, with respect to the original model. This is an approximation, however probably largely sufficient for such an "uncertain" random calculation.

I don't understand well. If your customer has sent a project in a Zipped file, you have to import it by using the main menu option "File > Import projects". This option cannot return a message "This Zip file does not contain a PVsyst Workspace"

This option of mixing different orientations in a same string is indeed only possible with optimizers. However this is not yet implemented in PVsyst.

The measurement of modules temperature in a field is a delicate operation. To my mind, just gluing the sensor on the backside of the module is not quite correct. The layout of the measurement is very important. Remember that a temperature sensor always measures its own temperature ! See our FAQ "How is evaluated the Module temperature during the simulation ? ". At the end of this post you have a paragraph with our advices: "PV array temperature measurement" Now PVsyst doesn't use the Sandia or NREL thermal model. It proposes a model in which you can adjust the "Thermal Loss factor" (U-value) in order to match you measurements at best. Please read the help "Project design > Array and system losses > Array Thermal losses". NB: expressing temperature differences in terms of percentages doesn't make sense. Percentage with respect to what ? If it is 0°C, this doesn't have a physical meaning. The reference could be anything else (25°C, -273°C, etc) The only way is to express the temperature differences in terms of °C.

it is strongly discouraged to put modules of different orientations in a same string. And especially in 2 opposite orientations. This leads to very high mismatch losses (the current in the string is the current of the worst irradiated module in the string, therefore almost nothing in the morning and the evening). PVsyst doesn't allow to do that. The only way would be to use optimizers, which overcome this problem of currents mismatch. However this is not implemented in PVsyst yet.

If your original data are measured in the horizontal plane, for calculating the GlobInc, you have to use a transposition model. You can use PVsyst for that. - Import your Irradiances data file using "Databases > Import Meteo Data > Custom file". When you are here press F1 for the procedure. NB: PVsyst only works in hourly values. During the import process, it will accumulate your minutes data into hourly values. - In "Databases", open "Meteo Tables and Graphs". Here you can see a table of all your data in hourly, daily or monthly values. You can get the values "Global tilted plane", which is indeed GlobInc or POA.

The position Portrait vs Landscape only affects the electrical losses. Any other discrepancy has probaly another cause. The electrical losses may be calculated: - either using the shading mode option "According to module strings". In this case for sheds or trackers arrangement you should use "Fraction for electrical effect" = 100%. In you "landscape" case, when you have 2 strings on 2 rows, you should define 2 sub-ectangles in the tables. - or using the ModuleLayout option. In your case the rigorous comparison is not possible as the sheds width is about 4 m in 2L, and 1.6 m in 1P configuration. You should keep the GCR constant (adjust the pitch). However the IAM and transposition should be identical. You have probably something different in your layouts. By the way you should only compare the electrical losses.

For the calculation of the weather corrected PR, you need indeed the array temperature, but in hourly values. The expression proposed by the NREL supposes an accumulation/calculation with hourly values. NB: This calculation is done in PVsyst. You can get it under the variable named "Weather corrected PR", i.e. PRTemp. You can show it on the report, by using in the Report's dialog menu: "Settings > General Options > Monthly values table". Here you can choose "Weather corrected PR".

The use of Y-connectors is not involved in PVsyst in any way. With some inverter, the number of input connectors is specified. But this is not used by PVsyst. The only relevant information is the number of strings effectively connected to the input of each MPPT input. PVsyst doesn't check if this matches the number of connectors. For the use of the option "Use multi-MPPT feature", please read the Help "Project design > Grid-connected system definition > Multi-MPPT inverters: power sharing"

The mismatch effect is calculated by adding the I/V curves: - In the string (modules in series) we add the Voltages - In the array (several strings in parallel): we add the currents of each string. Now the result of the mismatch loss is the difference of the Pmpp of the complete array curve with respect to the Pmpp of identical modules. The position of the Pmpp (voltage or current) on the curve is "unpredictable". Sometimes you can have 2 different maxima on the P/V curve. This is deeply explained in the tool "Project's dialog > Detailed losses", page "Module quality - LID - Mismatch", button "String voltage study > Detailed study". Especially the first option "Mismatch: General principles". Here you can press F1 for an explanation of the mismatch issues.

This is indeed a delicate question. The PR is defined on the basis of the GlobInc value (i.e. irradiance in the collector plane, also named POA for "plane of Array"). Therefore is seems natural that for the PR evaluation, you measure the irradiance in the POA. However be careful to put your solarimeter in front of your installation (on the first shed), or eventually significantly above, otherwise it will not "see" the albedo contribution, and may have some shading on the diffuse from other sheds. NB: Even if the albedo is not "seen" by the sheds behind, it should be part of the "official" GlobInc. This is taken into account in the transposition model and simulation. But it can also be interesting to measure the irradiance in the horizontal plane, with a solarimeter positioned sufficiently high. In this case you have the uncertainty of the transposition model for obtaining the GlobInc value. However this is more comparable with usual Meteorologic data. Moreover this is valid if you have several plane orientations in your system, for which you will have "transpositions" calculations suited for each orientation. For tracking systems, many people use to position the solarimeter on the axis. In this case the mutual shading of trackers (on the diffuse and albedo) are not part of the measurement (i.e. the measurement is affected by this shading), but they are accounted in the simulation process. Therefore this POA value is not really the waited value for the simulation. In the present time PVsyst doesn't give the opportunity of suppressing the mutual shadings calculations (usually a loss of the order of 2-3%). We should do that in a next version for simulating systems from this measured (but erroneous) POA value. Without this correction, when you resimulate your system the E_Grid will be lower, as the Shading loss is accounted twice. Therefore for comparing this E_Grid to the E_Grid provided by your original simulation, you should multiply it by (1 + ShdLoss[%]/100). The PR that you directly calculate from your measured data is PR_meas = EGrid_meas / (PNom*GlobMeas). However for comparing it to the "real" PR originally calculated using GlobInc, you should use PR_meas = EGrid_meas / (PNom * (GlobMeas *(1 + ShdLoss[%]/100) ).

Defining the south at top in the southern hemisphere is a choice of PVsyst. This is natural as the installations (tables) are oriented towards north. In this way you see them from front. If you define the north at top, in the perspective views you will see the PV installation from its rear side.

No, only global values for the whole system are outputted by the simulation.

There is no direct way. If Helioscope can issue files in DAE format, you can import them in PVsyst. But this will only concern the 3D geometry, not the other features of the PV installations defined in Helioscope (like PV modules, wiring, stringing, etc).

Irradiance treatment: circumsolar The treatment of the irradiance has indeed been improved. We now distinguish a new irradiance contribution: the circumsolar (enhanced irradiance in a crown around the sun). This contribution was previously included in the Diffuse component, and treated as such in the shading calculations (i.e. isotropically). It is now evaluated from the Transposition models (i.e. proportional to the beam component) so that we have now 4 irradiance contributions: Beam component, circulmsolar, isotropic diffuse and albedo. In the shading calculations and IAM, the circumsolar is now treated in the same way as the beam (i.e. coming from the direction of the sun). This means that the Shading loss on isotropic diffuse is lower, and the shading loss on beam + circulsolar is higher. For the linear losses, these loss contributions approximately compensate each other. But the Electrical shading losses are only related to the beam, and are therefore increased. NB: These improvements are not so important in usual systems. They become crucial in vertical bi-facial systems modelling, for the evaluation of the back side irradiance. This explains the differences of the simulation, in the optical contributions in the losses (shadings and IAM). Low-light efficiencies: The default values of the Rserie and Rshunt PV module parameters is assumed to ensure a low-light relative efficiency of -3%@200 W/m2, with respect to the STC. However in the Version 6, this value was not always attainable (sometimes -4 or -5 %). This may be improved by încreasing the Rshunt, which was not done correctly in the version 6. The new version 7 ensures that the low-light performance is -3%@200 W/m2 in any case.

For the barttery system management, you have - losses of the charging device (AC > DC converter) represented by an efficiency curve as for inverters, - losses of the battery itself (difference Charging / Discharging energy) - losses of the inverter device, - all losses at the output of the inverter may also be specified (AC wiring, transfo losses) in the same way as for a usual system.

Yes you can define a terrain by (X,Y,Z) coordinates. See the help "Project design > Shadings > Near Shadings: Import > CSV Ground data" And you can distribute PV tables on it.

PVsyst doesn't take the MPPT tracking losses into account. This is extremenly dependent on the inverter's technology, and the manufacturers never (or almost never) give information about this performance. If you want to take it into account, you have to include this loss in the inverter's efficiency.

This is the result of the full simulation process, in hourly values during a full year. With models for the irradiance on the PV modules, the production of the PV array, the inverter's behaviour, calculation of losses like shadings and all other losses mentioned on the loss diagram.