André Mermoud

The opportunity of defining chosen *.VCi in the batch mode for reruning all of them at a time is available since the version 6.26.

Formally, you are quite right. I will correct this for a next version. However the error is not very important: if we take Alpha = 0.9 and Effic = 15%, the error (1-Alpha) * Effic = 1.5%. This is a correction on the U-value, which is usually not known with a better accuracy than perhaps 10 % or more. The only cases when this U-value may be well known is when you fit it on your measured data. But in this case, if you fit it with this erroneous equation, the simulation result will be coherent with your measurement !

When in the batch mode definitions, you tick the box "Create Hourly Files", you will be prompted to define the variables to be listed in the hourly file. Then, in the parameter specification list in EXCEL, you should have a column "Create Hourly File" / "File name". In this column, you should define a filename for each desired hourly file (usually with CSV or TXT extension for an easy reading in EXCEL).

I can't give a definitive explanation if I don't reproduce the problem by myself. It is not clear what are the conditions between your two runs, if it is with the same version of the calculation version, etc. Some hidden parameters may have been changed. In the Parameter's part, the Imp/Vmp values are computed from the model at 50°C. The data of this module have not been changed in the database since 2012. However the reference temperature may have changed. There are many calculations by successive approximations in PVsyst. Usually they give stable results, but there may be exceptions. Now please admit that a discrepancy of 0.012 % is not really worrying...

In the 3D scene, the orientation of the modules is not dependent onorientation of the building. However if you have to put your modules not perpendiculary and to define rows of different lengths, you have indeed to define each row independently. If the rows have the same width, you can define a lateral shift from row to row ("misalign" parameter).

