André Mermoud

Importing Sketchup or AutoCAD files (in .DAE or .3DS formats) is now possible since the version 6.60. See the help "Project design > Shadings > Near Shadings: Import > Sketchup and other CAD software"

PVsyst is oriented towards PV systems. It doesn't involve a complex building model for the evaluation of the PV modules temperature, which would require a lot of additional paramewter. However you can import the Array (cell) Temperature in hourly values along with the Meteo data (CSV hourly file). You can therefore create a representative temperature time series using your own models - synchronized with your weather data - in MS EXCEL, for using during the simulation.

With Helios3D scenes on hills, the baseline slope induces an orientation distribution of each table. In this case PVsyst uses an average orientation. See our FAQ "With my installation on a terrain, I have multiple orientations".

In the present time, PVsyst can work with one average orientation. We are preparing (for very soon) the opportunity of defining several average orientations, with tools for the attribution of tables to one or the other orientation. Now please observe that the orientation (and its averaging) only affects the transposition result. A reasonable mis-orientation or dispersion around an average will not have a too big impact on the accuracy. The mutual shadings calculations (shading factors) are only based on the system geometrical configuration. They are taken correctly into account, even with orientation dispersions.

This would require a specific tool for each source of Meteo data, which are all different. For getting many of them, a manual manipulation (on the web) is often necessary. Very few offer an API for a direct import, and the use of such API is not yet implemented in PVsyst.

No sorry. There is no mobile license for PVsyst.

The wiring losses are basically calculated using the resistance Rwiring, which is the basic parameter used in the simulation (and stored as a parameters). Now PVsyst defines an equivalent value expressed as the percentage of the loss under STC conditions (i.e. PNom). This value is more convenient for a first approach of your system development, as the default value is well understandable and doesn't depend on the system nominal power. However in the last steps of your PVsyst system evaluation, you should calculate this Rwiring explicitly according to your real wiring conditions. NB: the specified percentage as function of the STC power will not be your final energy loss. See our FAQ Why the losses in the results are different than those specified ?

Yes, the principle is the same for PNom values different due to the temperature.

The "linear" shading loss is the result when using the first table. The second table is used for computing the Electrical loss (accounted in the Array losses), which results basically of a difference between the two tables. The Module layout tool - which is closely related to the inverter behavior - is indeed not available for Stand-alone systems in the present time.

In PVsyst, the shading losses are the result of a detailed calculation, involving your system configuration and the irradiance distribution. You cannot explicitly specify monthly values of course.

I don't understand what you are doing. A negative pitch doesn't make sense in the calculations. It is so unusual that we even not thought to forbid it in our error messages. By the way, you cannot use the backtracking strategy with a misalignment of the trackers. See the FAQ How is defined the Tracking Axis azimuth ?

I don't know. 15 kW/200MW represents 0.0075%. This may be a rounding error somewhere.

I have never seen that, and I can't reproduce it. This may indeed be related to a Windows setting (in "Internationalization"?) . - Does this arise with all projects ? - Does the date appear correctly in other dialogs (for example in "Tools > Meteo Tables and Graphs", box "Dates") ?

The reading of custom Horizon files is really very restricted. Only the first line may be a comment. The next lines should be values Azimuth; Height; We have indeed to modernize this reading for allowing a more flexible reading.

Sorry, the general treatment of tracking systems have not been developed in the "Tools" part, neither in the "Tables/graphs of Solar parameters" nor in "Monthly meteo computations".

You can convert these files by opening them in a new version (> V6.40), and save them using the option "File compatible with old versions" in the saving dialog. You can also ask the manufacturer for sending files in the old format.

Please check that you have also suppressed the bifacial system use in your other sub-array (LED switched OFF).

You should send your questions relative to errors at support@pvsyst.com

This was a beta-version. Please update to an official version.

This was in the V 6.61 only. It has been corrected in the version 6.62.

You can get a table of monthly values with any customized variable in "Results > Tables". Now adding custom variables on the monthly table of the main report is not yet possible, this is on our (very long) ToDo list.

