-------
Up to version 7.2, the partition model has been implemented as an all or nothing model. Tables were split into partitions, i.e. PV areas that would be electrically affected by a shadow, via mismatch effects. Shaded partitions would produce power only up to the diffuse irradiance, and their direct irradiance contribution would be considered naught.
-------
Version 7.3 introduced the notion that if shades were small, then these mismatch shading losses would be mitigated. However the implementation was only well adapted to very regular arrays, with a single orientation. In other situations, the electrical shading losses were underestimated.
The following post details the possible issues with this particular model: https://forum.pvsyst.com/topic/3085-electrical-shading-losses-in-versions-73x/
-------
Version 7.4 takes the idea of small shading mitigation further, in that the shade on each PV table is evaluated to estimate whether or not the electrical shading losses will be mitigated or not. In this way, the cases that were not well treated in version 7.3 (underestimation in case of irregular shadings, or multiple orientations) are now handled properly.
In practice, the partition model in version 7.4 splits each partition into three areas:
In the case of regular shadings that affect an entire row of modules, this translates well into the notion that whenever a single cell per submodule is partially shaded, the production of the submodule is lowered proportionally to the shaded portion of the cell (current limitation in a string of cells in series).
More details on the model itself can be found here: https://www.pvsyst.com/help/near_shadings_partition.htm
For more details on how to configure that partition model in a PVsyst project, see this help page: https://www.pvsyst.com/help/shadings_partitioninstrings.htm
]]>
In the layers list, make Snapshot layer invisible and Terrain layer visible :
Right click on the ground image and select Unlock then Explode
]]>
• Open Sketchup Pro
• Click on File>Import and select an Autocad .DWG file
• Click on File>Export>3D model
• Select Collada (*.DAE) and save your file.
• In PVsyst 3D scene, from the menu File>Import>Import a 3D scene (3DS, DAE,PVC), select and import your file .DAE file
• Open Google Earth Pro (this software is free even if it’s called “Pro”)
• From the menu Tools>Options>Navigation, check Do not automatically tilt while zooming (in order to be always in a perpendicular top view from the ground)
• Select a location by setting an address or by scrolling with the mouse
• Click on the Path tool and draw as many points as possible with the mouse to define the desired area (the polygon tool will only generate the elevation data for the polygon’s corners, it’s not sufficient to extract the topography of the polygon area)
• On Altitude tab, select Ground level
]]>
The backtracking orientation calculation is based on the geometry of a pair of trackers , i.e. the distance p between trackers, and the width w of each tracker.
These 2 variables are supposed to be equivalent from tracker to tracker, i.e. only valid for perfectly regular arrays. If it is not the case PVsyst will calculate the backtracking for the less favourable pair of trackers, and this calculation may not be optimal for more spaced pairs of trackers: these will beging to "backtrack" before it is necessary, resulting in orientation losses. Inversely if you have lower pitch, or altitude differences, you will necessary have mutual shadings.
In the present time, PVsyst doesn't calculate the backtracking for trackers at different altitudes. However even when we will implement this, the altitude differences will be necessarily the same for all trackers (i.e. the tracker array will be in a same flat E-W inclined plane).
Moreover, remember that in PVsyst, when using the tracking option the orientation of all trackers is identical at a given time.
On a Hill
Now on a hill, when the altitudes differences are different from tracker to tracker, it is physically impossible to define a "pure" backtracking strategy. If you calculate the backtracking Phi angle between the trackers A and B, it will be different than for the trackers B and C, so that the backtracking cannot be optimal for both pairs simultaneously: either you will have residual shades, or the "back"tracking will begin before it is necessary.
Some people propose a situation where all trackers take a different position: this leads to extremely complex calculations (the optimization of the Phi angle of each tracker should be performed simultaneously on all trackers for each sun's position) without ensuring a perfect solution. This optimization involves machine-learning techniques for a given installation. And the real gain may be questionable.
As far as we don't have a model for the implementation of such a strategy, we cannot envisage this development in PVsyst in a previsible future.
Moreover on the field, you should also wonder how you will physically implement such Backtracking control in your installation.
Workaround / only way on a hill: give up the backtracking strategy.
Please remember that basically the mutual shadings and "true" backtracking give very close irradiance results, as you intercept the same light tube. What you loose as shading losses in the first case will be lost as mis-orientation and IAM losses in the second case. See Which gain can I expect from backtracking strategy?
Only the electrical mismatch shading losses give a significant advantage to the backtracking.
The mutual shadings are quite correctly calculated by PVsyst with trackers on a hill. A not perfect backtracking will loose either by unexpected mutual shades, and by "early-back"tracking (leaving some sun rays unintercepted between trackers).
So on a hill, there is no definitive solution. You have to simulate both situations (with and without backtracking) and chose the best result.
]]>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.
]]>In particular, it will check that you have defined a sufficient active area (3D fields) in the 3D scene for positioning all modules defined in the "System" part (Subarrays area = sum of the areas of all modules).
You can define a greater area in the 3D scene, as your modules may not be completely jointive, but not a smaller one.
The match should be satisfied for each orientation.
This screen shows the effective areas defined in the System and the shadings part. If you need more details you can find them with the button "System Overview".
]]>In the present time, the PVsyst algorithm is quite insufficient, and you are not advised to use it. It only performs the backtracking in azimuth (with tilt set according to the sun's height), and without going to the "north", i.e. blocking the azimuth to values < 90°.
When the sun goes to higher azimuths, the backtracking should switch to a backtracing in tilt (i.e. the next tracker sees "above" the preceding one). This is not done in PVsyst as we could not find a suited analytical algorithm.
At this stage, one of the problems is: when should the system switch between the azimuth and the tilt strategy? This will induce a discontinuity on the tracking orientation: at a given time, the trackers will suddenly pass from an orientation to another one.
With such a behavior, the system should come back to the Azimuth strategy (at values higher than 90°) symmetrically with respect to azimuth = 90° (West or East).
Now a second problem arises with multi-rows arrays. In this case we should also implement the backtracking between 2 rows (one behind the other), which even may have a shift in E-W direction. Mixing this with the E-W BT strategy becomes a diabolic problem.
We don't see any way of modelling all these behaviours analytically. The only solution would be to implement an ajustment by trys-and-errors, which may become time consuming during the simulation. We did not yet develop such an algorithm in PVsyst up to now.
]]>Now in shading situations, you should put the strips perpendicularly to the potential shades. In this way the shades will affect all the cells of each module in the same way, so that there is no electrical mismatch.
Therefore the "Linear shadings" are representative. With thin film modules you should not use the "Partition in Module strings" nor the "Module Layout" options when calculating shading losses.
By the way thin film modules usually don't have internal by-pass diodes (no submodules), there is only one diode for the full module.
NB: The strips may be along the little or the longer side. This information is not included in the database of PVsyst, you have to refer to the datasheets.
This is important for deciding if you put your modules in portrait or in landscape.
]]>However these trackers have the constraint of having the same tracking parameters (i.e. same axis orientation, same tracking limits, etc).
PVsyst will compute the irradiance equally for each tracker (the orientation of all trackers is the same at a given time).
Backtracking with not regular systems
Now the backtracking strategy is closely related to the relative position between trackers.
In PVsyst, you can define it only if you have a set of at least 2 trackers (within a same tracking object) for calculating the backtracking angle with respect to the tracker's width and the pitch.
If you have uneven disposition (different pitches and/or altitudes), this backtracking angle will not be valid for the other trackers.
Therefore in this situation - and for the restriction of a same orientation for each tracker - the backtracking strategy doesn't make sense. A "normal" tracking system with mutual shadings will usually have better performances.
Backtracking calculation limitations
The backtracking calculations are a complex geometric calculation. Up to now we have only elaborated the algorithm for specific cases.
- With Tilted axis systems, the trackers should be organized in a "rectangular" way (i.e. no shift of one tracher with respect to its neighbour), and at the same altitude.
- With Vertical axis, we have not found the right algorithm up to now.
- With 2-axis trackers, the algorithm only acts on the azimuth backtracking. In this configuration there are several possible backtracking strategies, we have not implemented them up to now.
- The backtracking is correct within the tracking frames, but not from frame to frame.
]]>In the 3D scene definitions, you have 2 ways of defining the axis azimuth:
1. - Either you define the axis orientation in the tracking parameters. In this case the orientation will be defined within the tracker's set object, and you will obtain trackers "shifted" with respect to each others.
2. - Or you define Axis Azimut = 0° in the tracking parameters, and you will have a correct "rectangular" disposition of your trackers within the Trackers set object. Now when including this object in the global scene, you can give an azimuth to this Tracker's object, and finally you will get a tracking axis azimuth with respect to the geographic coordinates.
The azimuth specified in the "Orientation" part is indeed the axis orientation within the tracker's object (tracking parameters), it will be not null in the first case and null in the second case.
The report will mention the final azimuth, with respect to the Geographic coordinates.
NB: the backtracking results of a complex analytic calculation. We established the algorithm for the second case, but we couldn't find a satisfying one for the first case. Therefore the Backtracking is forbidden for the first case.
]]>Average orientation
Therefore, when you distribute your tables on a hill, each table will have its own orientation depending on the slope of its basis, so that you will have a distribution of orientations.
This may result in an error "You have defined fields with XX different orientations, you cannot define more than 8".
You can analyze this distribution and modify the tables that are attributed to each orientation group in the menu of the 3D scene, "Tools > Orientations Management".
For such a situation, PVsyst will use the average orientation of the distribution in each orientation group for the transposition step in the simulation.
When importing or creating a 3D model with non-uniform table orientations, PVsyst will automatically create the orientation groups according to a limit discriminating angle. This limit is specified for your project, using the button "Project's settings" ("Albedo & Settings" in older PVsyst versions), in the tab "Other limitations". For automatically getting one only average orientation, you can increase this limit, at the price of a slight loss of accuracy in the transposition calculation. If the automatic grouping of orientations is not satisfying, you can manually adjust the attribution of tables to the groups as described above.
Several Average orientations
If you decide to group the tables in several average orientations in order to have more accuracy in the transposition calculation, you should keep in mind, that in the 'System' part of PVsyst the sub-arrays are linked to a single orientation. You therefore need to make sure, that splitting the tables into several orientation groups should stay compatible with the sub-array organization of the PV system you are designing.
]]>Pnom [kWp] = Coll. Area [m2] * Effic at STC [%] / 100
Now the Utilization Factor UF (= Acoll / Aground), which is the inverse of the Ground Coverage Ratio (GCR), is calculated according to:
Utilization Factor
We can notice that the more relevant parameter is the collector tilt: with 30° tilt you can install only 40-50% of the available ground area, when with 4° or less you can install more than 80% of your ground area.
This is very weakly dependent on your limit angle.
UF as function of collector tilt
Therefore when the area is limited, you are always advised to put your collectors as horizontal as possible (with the only limit of the soiling problems).
Moreover, this results in much simpler support's mechanics, less wind sensitivity, lower weight, etc.
This allows also to define higher shed's width, i.e. more strings in the width of the shed. This drastically limits the electrical shadings losses.
In most cases, taking the shading effects into account, the overall energy loss will be less than 2-3% with respect to 20-30° sheds.
]]>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.
]]>Let's call submodule the set of cells protected by one by-pass diode. In most modules (60 or 72 cells), there are 3 by-pass diodes and therefore 3 "sub-modules", usually disposed in length within the module.
Let's suppose that the modules are disposed in landscape, and all modules of the bottom row belong to the same string.
Now it is often believed that when the bottom cell row is shaded, the by-pass diodes will limit the electrical loss to the sub-module row, i.e. the string electrical production will remain 2/3 of the normal production.
This is only true (about) if you have one only string per MPPT (violet curve).
If you have more than 2 strings in parallel, the electrical shading factor is shown on the next figure: this shows that as soon as 1/3 of the sub-modules are affected by the shade, the electrical loss is 100%!
Electrical shading factor according to the number of shaded submodules in a string
(this plot may be constructed point by point using "Tools" /"Electrical behaviour of PV arrays")
Therefore in rows arrangements, the protection diode don't recover any electrical loss: the full string width (module with) should be considered as electrically inactive as soon as the bottom cell is shaded. With the calculation "according to string" in the 3D model, this means that with row systems the Fraction for electrical loss should always be set to 100%. With "Unlimited sheds", the width of the full string should be considered.
The next figures show how the I/V curves are affected: the first shows a not-shaded string
One only string without shadings
and when 1/3 of sub-modules are shaded: we loose in voltage, but the current remains the same.
If the string is alone in the array, the Pmpp loss is proportionnal to the number of shaded sub-modules.
One string with 1/3 submodules shaded
Now when there are other strings in parallel, the MPP is chosen on the resultant I/V curve, and the voltage Vmpp is the same for all strings: for the shaded string, only the diffuse contributes !
1/3 shaded string in a 3-strings array
]]>On the one hand the positioning and attribution of all modules in the system may be tedious, and on the other hand the calculation time of the simulation will become prohibitive.
PVsyst advises a "reasonable" limit of 1 MW, and prevents to develop the ModuleLayout option for systems upper to 5 MW. However you can modify this limit in the Hidden parameters, topic "System Design Parameters, losses, shadings", item "Power limit for Module Layout error".
If you have a very big system, you are advised to perform your shading studies with the module layout option on a reduced representative part of your system.
This will give namely an electrical shading loss reference result.
After that, you can perform the calculation on the full system using the shading option "according to module strings", which is easy to define and fast.
This will give you another estimation of the electrical loss. With "Fraction for electrical losses" = 100%, this should represent an upper limit to this loss.
Finally, comparing with the loss obtained with your reduced system, you can adjust a realistic value for the "Fraction for electrical losses" parameter, in order to get the same relative loss.
With sheds (row) arrangement, the "Fraction for electrical losses" is usually 100%, even with by-pass diodes; because as soon as 30% of the submodules are shaded, the concerned string doesn't produce any more for beam component. See How to evaluate the effect of by-pass diodes in shaded arrays?
Therefore both calculations should give give close electrical shading loss results.
]]>The area is defined as the gross size of the module: Length x Width. Except with tile-modules, where this is may be defined as the apparent area.
This is the reference surface for the determination of the efficiency.
Now in the PV module you can also define the area of the cells (sensitive area): this is only used for the evaluation of the cell's efficiency, i.e. a characteristics of the PV module technology.
The simulation uses the rough area of the modules for the evaluation of the efficiency.
In the 3D shading part:
In a first step, the areas are defined independtly of the modules: these are generic surfaces which may receive the installation of modules, whatever their size, disposition, and spacing between them. The shading factor calculation is not very sensitive to the real area.
These plane areas may (should) be over-sized in order to be sufficient for receiving the modules. When you exit the 3D editor, PVsyst will check that you have defined sufficient room for placing the modules defined in the System part. This should not be less than the total modules area, but may be largely oversized.
In a final step (in the future version 6) the layout of the modules will have to be fully defined on these surfaces, in order to compute the electrical effects of the shadings.
After this definition the 3D areas will be readjusted to the real position of the modules and their eventual spacing.
]]>On the other hand, the shading calculation time in PVsyst is strongly dependent on the number of elementary surfaces defined in the scene. As in drawing software this is not a limitation, people create complex scenes with many realistic details, not relevant for the shading calculations. We have to find some algorithms for analysing and suppressing the useless elements. This is a complex task.
We are now on the way of developing the import of Sketchup drawings. This should be available within a few months.
But the import of Autocad *.DWG files is not possible in the present time. We are studying the possibility of importing some specific objects like terrain descriptions, or 2D roof layouts (chimneys, technical elements).
]]>You can easily import the SunEye data (file "ObstructionElevations.CSV") in PVsyst, option "Horizon", button "Read/Import".
Please be aware that the SunEye results are only useable for defining far shadings (i.e. an horizon line). Shading obstacles are considered as "far" when at a given time the full array may be considered shaded or not: the sun is or is not present on the array. As an order of magnitude, when the obstacle is at a distance of, say, 10 times the array size.
For near obstacles - which produce partial shades - you must use the "Near shadings" option, i.e. create a 3D representation of your PV field and its environmnet. The SunEye data are completely unuseable for this.
NB: Solmetrics had established a specific file for use in PVsyst. Please don't use this file, which was developed for verion 4 and is not satisfactory.
]]>In the years 1990 we had passed a full-day seminar on this question with all involved people in Switzerland (including the Meteonorm team), and did not find any satisfactory solution. With our mountains, meteo measurements in Switzerland are especially concerned with this question of course !
With any ground-measured data, the horizon loss of irradiance is already included in the meteo data.
This is very difficult to use because:
- the horizon line is very sensitive to the exact location: the horizon at the exact sensor position may be very different of the horizon seen by the PV system.
- if applied to monthly values, the synthetic generation doesn't "know" the horizon, and will generate values with beam component below the horizon. Which will be incorrect in the simulation of course.
Therefore in any case (except on-site meteo measurements), the horizon data should ideally be horizon-free and the horizon effect should be computed within PVsyst, using the effective horizon line of the site.
There is no simple mean for avoiding the problem.
With monthly values, we could generate a full year of hourly values, evaluate the loss (on beam) due to the pre-specified horizon of the site, and then add these losses to the monthly original values and re-generate a synthetic hourly file. This file will have better "free horizon" values on which we can apply the real horizon of the PV system.
With hourly values, we should reconstruct the supposed beam component below (and behind) the horizon. We have now models for doing this with some confidence (probabilistic continuity of the weather).
We have tested these methods, and they can give acceptable results. But sorry, I did not yet implement this special case in PVsyst.
]]>PVsyst provides a pedagogic tool for the understanding of the performances as function of plane tilt and row pitch (for a given limit shading angle): in the "Orientation" part, choose "Unlimited sheds" / "Show optimization". The graph shows the annual yield (by respect to horizontal) for unshaded plane (in green) and shaded system (irradiance or electrical effect).
This tool clearly shows that the optimal tilt angle for unshaded plane is significantly reduced when considering the shaded performances.
And this becomes dramatically worse when considering sheds not well oriented toward the south.
Further, the power which can be installed on a given area decreases when the tilt increases. With 30° collector tilt, you can in general not put more collectors area than 45-50% of the available area. With low tilt angles (around 3°), this increases to 80% or more.
The mechanical structures are much more simple with low tilts (reduced wind sensitivity).
But the low tilts may induce cleaning problems with rain. You are advised to use frameless modules.
NB: for the final optimization of your system, you are advised to perform the full hourly simulation and vary the parameters.
You can easily do that by using the "Batch mode" (version 6 only).
]]>When you tilt the baseline of a collector (rotating around the azimuth line), the plane "true" orientation will change.
For understanding this: please take a cardboard as collector, and position it at, say, 30°south.
Then give a tilt to the base (baseline slope). Now the plane azimuth is defined as the perpendicular to the intersection of your cardboard and the horizontal plane.
And the plane tilt is the tilt accounted perpendiculary to this horizontal line (i.e. the angle between the plane of your cardboard and the horizontal plane)
At the limit of a vertical base line, the azimuth will be (90°-plane tilt) (by respect to original Azimuth if not south).
The calculation of these new orientation angles is not straightforward: it implies 3D rotations matrices. But you can trust the proposition of PVsyst...
This arises on a roof when the tables are set perpendicularly to the slope, and also when you put tables on a sloped terrain (hill).
In the case of a hill, you have usually many different slopes, and PVsyst performs an average for the incident irradiance calculation.
You have a detailed tool for analyzing this situation in the 3D shadings editor, menu "Tools > Edit orientations".
]]>3D shadings calculation
In the 3D tool of old versions, the calculation of the shading factor went with the square of the number of elements; the elaboration time of the shading factor table becomes prohibitive above some few tausends of elements.
In the version 6, this calculation has been optimized, with a gain of up to a factor of 10 in speed. For using this feature, make sure that in the menu of the 3D editor, the option "Tools" / "Optimized shading calculation" is checked. Since then Version 6.6, this calculation uses the "OpenGL" tool, and this is no more a problem.
In your 3-D shading scene, you should not define one rectangle for each PV module. This is not the right way.
The "tables" (sheds or rectangles) of PVsyst are generic surfaces, intended for receiving a set of PV modules. You are advised to define each table as big as possible according to the constraints of your configuration. For example, when you have side-by-side sheds, you can define a big one instead.
Calculation on partial systems
NB: Since V 6.44, it is possible to specify a representative sub-part of the system (for example the input of one only inverter), and during the simulation the shading calculation will only be performed on this sub-system, but applied to the full system.
This concerns the "Linear shadings calculation", and the calculation "According to modules strings". This tool doesn't apply to the "Module layout" calculation. However this is no more really useful as the normal calculation is sufficiently fast now, event with very big systems.
Advice: with very big power plants, if the configuration is regular (i.e. with flat ground) you are advised to perform your first simulations (for optimization purpose) using the generic option "Unlimited sheds" in the "Orientation" part. In this case you don't have to define a 3D shadings scene, and the calculation will be straightforward.
This is for example useful for optimization analysis of the row-to-row distance and shed tilt
Module Layout calculation
The detailed calculation of the electrical effect according to the Module layout option is also very time-consuming, without possible optimization.
This option is not suited for very big system.
For multi-MW systems, you should evaluate the electrical shading loss with the "ModuleLayout" option using a part of the system (say - one inverter, i.e. one MW) and extend this to the whole system.
Since version 6.67, PVsyst puts a warning for systems over 1 MW, and prevents the definitions of ModuleLayout for systems bigger than 5 MW. This upper limit may be increased in the hidden parameters, topic "System design parameters, losses, shadings".
For evaluating the electrical shading loss in bigger systems, you should:
- Define a variant with a representative sub-system of your full big system (for example a sub-array connected to one central inverter, i.e. around 1 MWp).
- Define the "Module Layout" for this sub-system, and perform the simulation. You will get an electrical shading loss value.
- Recaclulate the Electrical losses with the option "According to Module strings" for this sub-system, with "Fraction for electrical effect" = 100%.
- Comparing the results for electrical loss will allow to estimate a "Fraction for electrical effect" leading to a same loss value.
- You can now define the option "According to Module strings" for the whole system, and apply this new "Fraction for electrical effect".
]]>- The shading loss due to the irradiance deficit on the modules (optical loss), which we call "Linear shadings". The shading factor is the ratio of the effective shaded area with respect to the total field area.
- The Electrical losses, i.e. the effect of the partial shadings on the electrical response of your PV array. The calculation requires to define the position of each module, and specify its electrical connexion on the inverter input, in order to combine each I/V curve of each sub-module. This is done in the "Module Layout" part. The electrical loss will appear in the Array losses on the loss diagram.
- Simplified Electrical losses, which we called shadings "according to module strings": this is intended to the evaluation of the maximum electrical effect on the array production, in a simplified and approximate way. Remember that in a string, the poorer cell determines the current of the whole string. That is, when one cell is shaded, the entire string is affected, and is supposed to become almost inefficient (for the beam component). Therefore in this mode, the array is partitioned into rectangles, each rectangle representing (approximately) the area of a full string of modules (to be defined within the shading scene, icon on the left). Then, when a part of this rectangle is shaded, the whole rectangle is considered inactive.
The Global Shading factor is the ratio of the shaded rectangles (grey + yellow) to the total field area. The additional loss represented by the yellow parts (Global - Linear shading factor) gives indeed an evaluation of the upper limit for the electrical loss.
Now some part of the string energy is recovered by the by-pass diodes (see How to evaluate the effect of by-pass diodes in shaded arrays?). This is the reason why we have defined the "Fraction for relectrical effect". However when about one third of "sub-modules" in a string are shaded (as for example in rows arrangement), the output for beam irradiance becomes almost null, and this fraction will be near to 100%.
This evaluation of electrical losses "according to modules strings" was the only way of estimating the electrical losses up to the version 5.
It should still be used with very big systems, when the "Module layout" becomes impracticable due to calculation time. In this case you can evaluate the "Fraction for electrical effect" by comparing the "real" electrical loss calculated by the Module Layout on a reduced sample of your system, to the calculation "according to module strings". And apply this last calculation to the full system.
]]>In version 5:
The version 5 calculation cannot give a reliable value for this "Fraction for electrical effect" parameter. This is dependent on the shades distribution on the field and the electrical array configuration. For a shed arrangement (where the shades are very "regular" and several sub-modules are shaded), it is near to 100%, because as soon as 1/3 of its sub-modules are shaded, a string doesn't participate to the electrical production anymore. When with more "distributed" shades like Chimneys, far buildings, it could probably be of the order of 60 to 80%, depending on the "regularity" of the shade (a diagonal-like shade has a lower impact as it concerns modules better distributed in the array).
In version 6
The realistic calculation of the electrical effect of shadings implies the exact positioning of each module on the geometrical plane, using the "Module Layout" tool, the identification of each electrical string in the array.
Coupled to the shading calculation, the "Module layout" tool evaluates the real I/V curve of the PV array (on one MPPT input), and provides a realistic evaluation of the loss due to the electrical mismatch.
Now comparing the Electrical loss calculated by this "Module layout" option, and the "Electrical loss" evaluated by the approximated shading mode "according to module strings", you will be able to establish the "Fraction for electrical effect" to be applied in order to match the Module Layout calculation.
As an example, if you get 4% electrical loss from the option "according to module strings", and 3% with the Module Layout, the fraction for electrical loss will be 75%.
]]>