André Mermoud

PVsyst is quite able to model the CIGS modules: you should choose the technology CIS (equivalent to CIGS). Now with these PHOTON data, the specified Number of cells is 88, which leads to a Vmpp value of 0.23 V/cell. This is far below the usual values for CIS technology, the module organization is probably 2 strings of 44 cells in series. When you change this in the "Size and technology" page, please also go to the "Model parameters", and click the default checkboxes for Rshunt and Rseries (=> resp. 80 and 0.373 ohm). Because when trying to adjust the model with the false number of cells in series, PVsyst has fixed erroneous default values for these parameters. NB: During my researchs about modelling, I measured a CIS module during 7 years (one measurement every 10 minutes), and it obeys "perfectly" to the one-diode model (the RMS difference between Measured and Modelled values was < 1%, for any irradiance and temperature conditions over several years).

Some answers, but you should also refer to the help. 1. In a row arrangement, when the bottom cell line is shaded, the concerned string doesn't produce any electricity anymore. The by-pass diodes don't help in this case. As soon as 1/3 of the sub-modules (modules parts protected by a diode) of a string are shaded, the string's voltage is not sufficient to participate to the array power. You can only have a little recovery if the string is alone on the MPPT input, but it may also be below the Vmpp threshold of the inverter. 2. For this reason the "Fraction for electrical effect" should indeed be set to 100% with shed arrangement. 3. The mismatch loss parameter has nothing to do with the shadings effects (see How to define the Mismatch Loss parameter?) 4. See our FAQ What is the "Shading loss according to module strings", and What is the "Fraction for electrical effect".

I can't understand that. When the simulation has been performed with success, you are directly led in the "Results" window, with several options. The main one being "Reports".

You should desable it in the option "Partition in module chains" (icon in the left of the 3D edition), button "Cancel Partition".

PVsyst puts limits to the monthly meteo data, for avoiding erroneous inputs. These limits are applied on the Clearness Index value (Kt) which is the ratio of the measured irradiation to the extraterrestrial one. Therefore Kt is a measure of the transmission of the atmosphere. The limits fixed in PVsyst are Kt = 0.12 (months with very covered conditions), and Kt = 0.82 (very sunny months) (0.8 in older versions). PVsyst also puts a limit to the monthly Diffuse/Global (D/G), established at 0.13 (very sunny days). Usually the values of "normal" meteo data - all over the world - never exceed these limits. However the meteo conditions for Chile are really exceptionnal, and sometimes overcome these limits. You can change them in the Hidden parameters, topic "Miscellaneous".

See our FAQ With my big power plant, the calculation time is prohibitive

The nuVco may either be the result of the one-diode model (and it depends itself on the temperature), or you can specify the value given by the manufacturer. See our FAQ How to adjust the Voc temperature coefficient ?

I will correct it for the next version 5.72

I don't know. I can't reproduce this problem. When puttin 1° for the azimuth, it appears correctly on the report.

This comes from nowhere: you can put its value to 0 if you want. The value given here is just a default for a usual value. This represents the cost of the capital in general. Even if you don't perform a loan, you perhaps would like that your inversted capital yields some annual profit. This is equivalent to an interest which would have been obtained if you had invested your capital on the market: perhaps you want to recover this and it should be included in the final price of the energy.