Please see our FAQ How are managed the new "Twin modules" with half-cells ?

In PVsyst, the azimuth is defined as function of the geometric "true" North (or South) , i.e. parallel to a longitude line.

Sorry, this is not possible in PVsyst. I don't know if we will implement that for Tigo optimizers.

The new technology of "Twin half-cut cells" is more and more frequent on the market. These modules involve half-cells strings, mounted in the following way: Twin-module with half cells architecture Electrically, these modules are made of 2 strings of half-cells, mounted in parallel. In the PV modules definition, this should be defined as "Twin half-cells" layout, 60 (or 72) cells in series and 2 strings in parallel. One of the advantages waited from this configuration is an improvement in the mismatch under partial shadings. How can this new module configuration be taken into account in the PVsyst shading calculation ? First of all, we will only consider "regular" shading situations, when the shades affect all lower submodules at a time, i.e. mutual row shadings in sheds arrangement (portrait disposition, modules in portrait of one string on a same row). In this case as soon as the lower half-cell is shaded the lower submodule becomes completely inactive (for beam component), and the string current will be half the "normal" current (upper sub-module). This is the key point of the benefit of this configuration. This should be taken differently into account in the different ways PVsyst evaluates the electrical shadings: - In the "Unlimited sheds" 2D calculation, where the electrical shading loss is considered complete as soon as the first bottom cell is shaded, we can simply consider loosing half the module instead of the full module width. This option asks for the number of strings in the width of the row. We can simply double this value for twin modules (i.e. consider 2 rows for one module in portrait). This doesn't require any program modification and the calculation is correct. - In the calculation "according to module strings", the rectangle-string becomes inactive when the rectangle is hitten by a shade. In our case the halfmodule lower row behaves as a string: as soon as a part of it is shaded the half-modules doesn't produce anything more for the beam component. Therefore you can define the "rectangle-strings" size as half the size of the module. This is only true for one row of modules: in you have several rows (for example U-wiring), this is no more true and the situation becomes much more complex (with reduced gain on the losses). In the present time with normal modules, there is a correction for sheds arrangement: when the bottom cell is partially shaded, the remaining current should be proportional the the enlighted part of this bottom cell. In practice, PVsyst accounts for electrical shadings only when half the bottom cell is shaded (correct on an average over numerous situations). This correction becomes a little bit optimistic as it is applied on a cell which is half the size. - With the "Module layout" calculation, the calculation of the I/V curves becomes more complex. It has been fully implemented in the Version 7. Here there will be a tool for deeply understanding the real electrical effect of the partial shades. In the old versions (V 6.xx) the Twin modules are defined in the same way as usual modules in the ModuleLayout part (3 sub-modules in length). Therefore if you mount them as portrait, they will have slightly higher mismatch losses than the landscape. Cells temperature Now some people are wondering about the cell's temperature, and if it should be lowered in the model due to half the current in each sub-module. I can't imagine why, physically, the cell temperature should be lower than in normal PV modules. The current is half, but in half a cell. Therefore the current per cell area is the same. Now if you have scientific papers with reliable cell-temperature measurements (differential between normal and half-cut modules), please send them to me. Moreover I don't know the exact relation between the currents in the cells and the module temperature. This should be very low as to my understanding, the temperature elevation would be due to the power loss Rs * Ioper². Now Rs is around 0.3 ohm for a usual PV module, therefore the power loss is 24 W for Imp = 9A (and 6 W when operating at half-irradiance). If we assume an irradiance of 1000 W/m2, this module of 1.6 m2 will receive 1600 W, the current loss is 24/1600 = 1.5% of the irradiance, i.e. roughly a contribution of 1.5% to the U-value (and 0.75% under 500 W/m2). PVsyst desn't pretend to provide default U-values with this kind of accuracy. By the way, this Rs loss is already accounted in the thermal balance equation, as this equation accounts for the efficiency. Now if this is really the case, the benefit will probably be exactly the same in hot and cold climates, as the temperature correction wiil be added to the module temperature whatever the original temperature, and therefore lead to similar power differences.