It is a usual belief to think that systems with string inverters have a better yield than centralized ones. I am not sure of this, if there is a differece, it is probably very low. How can this be taken into account in PVsyst ? - The main implication I can identify is the electrical mismatch losses under partial shadings. This graph shows that with one only string on one MPPT,the loss is limited (blue line); but as soon as you have two strings or more in parallel on one MPPT, the electrical yield for beam becomes null as soon as you have 1/3 of the submodules shaded (i.e. the case of sheds, with the bottom cell's row shaded). See also How to evaluate the effect of by-pass diodes in shaded arrays?. Electrical Shading loss acc. to number of strings on the MPPT This diagram shows that the configuration of "One only string per MPPT" will indeed have a lower electrical loss. Equivalently, if you put all bottom strings of different tables on a same MPPT input, you will get the same result. This configuration should be preferred with string inverters with few MPPT inputs. - The wire length variations - and therefore wiring voltage drops - are obviously higher for centralized systems. A new tool of PVsyst will show that the mismatch between strings of different voltages is extremely low. As an example: for a 500 kW array and 4mm² string wires, one central inverter would have 0.17% mismatch loss, when distributed string inverters with 2 strings per MPPT would have 0.05%. - The number of MPPT (centralized or distributed systems) may have consequences on the wiring layout. It is your job to define and optimize the wiring and therefore to calculate the wiring resistance of the PV array or the full system. - Big inverters may have a higher MPP tracking inefficiency (due to response time). PVsyst doesn't define this inefficiency: it assumes that it is included in the inverter's efficiency profile. However very few manufacturers give information about this inefficiency. - With big systems we can imagine a mismatch effect because of inhomogeneities due to clouds passages. These are transient phenomenons, not really significant on the hourly accumulations of the simulation. By the way the mismatch loss between strings of inequal irradiances is usually very low. - Finally, an inverter failure will be easily managed with string inverters, when it penalizese the running of the full centralized systems. This could be taken into account when specifying unavailability losses. Besides these arguments, I can't see any significant difference between centralized and distributed systems, which could be taken into account by the simulation.

Once more: If PVsyst applies a correction, it is because the data are not correct, or not correctly imported due to a time shift. This has implications on the calculations during the simulation, and should be corrected. The errors usually arise when importing POA measurements, and are due to the fact that if the retro-transposed Global or Beam horizontal values are higher than the clear day model (by a significant amount which is specified in the hidden parameters), PVsyst will limit it. This will arise either in morning or in evening hours, when the sun is low on the horizon (low sin(HSol) varying quickly with the time). With even little time shifts you can easily get Normal beam components of 3000 to 5000 W/m² at the sunrise or sunset. How PVsyst will manage this during the simulation ? However I don't understand well your assessment that you have differences with Ghi/Dhi, as in this case there are no calculations during the import. Except if for some hours your Diffuse part is greater than the global part: this doesn't make sense and the simulation will not understand that !!!

The backtracking strategy requires complex geometric calculations. In PVsyst, it is not developed for any situation. There are several limitations, for which I did not find the suitable algorithm. The backtracking is based on a given collector width and pitch between trackers. Therefore it is only defined for a set of trackers specified as one sub-field in the 3D geometry. These parameters cannot be different for different sub-fields in a same system (or the backtracking will be established on the less favourable sub-field). Single axis systems: - The backtracking works well with horizontal axis systems. - For tilted axis systems, it works well with usual configurations. But it cannot be defined if the azimuth of the axes within the sub-array is not null (i.e. if the trackers are shifted with respect to each other). However it is possible if the whole sub-array is not south-oriented (azimuth of the whole 3D object). - It is not possible to define backtracking between trackers of different altitudes, because you cannot (in the present time) specify an east-west slope for a tracking sub-field. - For Vertical axis, the backtracking is not implemented as I couldn't find an algorithm. Two-axis systems - For usual two-axis systems, there are several possible backtracking strategies. The only one implemented in PVsyst in the present time is by following the sun height: the azimuth is then adjusted for avoiding the neighbour tracker's shades. This strategy alone is not very efficient, especially at lower latitudes where the east-west sun position is preponderant. When the azimuth is big (east-west directions), the system should adopt another strategy: following the sun azimuth and applying the backtracking to the tilt. This is not implemented yet. The backtracking from one row to the next one would require to define the Tracker's nord-south pitch and shift (i.e. between 2 different rows), and would apply to the tracker's tilt. Moreover it would be correlated to the backtracking of the row (either in azimuth or in tilt). As for the previous case, I didn't find the algorithms for the general case, and this is not yet implemented in PVsyst. Therefore backtracking strategy is not really useable for two-axis systems. For Tracking frames, the backtracking is implemented between trackers within the frame, but not from frame to frame. If analytical or geometrical algorithms are too difficult, I will probably try to approach the problem by successive approximations in a future version.

There is no formal limit to the system size in PVsyst. However for very big systems (dozens of MW), the calculation time may be prohibitive, and even the management dialog of the system may become unworkable. There are several bottlenecks: - When near shadings are used: the calculation of the shading factor requires to compare basically each elementary surface to each table (goes with the square of the number of elements). Therefore you should define "tables" (areas for receiving a set of modules) as big as possible in order to limit their number. In the version 6 there is an optimization which may gain a factor of ten. Please check that for your simulation, this optimization is effectively active (in the 3D editor, menu "Tools" / "Optimized shading calculation" checked). - This calculation time for the shading factor is especially penalizing when establishing the shading factor table (prior the simulation) , which involves a calculation for 190 positions, and may spend several hours. - A significant time may also be due to the pre-calculations for the optimization of the shading factor calculation, or the check that each table should not interpenetrate any other table or objects. - When using "Module layout" for electrical mismatch effects, defining more than 1000-1500 modules becomes impraticable. And this results in very long simulation time. For very big systems, you should perform a simulation with Module Layout on a reasonable subsystem, which will give you an electrical loss value. Then you can use the simulation on the full system with the option "According to strings of modules", and adjust the "Fraction for electrical effect" in such a way that you get the same electrical loss. - With string inverters, the simulation is performed for each inverter input, which significantly increases the simulation time. We are working on the improvement of the calculation performances, by optimizing the algorithms. We will also develop a parallel calculation for a better use of multicore processors, which should be available soon.

The effect of the IAM on the diffuse component is calculated assuming an isotropic diffuse distribution. It results of the integral of the IAM loss over all directions of the sky "seen" by the PV module. As this value is independent of the sun's position, it is constant over the year, and applied to the diffuse component at each step of the simulation. The same stands for the Albedo component. NB: This integral is indeed performed simultaneously with the shading factors if horizon or near shadings are defined. Sorry, I discover that this part of the help is incomplete and rather old: I have updated it for the next version 6.26

The horizon is considered as significant only when some values overcome 2°.

The Report language remains indeed the current language, and doesn't obey the choice of the "Printer" dialog anymore. Thank you for pointing this out. We will investigate and correct this for the next version.

The PV module specifications include a VMax parameter, which is the maximum voltage (i.e. array voltage) of the system in which this module will be installed. As for the inverter, this maximum voltage is the absolute maximum in any conditions, i.e. the Voc under the lower temperature ever measured at this site (see How to adjust the design temperatures ?). Now this limit is usually different in the US (UL norms) and in the rest of the world (IEC norm). The US limit is probably due to the general 600 V limit for the class of usual electric systems. If you are in US and the module has an IEC limit of 1000 V, you can change this criteria in the project's definition parameters, button "Albedo and settings". However you have the risk to be not compliant with the US regulation.

The time reference in PVsyst is indeed the Legal time, i.e. UT + Timezone, and the time label is the beginning of the hour. But as with most solar software and meteo data, it doesn't take the DST (winter/summer time) into account. For most Meteo data, the Time Zone is fixed according to the Winter time. NB: If sometimes meteo data are not recorded exactly during a Legal hour - may be for example accumulated from 8:15 to 9:15 - then when importing these data into PVsyst you have to specify a "Time shift", which indicates that the solar geometry will not be computed at 8:30, but at 8:45 in this example (middle of the measurment recording interval). NB: for being compliant with some old research meteo data, PVsyst can also work in "Solar time", i.e. the time defined by the passage of the sun at south at Midday. This time definition is really not practical, and should never be used except for very special reasons.

You cannot identify peak values over 15 minutes interval, as PVsyst only performs simulations on 1-hour time step data. However an indirect way would be to identify the peak irradiance in your original 15-minute meteo data. As the output of a PV system (without Power limitation) is very linear with the input irradiance, you can calculate the ratio E_Grid/GlobInc for a similar hour in your hourly data, and appliy this ratio to the 15-minutes peak irradiance. NB: you can get a table of the maximum hourly values for each month and each hour of the day in the results "Tables" / "E_Grid hourly averages". Here you can choose Maximums instead of averages.

If the shade was very sharp (shading object very close), only a contribution of 3 cm width would affect the elecrtrical mismatch. The concerned cells are not completely shaded, and the shade contribution will be around 3 cm/15.6 cm, i.e about 20% of the full beam. Now the apparent diameter of the sun as seen from the earth is 0.54° (Sun's diameter is 1.4 Mkm, sun-earth distance is 150 Mkm). Therefore the shade of one point at 50 m will be a patch of about 50m * sin(0.54°) = 0.47 m. The shade of this 3 cm wire will be spread over around 50 cm width. This will cover several cells, and will not produce significant electrical mismatch losses. The shading effect will therefore be limited to the irradiance deficit, i.e. the "Linear shading" corresponding to 3 cm width obstruction. As a conclusion, at this distance you should use the "Thin object" option for this wire, but with a negligible contribution (1%, i.e. the minimum allowed in the program).

It seems that several people have developed their own techniques for using data from external drawing software. Few of them are publicly available. Here at PVsyst, we are on the way of developing the import of terrain drawings from AutoCAD, as well as the positioning of tables of modules on this terrain within PVsyst. This should be available within some few months. But we didn't yet study the possibility of a general import of full scenes or shading objects from AutoCAD.

We are on the way of developing the import of terrain drawings from AutoCAD, as well as the positioning of tables of modules on this terrain. This should be available in PVsyst within some few months.

When importing this module: The main problem in your definition is the number of cells in series. Of course a thin film module is made of cells, each cell being a long strip (usually 10 mm width). The one-diode model is applied to one cell (between 0.4 and 0.5V for CIS), which is the module voltage divided by the number of cells. If you apply the one-diode model to the full module voltage, it will obviously completely fail. The CIGS is very similar to the CIS technology. In PVsyst they are not distinguished. The negative temperature coefficient is due to your wrong number of cells. When defining the correct number of cells you will be able to correct for getting the specified muPmpp value. But the muVoc is not adjustable (see out FAQ How to adjust the Voc temperature coefficient ?. NB: the NOCT is not defined in the database of PVsyst (see the FAQ How to adjust the NOCT value ?.

There is a way of exchanging the PVsyst component data (Geographical sites, PV modules, Inverters, Batteries), with an EXCEL document in tabular form (one line for one component). The concerned file is named "Components.XLS", stored in the installation directory: c:\program files (x86)\PVsyst6\DataRO\PVsyst6_data\UserData When using (modifying) this file, you are advised to save it in your PVsyst data workspace: ...\User\Documents\PVsyst6_Data\UserData\ The procedure is fully explained in the Excel document, page "Help". Basically, if you select a whole line in the EXCEL document, you will get a button "Import from table" when opening a new component in PVsyst. Inversely, in the PVsyst definition dialog of these components, you have a buttin "Export to Table". In the component's list ("Database" part), you have also a button "Export", allowing the selection of several components at a time.

This is typically a time shift between the time definition of your data and the internal time of PVsyst. Please analyze your meteo file in "Meteo tables and graphs" / "Check Data quality". You have detailed explanations in the help "Geographical and Meteorological data > Hourly meteorological data > Hourly meteo data quality check" and " >....> Time shift".

The calculation involves curve approximations in some cases, and there may be some calculation artefact errors. Now 0.5 kW/800 kW represents 0.06% error. If this arises, say, 100 times in the year, this will represent 50 kWh. Your installation will probably produce around 1'000 MWh/year or more. Does really an error of 0.005 % affect your financial balance ? However I will analyze this situation when I will have some time.

No, there is no way for importing nor editing a shading factor table in the present time. The shading factor table is a result of PVsyt shading calculations, it doesn't make much sense to modify it explicitely.

Yes in principle the ZIP file contains the project *.PRJ, the meteo file *.MET, the variants *.VCi, and the components which are not present in the original database. Please check that your project contains indeed sohttp://forum.pvsyst.com/index.php?sid=9a56d2e74fa0a16b827fcf5adc6152afme saved calculation versions.

It depends where you are. In the US territories, you have some providers for recent data (SolarAnywhere). But for other places in the world, the only data I know are SolarGIS, 3Tiers, or perhaps Helioclim. These data are for pay. You can try also the meteorological service of your country.