For the first table (null anywhere), you have defined a tracking system with backtracking strategy. By definition, this mode avoids any mutual shadings, so that the shading factor (on the beam component) is always zero. In this table the orientation of the trackers is adjusted for each position of the sun. However the shading effects on the diffuse will not be 0 (see our FAQ How is calculated the shading loss on diffuse with tracking ? The second table seems to be quite correct, corresponding to an obstacle at south of your system.

Your 2 fields are on the same orientation, therefore you don't need to define heterogeneous fields. In the "Orientation" part, you should simply choose "Fixed tilted plane". Then, choosing to define "PV planes in sheds" is quite correct in the 3D shading part. You can construct any number of "PV planes in sheds" objects in your system, provided that you have the same orientation and a sufficient area for putting all the modules you have defined. NB: When you choose "Heterogeneous fields", the 3D shading construction waits for 2 fields (or groups of fields) in 2 different orientations.

There is no limit, the calculating time will simply increase, perhaps becoming prohibitive. And this doesn't depend on the total Power of the system, but on the number of "tables" (elementary mecanical rectangles receiving PV modules). For a 5 MW plant and reasonable tables sizes, there should not be problems with the version 6, where the shading factor calculation has been optimized.

For the first problem of disposition: Putting modules in several orientations on a same shading object is really not easy to do, and we decided not to allow this. This is a relatively rare case, and it doesn't justify the big amount of development. However you can always redefine your planes as independent rectangular areas, for portrait and for landscape modules dispositions. For the area calculation error: I will check in the program For the third problem of deformation: This is only a display problem, the filed area itself is not affected. We will also check this for a next version. By the way we are just elaborating a tool for the direct positioning of modules during the 3D shading development stage. It will become possible to redefine the polygonal field as the envilope of the real modules, positioned by mouse.

The far shading losses are indeed depending on plane tilt. When the modules are at low tilt, the losses arise with a higher incident angle, and the loss applies to a lower beam irradiance amount (due to cosine effect). With a high tilt, the shades apply with a lower incidence angle, when the sun's rays are more perpendicular. For understanding this intuitively, you can take the exrtreme cases of an horizontal plane (which "sees" the horizon line quite marginally) and a vertical plane, which will be affected by low sun's height, when it should be very well irradiated.

Thank you for the suggestion. This is indeed on our ToDo list since a long time. But not at the top, sorry ... In the present time you can - export (copy/paste) the Tables of monthly values in EXCEL, with your chosen output values, and compare them in EXCEL. - use the "Batch Mode", which allows to perform several simulations with different parameters in one operation, and directly compare the results in EXCEL.

I am indeed preparing a multi-orientation option for the next version 6.13 of PVsyst (up to 8 different orientations). With a shading calculation specific for each orientation, without any angular restrictions between planes as previously. "I'm not a programming expert, but I would imagine that a small piece of code would be able to dissicate a 20 orientations project": I'm working on this implementation since more than 2 months. I can confirm that this is not "just a little bit of code". It is a very deep improvement, which involves namely many user dialog issues. It affects all parts of the software (orientation, system, shadings, module layout), and I'm really not sure that this will work perfectly just from the first issue.

The meteo data are the irradiance as measured at ground. They include the cloud losses of course... If you want to evaluate the cloud losses, you have to calculate the "Clear day" model ("Tools" / "Tables/Graphs of solar parameters") and do the difference.

I don't know what happens. Probably a corrupted file. Please check that in your project, the Project's site is well defined (with valid Monthly data). In versions before 6.12, some manipulation could lead to a corrupted project's site. Then, the project's site is used for the orientation optimization in the "Orentation" part. If corrupted, you have to destroy and recreate the project's file *.PRJ. This will not affect the calculation versions already constructed (with the same filename).

Sorry, it is not possible in the present time. Developing this possibility is on my ToDo list.

OK, I will check this in the program. But please admit that this will have a marginal effect...

In PVsyst the final yield is meant as the net energy delivered to the grid (produced - consumed). The not-operating loss (by night) is apparent on the loss diagram as parts of the transformer MV losses and the eventual auxiliaries loss (if arising by night). If we don't include them in the final yield, we should represent them as an input arrow representing an input gain drawn from the grid, which may be confusing. And still more confusing if we consider that these losses arise indeed during the full operating time (not only the night).

Sorry, this has not been completely managed in the PV module definition yet. These values should be used as default inputs for the Module Layout part. The submodule partition indicates how the submodules (sets of cells protected by one by pass diode) will be arranged. For example with a 72 (6 x 12) cells module: - "In length" means that the submodule is divided into 3 longitudinal bands of 2x12 cells, - "In width" means that the submodule is divided into 3 transverse parts of 6x4 cells, - "Mixed" would mean a crossed arrangement (for more diodes or cells). I will probably suppress this unprobable possibility. I will put a little drawing according to the user's choice. For a future version ...

Each point of the graph represents the production of one day. On the x-axis, you have the daily irradiation in the collector plane [kWh/m2/day] On the y-axis, you have the system's production [kWh/day] For Grid-connected systems, this is usually very linear (points below correspond to days with special losses like shadings or system unavailability). You have often a curvature in the upper part, corresponding to higher operating temperatures in summer. For Stand-alone or pumping systems, it is much more instructive: a plateau indicates that the storage is full: if the plateau is low (begins very early), your storage (battery or water tank) is not sufficient: for many days the production is limited by the full filling of the storage. A well-sized storage will give a little plateau in the upper part of the graph.

When you are in the project's definition dialog, you have a button "Albedo-Settings" Pushing this button you have the item "Limit overload loss for design". This defines the amount of overload energy you accept to loose over the year. The help is available from anywhere in the software, by typing F1 (or sometimes little orange questionmarks for more targeted answers).