0% found this document useful (0 votes)
165 views36 pages

PVSyst - Project Design-2

Uploaded by

jwaos
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
165 views36 pages

PVSyst - Project Design-2

Uploaded by

jwaos
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 36

Project design Page 37 of 174

A few tools are available in order to select objects in the 3D scene.

Basic object selection

The basic selection is made by left-clicking on one edge of the object. You can select more objects by pressing [Ctrl] and left-clicking on the other objects you want to add to selection.
Clicking on an empty area will reset selection.

Rectangle selection

This tool allows you to draw a rectangle on the scene and select/deselect objects which are either touched by the rectangle or completely inside it.
When you click on this button, the following menu pops up and allows you to choose what you wish to do.

Clicking on the button one more time will disable the drawing but keep your current selection.

Lasso selection

This tool allows you to draw a free shape on the scene and select/deselect objects which are either touched by the drawing or completely inside it.
When you click on this button, the following menu pops up and allows you to choose what you wish to do.

Clicking on the button one more time will disable the drawing but keep your current selection.

Objects list

You can select objects directly in the list and use [Ctrl] or [Shift] to select multiple objects.

Object positioning
Each shading object is built in it's own referential and then positioned in the global scene.

To position an object, use the button or the "Object -> Position in scene" menu item.
The corresponding keyboard shortcut is [Ctrl + B].

This will show the positioning dialog:

And it will also display the help tool for moving the object with the mouse directly in the scene:

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 38 of 174

The help tool allows you to move the object on one or two axes as shown in the images below:

Moving an object on one axis

Moving an object on two axes

Left click and drag to move the object

Positioning operations are greatly facilitated when using orthogonal views in order to drag the object more accurately in the scene.
From a mathematical point of view, parameters are defined in such a way that the object is first displaced in the main referential, then it is rotated by the given azimuth angle, and finally
tilted around the new OX' rotated axis.
This process is the same for positioning an elementary object in a "building" object.

Fine tuning
You can also use the arrow keys to move the object in the scene on two axes, depending on the current selected view.
You must combine the arrow key with [CTRL], [SHIFT] or both in order to move the object.

When moving an object either with the mouse or the arrow keys :
 pressing [CTRL] will move the object by 1 centimeter.
 pressing [SHIFT] will move the object by 10 centimeters.
 pressing [CTRL] + [SHIFT] will move the object by 1 meter.

Important notice
When positioning PV planes among other objects, please always leave a little space between the plane and the support surface. Indeed, shading calculations involve complex
calculations of intersections and reunions between 2D projections of these objects. Confused points (and also points confused with a surface) often cause problems to these routines, and
may sometimes lead to topological errors.
On the other hand, module shading calculations consider a rectangle as shaded as soon as one point is shaded. When confused with its support surface, the baseline of the PV plane is
calculated as shaded, and invalidates the lower rectangles.
In the shading scene, you can define groups of objects in order to select them more quickly or to modify them at the same time.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 39 of 174

In this sub-panel you can manage groups and objects.

Creation
Click on [New group] to create a group, specify its name and then select the objects you want to include in it via the windows which pops up. By default, objects currently selected in the
scene will be be selected in this window.

Right-click menu

If you right-click on a group in the tree, it will display the corresponding menu.
Here are the different options :
 Rename group: Allows you to change the name of the group
 Delete group: Deletes the group, this will not delete objects from the scene
 Clear group: Removes all objects in this group, this will not delete objects from the scene
 Insert objects ...: Opens a selection window in which you can select which objects must be added to the group
 Insert selected objects: Adds currently selected objects to the group
 Remove selected objects: Removes currently selected objects from the group
 Select all objects in group
 Modify all objects: Opens the Advanced selection dialog

Zones of tables : Define zones and fill them with PV tables


In the shading scene, you can define zones which will be filled with PV tables.
The zones only defined on the XOY plane as you draw them on the floor and the tables are placed dynamically on the scene.
The generated tables are placed depending on the objects they are located on, it means that if you draw a zone over a roof the tables will be placed on the roof itself, at the correct
altitude. You can also specify that you want the tables to tilt automatically according to the object they are located on.

Zones creation :

In order to create or edit zones, click on this button and the following panel will appear :

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 40 of 174

Click on the button one more time to hide the panel

Create a new rectangular zone :


This will create a new rectangular zone and allow you to define the upper-left corner and lower-right corner of the rectangle on the scene.

Create a new polygonal zone :


This will create a new polygonal zone and allow you to define new points by left-clicking on the scene.

Create a new free-drawing zone :


This will create a new zone and allow you to draw it by maintaining the mouse left button pressed and moving the mouse.

Right-click anywhere while drawing a zone to finish drawing. Once you finished drawing a polygonal or free-drawing zone, you can insert new points on existing segments (left-click) or
delete existing points (right-click).
When your new zone has been defined it will appear in the groups component and you will be able to delete it at any time. If PV tables have already been created in this zone, you will be
asked to choose if you want to keep them or not.

Selected zone parameters :

This button opens the Table field edition dialog in order to setup the parameters of the tables which will be generated by the zone.

Label : Defines a custom label for this zone


Azimuth : Orientation of generated tables
Pitch : Distance between the base of tables in two consecutive rows
Tables spacing : Distance between two consecutive tables on the same row
Align tables : Defines how the tables are aligned on each row
Distance from ground : This value defines the distance at which PV planes will be generated from the ground they lay on
Automatic tilt : Checking this will ignore the tilt parameter and tables will get the tilt from the surface they lay on
Automatic length : Checking this will ignore the length parameter and only generate one table per row, with its length extended to fit the zone

This button will fill the zone with the given parameters. It will remove the previously generated tables and generate new tables in the scene which will be linked to this zone.

This button will select all the tables that have been generated by this zone.

This button will allow you to add new tables on an existing row of tables. You will be able to add them at the left or right end of the row, or in a place where you previously deleted one of
the rows table.

This button will allow you to slide a row on its horizontal axis, in order to align it exactly as you wish. First click on this button, then move the mouse over an existing row, press the left
mouse button, drag the mouse until tables appear at the correct location, and finally release the mouse left button.
Warning : Any changes on rows will be lost if you generate the zone again.

Additional information:
You can only edit one zone at a time, which means you will need to click on the zone you want to edit in the scene in order to select it.
Modifications to a zone are stored in the history so you can easily Undo and Redo your actions.
Once tables are generated you can edit, delete, move or rotate them as you wish independently.

Creating exclusion areas


Use the following buttons to draw exclusion areas:

These areas will be applied as masks on the zones you drew and they will prevent tables from being placed here.
You will need to fill your zones again in order to take the masks into account.

Hand-drawing objects
The hand-drawing tool allows you to draw objects with the mouse directly in the scene.
This tool currently allows the drawing of the following objects :
 Triangle
 Parallelepiped
 House
 Tree
 Extruded polygon (by defining the 2D contour and the height)

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 41 of 174

 Rectangular PV table

Click on the following button to pop the object type selection menu up and choose the one you want to start drawing:
Then just follow the instructions shown in the tooltip for each object.

Conversion of fixed tables to trackers


You may want to convert fixed tables to trackers at some point in PVsyst for example if you imported a 3D scene which contained fixed tables, or also if you filled a zone with fixed tables.

First select the fixed tables you want to convert in the 3D scene:

Then click on the menu called "Create -> Convert fixed tables to trackers":

This will show a dialog asking you to specify which type of tracker you want to end up with as well as the tracking parameters:

Define everything as you wish and then click on OK. The selected tables will then be converted to trackers.

Shadows drawing
When the global scene is completed, you can have a look on the produced shadows for any given sun position, or any time in the year, by clicking on the speed-button "Shadow drawing".
Solar angles or time conditions may be easily modified to see the evolution during the year. After each parameter change, please click on the "Shadows drawing" button again for
updating the shadow computation.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 42 of 174

NB: This "Linear" shadow computation is a very complex process involving polygon intersection and union calculations, which sometimes may fail, giving erroneous results (i.e; part of
the field is over- or under-shaded). If the program can detect the failure through it's internal checks, it uses an alternative computing method by distributing a grid of points on the PV area,
and evaluating the shading state of each point. This second method is less precise, but leads always to reliable results.
To minimize such problems, please always position PV planes with a little gap between them and their support surface.
If you have defined a partition of your PV-field according to strings of modules, the partially shadowed string rectangles will also appear in yellow. The two shading factors will be
displayed, indicating the lower and upper limits for the shading's real effect.
You also have an animation of the shadows drawing over a whole day. This simultaneously draws the curve of the loss factor on the beam component, and calculates the overall daily
loss on beam component for a clear day.

Tip: Try the "View from sun direction" speed-button to deeply understand how the shadows are formed !

Observer's point of view


The tools for defining the point of view with the mouse are described in the Global scene building section.
To define it by setting values, the "Observer position" panel is available in the right panel and through the menu "View / Specify observer position".

Look at
These coordinates define the target the observer is looking at. When using the Zoom to fit tool, the target is relocated to the focused object.
When moving the point of view with the Pan tool, the target is also moved.

Look from
This is the actual position of the observer, defined by height and azimuth angles and a distance to target.
In orthogonal projection, the distance has no effect and is disabled.

Perspective / Orthogonal projection


Orthogonal projection is the default one, it is advised to use it when building the scene.
Perspective projection can be used to get a more realistic view of the scene, when generating the shadows video or in the report

Back to default view


Sets the observer position back to its default position and looking at the scene origin (0, 0, 0).

Near Shadings: Auto-save


An auto-save mechanism has been implemented in the shadings scene in order to prevent the loss of work if PVsyst crashes.

Here is how it works :


 one auto-save file is kept for each variant,
 it is saved every 5 minutes,
 the file is located in your current workspace Shadings folder, and is named "__auto__" followed by the current variant name,
 files are kept until you exit PVsyst after a clean run,
 files can be recovered by clicking on "File -> Read scene", they are listed with other scenes.

Sketchup and other CAD software


Since PVsyst version 6.60, it is possible to import shading scenes from other CAD software.

Allowed file formats


- DAE : The Collada file format can be exported from many CAD software as it is an open format. It is available as an export format in Sketchup free version.
- 3DS : Less used but still an export option in many tools
- PVC : PV Collada file, open-source format derived from DAE format to include data about the PV modules and tables

How to
In order to import such a file, use the menu "File / Import / Import a 3D scene (3DS, DAE, PVC)".
Once imported, the new objects will be integrated in the current scene. The import will not clear the scene like the Helios3D one.

After a successful import a dialog summarizing what was found in the imported file will appear.

Scene details
This panel sums up the number of imported objects, and their total numbers of vertices and faces.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 43 of 174

It also allows you to set the input unit in order to scale objects correctly in the PVsyst scene (currently always in meters).
When importing DAE files PVsyst will try to extract the unit from the file and set it automatically.

The import will be automatically translated to the origin (0,0,0) of the scene.You can however modify the translation parameters by unchecking 'Automatic' and by editing X, Y and Z.

There is an option to rotate all the imported objects by 180° around the origin (0,0,0) of the scene. This option is checked by default in the southern hemisphere and it is unchecked by
default in the northern hemisphere. But you can check or uncheck it as you need.

Importing PV fields
The second part of this dialog allows you to define the orientation options (upper part) and to pick up one or more materials used in the imported scene (bottom part), and convert the faces
which use them to PV fields in PVsyst. The bottom part will not appear if you imported a PVC file as PV information is already defined in the format.

For defining the orientation you now have two options:


- either PVsyst will use the longest edge of each PV table to define its orientation (default behaviour before PVsyst V7.4.2)
- either PVsyst will try to optimize the azimuth of the table when defining its orientation (default behaviour in PVsyst V7.4.2)

After selecting one or more materials the combobox will allow you to define which kind of PV field must be created in PVsyst after the import : fixed tables or trackers. If you select a tracker
type then you will be able to specify the tracking parameters to apply depending on the type.
This way it becomes really easy to import full PV scenes directly from other CAD software.

Import from Autodesk AutoCAD


Importing from AutoCAD requires an additional step because it can't export directly to DAE.
You can either export your scene to Sketchup first and then to DAE (recommended option), or you can use a tool provided by Autodesk and called FBX Converter (which can lead to
some issues, see below).

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 44 of 174

FBX Converter allows you to convert an FBX file generated from AutoCAD (and some other Autodesk products) to some other formats including DAE.
This way it is possible to import your scene in PVsyst. WARNING: Using FBX Converter can result in some objects being slightly misplaced in the resulting DAE file. If you use this
method, we recommend to carefully check the placement of objects and PV panels in the shadings scene of PVsyst after import.

Limitations
Because PVsyst is used to simulate the shadings on PV fields its performance is directly related to the complexity of the shading scene.
Importing very detailed scenes from Sketchup or any other software is possible but not recommended as it will make the calculation time grow exponentially.
PVsyst will not be able to simplify objects geometry but you can still :
- Delete useless objects from the scene
- Disable shadow casting for these objects in order to speed the calculations up
Anyway, even if PVsyst can now handle and display large scenes as it uses hardware acceleration, we recommend that you simplify your scenes before importing them in PVsyst.

Helios 3D - Ground Power plants


Helios 3D is a software for the design of ground-based power plants, able to import and use a terrain representation in the AutoCAD format.
There is a special link in Helios3D for exporting the plant data to the shading part of PVsyst, using a specific format (*.h2p files)
Then, if the plant is not too big, the full study of the plant can then be executed within PVsyst.
Helios3D representation
Helios 3D defines "Tables", which are mechanical structures receiving a set of PV modules (not individual modules). These tables may have inactive mechanical bands, which participate
to the mutual shadings.
Each table is defined with its nominal Azimuth and Tilt; but may also have a slope of its basis, following the terrain.
Please remember that when you tilt the basis of a table, the real orientation of the corresponding plane changes (see Base Slope).
Therefore Helios3D data result in a great number of elementary fields, with a spread of orientations (azimuths and tilts).
NB: When designing a PV plant in Helios3D, please be careful to let a little spacing between adjacent planes (say, at least 1 cm), as PVsyst doesn't accept the interpenetration - nor even
confused points - of other objects in the PV planes.
Orientation analyzing tool
This orientation spread is a main difference with the installations usually within PVsyst, which usually have well-defined plane orientations.
A specific orientation analyzing tool is shown at the reading of the helios3D scene, and is also available in the main menu "View" / "Plane orientation" when spread is effective in the 3D
scene.
According to the tilt, the "Base Slope" may induce an azimuth deviation of 2 to 3 times the Base Slope value (dependence shown on the tool), but without big effect on the tilt. Therefore
each table will have a different orientation. These orientation distributions are shown on the tool.
All the table definitions may also be stored in the clipboard for a further analysis in EXCEL.
This orientation spread doesn't affect the shading calculations.
But during the simulation, the incident irradiance will be calculated once for the average orientation, and applied to all tables in the same way, resulting in a (little) orientation loss. This
inaccuracy is not yet taken into account nor evaluated in the present version of PVsyst.

CSV Ground data


In the near shadings you can click on "File > Import > Import CSV ground data" in the menu to import a text file containing 3D coordinates of points.
Here is an example of content for the file you can import this way :

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 45 of 174

0 250.01 0.19
5.55 247.2 0
10.05 269.66 0.29
15.63 267.05 0.09
17.56 246.27 0.82

Each line must contain the coordinates for one point only, in the following order : X Y Z.
The unit is in meters (m), you should make sure that the origin point is near 0 or the generated ground will appear far from the scene origin. Anyway, you will be able to move it where you
want in the scene after it has been imported.
You can choose one of the following separators: [TAB] ; , [SPACE]
A ground object will be created as soon as at least three correct and distinct points are found in the file. A triangulation is automatically made in order to physically represent the ground.

PV Collada file format

The PV Collada file format has been created by the PVsyst team in collaboration with the PVCase team in order to provide an open-source exchange format to describe 3D PV scenes.
PV Collada files can be imported into PVsyst since version 7.0.

Format description
PV Collada files use the .PVC extension.

The format is based on the Collada 1.5 format (full specifications available on the Khronos group website).

Extension of the <mesh> tags


The <mesh> tags can contain an additional child element from the following ones :
 frame_parameters
 tracker_parameters
It must contain only one of these and not the two simultaneously.
Adding one of these tags to the mesh will define it as a PV mesh and each of its faces will be converted to such in PVsyst after the import.

<frame_parameters>
This element describes a fixed-tilt table, it must contain the following child elements :
 module_width : INTEGER type, millimeters, describes the width of a module contained in the table
 module_height : INTEGER type, millimeters, describes the height of a module contained in the table
 module_x_spacing : INTEGER type, millimeters, describes the horizontal spacing between modules contained in the table
 module_y_spacing : INTEGER type, millimeters, describes the vertical spacing between modules contained in the table
 module_manufacturer : STRING type, describes the name of the module manufacturer
 module_name : STRING type, describes the name of the module manufacturer

<tracker_parameters>
This element describes a tracker, it must contain the following child elements :
 module_width : INTEGER type, millimeters, describes the width of a module contained in the table
 module_height : INTEGER type, millimeters, describes the height of a module contained in the table
 module_x_spacing : INTEGER type, millimeters, describes the horizontal spacing between modules contained in the table
 module_y_spacing : INTEGER type, millimeters, describes the vertical spacing between modules contained in the table
 module_manufacturer : STRING type, describes the name of the module manufacturer
 module_name : STRING type, describes the name of the module manufacturer
 tracker_type : STRING type enumeration ("single_axis_trackers", "dual_axis_trackers"), describes the kind of trackers
 axis_vertices : this element must contain two child elements of type <float_array> with a length of 3, describing the global coordinates of the two axis points
 min_phi : INTEGER type (between -90 and 90), degrees, describes the minimum E-W tracking rotation angle
 max_phi : INTEGER type (between -90 and 90), degrees, describes the maximum E-W tracking rotation angle
 min_theta : INTEGER type (between -90 and 90), degrees, describes the minimum N-S tracking rotation angle
 max_theta : INTEGER type (between -90 and 90), degrees, describes the maximum N-S tracking rotation angle

Sample PVC files can be found in the "DataRO/PVsyst7.0_Data/Userdata" subfolder of the PVsyst installation folder.

Ground Image
In the near shadings 3D editor, you can use menu "File > Import > Import Ground Image" to import an image or a plan of the scene ground. This file must be in BMP or PNG format.
Importing a ground image helps to set position and dimension of the PV and shading objects when building the global scene. The user is responsible to provide the ground image. He can
use for example a Google Map in earth view of the PV system area.

Note that PVsyst is expecting a Ground Image captured in 2D and showing the ground at 90 degrees. Once imported in the PVsyst 3D editor, the Ground Image will be visible
only when top view is selected. Here is an example of Ground Image captured from Google Map:

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 46 of 174

Ground Image Control principles


The Ground Image Control dialog allows to transform the imported image to fit the shading scene position, orientation and scale. The available transformations are rotation, translation
and rescaling.
The image transformations are defined by drawing two points on the ground image and setting the distance between them. The first point, named X1, is the new ground image origin. The
second point, named X2, is on the X axis at a known distance of X1 and will define the new horizontal axis. Once applied, the transformation defined will:
1) Translate X1 to the shading scene origin
2) Rotate the ground image around X1 until the line defined by X1 and X2 becomes horizontal
3) Rescale the image to match the shading scene scale.

The drawing below is showing a ground image before the transformations are applied. The rectangle filled in light color represents the original ground image. Its size depends on the
original image size. The rectangle in dark color represents the ground image after the transformations defined by X1 and X2 are applied. The arrows are showing how X1 and X2 points will
be moved.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 47 of 174

Ground Image Control usage


A simple example showing how to use ground image is to import an image where a building roof is visible. The user set first the upper left corner of the building roof as origin (X1), then the
upper right corner as X2 and finally set the distance between X1 and X2. After the transformation is applied, the roof upper left corner is moved to shading scene origin, the roof upper
border becomes horizontal and the scale matches the shading scene grid. Now the user can easily add PV and shading objects on the roof.

Definition of ground image transformations:


The Ground Image control User Interface allows to easily set the points and distance between them:
1) The user first set the position of ground image origin (named X1) by moving the mouse and pressing its left button.
2) Once X1 position is set, the user set the position of second point on X axis (named X2) again by moving mouse and pressing its left button
3) Finally the distance between X1 and X2 is set by selecting the related edit box in Ground Image control dialog.

Note that you can use the 3D Editor zoom control to set X1 and X2 position with more precision.

It's also possible to move X1 and X2 using the arrow keys together with <Shift> and/or <Ctrl> key. You can change the point to move by selecting X1 or X2 related edit boxes.

Applying ground image transformations:


The transformations are applied to the ground image once the check box "Apply" is selected.
Disabling this check box allows to display back the original image and edit X1/X2 position and distance again.

Additional information:
The Ground Image edition panel is shown in the right panel when a ground image is currently being edited.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 48 of 174

The file used to import ground image will be copied in user workspace (in directory "Shadings") as soon as the user saves the shading scenes or his project.

Dialog overview
In PVsyst, there are several ways to select the objects of the shadings scene. A more complex selection can be made using the advanced selection dialog.
The advanced selection dialog can be opened from the shadings scene by clicking on the menu Tools -> List and management of objects.

In this dialog it is possible to search, filter, sort, select, edit and remove objects of the shadings scene. It is also possible to export in CSV format.

Searching
In order to search specific objects from your shadings scene, you can enter a specific text in the Search box:

The search is applied on the #, Type and Name columns. To clear the search, clear the content of the search box or left click on .

Filtering / Sorting
Each column can be filtered and sorted.

To filter a column, hover the mouse cursor over the desired column header and left click on the funnel that appears:

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 49 of 174

You can now filter the items you want in the pop-up window.
Note that it is possible to filter several columns at the same time.

To clear the filtering, left click on .

To sort a column, just left click on the desired column header. This will sort the column in ascending or descending order, and a sort symbol will appear on the column:

Selection

: Select all displayed objects.

: Unselect all objects.


You can also select / unselect the objects directly in the list, by left clicking on the objects while holding the CTRL key down.
When you close the advanced selection dialog, the selected objects will remain selected in the shadings scene.

Expand / Collapse

: Expand all objects.

: Collapse all objects.

Copy / Paste

: Copy all selected objects to clipboard.

: Paste from clipboard to selected objects. If no object is selected, the paste will be performed on objects with the same ID (#).

: Same as standard paste, but only applied to visible columns.


Pasting can also be done from an external spreadsheet program like Excel. In this case, be sure to copy the title line and have at least the 3 first columns #, Type and Name:

Edition / Deletion

: Opens the edition dialog for the selected object. A single object can also be edited by double clicking on it.

: Delete the selected objects.

: Undo.

: Redo.

Some fields are also editable, these are cells surrounded by a rectangle:

If several objects are selected, the edition will be applied in a grouped way to all the selected objects.

Columns edition
In order to gain in readability, it is possible to show / hide the columns:

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 50 of 174

: Select / Unselect columns to show. Also available by right clicking on the columns header. Note that your choice is saved for the next sessions.

: Show default columns.

Contextual menu
Some actions are accessible via a contextual menu by right-clicking on selected tree node(s):

CSV export
In order to use the data linked to the objects outside PVsyst, it is possible to export the displayed list in CSV format.

Click on , then paste (CTRL + V) in Excel or any other spreadsheet program.

Introduction
In PVsyst you can define and simulate projects without defining a shading scene, doing so will require you to define your fields orientation in the "Orientations" part of the variant editing
dialog.
But when you choose to define a shading scene, you have to match two things :
- the orientations defined in the variant "Orientations" part,
- the active PV area defined in the "System" part by the sub-arrays for each orientation.
If one of these two elements is not matching, PVsyst will not be able to run the simulation.

By default PVsyst will try to identify orientations automatically from your scene with a given tolerance, and limit it to 8 different orientations. But the shadings orientation tool allows you to
manually define your scene orientations, by grouping PV fields the way you want. It also gives you a lot of information about the current and expected PV areas and orientations in order to
match the variant definition.

In the following sections you'll also find three use cases :

- Checking the scene validity by analyzing the current definition


- Understanding how PVsyst behaves when you import a full scene from Helios3D
- Defining the orientations for a random complex scene

Dialog overview
The orientations management dialog can be opened from the shadings scene by clicking on the menu Tools -> Edit orientations or by pressing [SHIFT + CTRL + O].

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 51 of 174

General info
This panel shows information about the current validity state of your orientations definition.

Overview / Details
The Overview tab contains overall information about all current orientations in the shadings and in the system.
The Details tab shows the detailed list of all the fields linked to the currently selected orientation, it will not be accessible if no orientation has been explicitly selected in the Overview tab.

Analysis
This part shows orientations spread and values for several types of data, like plane orientations, deviation around average and azimtuh/tilt according to baseslope.
The average values are also computed and shown in the Analysis panel at the right.

System details
This tab contains a tree representing the current definition of orientations from the Variant part, it also show the sub-arrays linked to each orientation from the System part.
You can find detailed information about how your current definition matches the System one in the System match panel at the right, it gives information about each individual orientation
match.

Automatic identification
This panel contains a button to force PVsyst to identify orientations once again, by deleting any custom orientations and starting it all over again.
You can also change the tolerance parameter which will be used when matching fields with each other automatically. Read Automatic definition for more details.

Orientations
This panel is where you can add or remove current orientations, and where you can select an orientation to get its details.
Selecting one or more orientations will also select the related fields in the shadings scene.
Read Manual definition for more details.

Automatic identification
When defining PV fields in a shading scene, PVsyst will always try to identify their orientations automatically, grouping all similar fields into the same orientations.
This is the normal behaviour because the field properties give all the information needed to do so.
Problems arise when the fields are not created with a regular layout, for example when they follow the ground slope, meaning that there are too many different orientations.
When this happens, we need to either increase the grouping tolerance or find other ways to get realistic orientations.

Here is a list of situations and how PVsyst will behave :

Helios3D
Fields are grouped by their nominal tilts and azimuths, so their baseslope will not affect the way they are grouped.

Zones of tables
Fields are grouped within the same zone, and with other zones if they share the same tilt and azimuth definitions.

Random scene
The first field is considered as a reference, then PVsyst tries to match other fields and if they don't it defines a new orientation.

For all scenarios, PVsyst then computes an average tilt and azimuth for each orientation from its fields.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 52 of 174

This is the way orientations are defined automatically since PVsyst 6.64, but before that they were always defined using the "Random scene" algorithm which was not accurate enough
and could lead to very odd orientation definitions. Also, there were no averages computed afterwards, the orientation tilt and azimuth were the ones from the first reference field.

Warning messages will pop up if you try to open an old variant with newly identified orientations that differ from the stored ones, therefore creating an incompatibility between the variant
Orientation part and the shadings part. You can click on Yes and save your variant again to validate it again.

Manual definition
This section describes how to define orientations manually.

Clear / Delete an orientation


In order to define your orientations manually, you may need to clear things up before starting your definition.
To clear or delete an existing orientation, right-click on the orientation and choose the action you want to perform.

Add a new orientation


To add an orientation click on the corresponding button above the list, it will add a new empty orientation after the existing ones.

Create an orientation from a selection


You can create a new orientation from the fields which are currently selected in the shading scene.
To do so, right-click on the fields in the right panel of the shadings dialog and click on the following menu :

You can do the same for groups of fields and zones too :

Add fields to an existing orientation


There are two ways to add fields to an existing orientation, the first one is by using the following menu in the shading scene, like described for creation above :

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 53 of 174

The second way is to open the details of the orientations, in the orientations dialog, by selecting it and switching to the Details tab and clicking on this button.

It will show a new window asking you to pick the fields you want to add, please note that you will only be able to pick fields which have not been manually added to an orientation yet.

Removing fields from an orientation


From the Details tab of the orientation, select the fields you want to remove and right-click, then click on the following menu :

Changing the reference field


Changing an orientation's reference field will clear it and look for fields which match the reference field's plane. The tolerance of this match is the same as the automatic identification one,
and can be changed directly in the corresponding panel.
To set the new reference field, right-click on it in the Details tab and click on the following menu:

Matching the variant


In order to be able to perform a simulation with a shading scene, you need to make sure that the orientations defined in the shading scene match the ones defined by the variant.

Here are the elements which must match :


 number of orientations
 tilt and azimuth values
 active PV area

Also, each orientation defined in the variant must be linked to an electrical sub-array in the System part, or the simulation will not be possible.
You might get an error message explaining this in the shadings, but the only you will be able to fix it is in the System.
All the needed information to know if the scene matches the variant is available in the orientations management dialog, global information is given at the top and detailed information is
given in the System match panel at the right.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 54 of 174

Updating variant definition


Once you have built your scene, there may be some differences with what you defined first in the variant, for example if you defined fields following a ground slope.
There are many scenarios where this can happen and where you want to keep your definitions from shadings because you know they are correct.

You can update the variant orientations parameters by clicking on the following button in the System match panel :
It has the same function as the button which appears after you edited a scene.

Use case : Checking scene validity


In this use case, we're going to see how we can interpret the matching errors and get an orientations definition to match the variant one.

Variant definition

Two fixed orientations

One sub-array of 50m² linked to orientation #1

One sub-array of 50m² linked to orientation #2

Shadings definition

Two rectangular fields, one of 50m² and another of 160m²

One field is 20/25° (azim./tilt) and the other one is -70/15°

Interpretation and solution

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 55 of 174

We can see that the second orientation found in the shadings is marked with a red icon, when the first one is green. This means that it is not matching the system correctly and needs
some adjustments.
Let's open the System match panel :

It says that is just has no match in the System, which means that we have two solutions:
 update the System definition from here
 edit the field causing the error and change its tilt to 25°

We'll go for the second one and edit the field's parameters, now the orientations look like this:

The orientation #2 has now the correct tilt and azimuth definition but it is still marked as red, so we check the System match panel :

The error message is clear : the active PV area is too large in our shading scene, we need to decrease it until we get close to 49m².
After decreasing the field size, it's area is now 46.7m² and the orientations dialog shows this :

It is only showing a orange warning which means that this is not blocking for the simulation, the area is respecting the tolerance so it is possible to go on with it.
The orientation #1 area is really close to the System one so it is displayed in green and considered fully matching.

Conclusion
Depending on how you design your systems, you will sometimes need to consider the shadings definitions like the good ones and override the variant definitions. Or, you will follow the
error messages to get your shading scene to match the variant.
As long as you have no red error messages while checking the match, you will be able to perform the simulation.

Use case : Helios3D


As explained in Automatic identification, the way PVsyst defines orientations has changed significantly since version 6.64.
These changes greatly improved identification when working with Helios3D scenes, here is how.

PVsyst version 6.63 and lower


There were two scenarios for identifying orientations in a Helios3D scene :
 If the global spread of the fields normal vectors was over a given tolerance, the average was calculated and stored from all normal vectors of the scene.
This was leading to situations where PVsyst was considering only one average orientation when it should have had many, for example for scenes with a dome layout, or scene with
fields on different sides of a hill.
 If the global spread was not too high, PVsyst tried to match fields together starting with the first one as a reference. This was also leading to illogical orientations with inaccurate
averages, forcing users to increase tolerance until they only get one global orientations but still not appropriate.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 56 of 174

Since PVsyst 6.64


PVsyst now automatically groups the fields from their nominal orientation, which means that :
 fields with the same tilt and azimuth but with a different slope (because they follow the ground slope) will be grouped together
 domes will define two orientations, one for the front panels and one for the back panels
 the orientation tilt and azimuth values are the average of all the fields linked in it

The maximum number of orientations is still 8 which means that if your scene contains too many different orientations, some fields will remain not grouped and you won't be able to
perform the simulation.
But the new management tool allows you to group fields manually, so it is now possible to merge two groups of fields which have slightly different orientations in order to get 8 orientations
total.

Reopening old variants


If you worked on Helios3D projects with older versions, you will be able to open them again in the newer ones and their orientations definitions won't change which means that you should
get the exact same variant.
But if you import the H2P file once again in the shading scene, orientations will be different because the new algorithm will be used.

Use case : Complex PVsyst scene


In this use case, we're going to see how we can manually group fields together in a complex scene, after we imported it from a DAE file we built in Sketchup.
There are three distinct zones of fields placed on a hill, each zone has a unique nominal tilt/azimuth pair. All fields follow the terrain slope so their normal vectors are varying.

Variant definition
We define the three nominal orientations which we expect to get, they are the ones we defined when we created the scene in the other software.

We create three sub-arrays in the system, one linked to each orientation, and we set the expected area of each zone.

Shadings definition
Here is the scene after we imported it in PVsyst :

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 57 of 174

We can clearly see the three zones

This shows how fields follow the ground slope

Now let's open the orientations management window to see how they are grouped by default.

Interpretation and solution

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 58 of 174

We can see that fields are grouped automatically in 8 orientations with an angle tolerance of 1°, which is not want we want.
We could try to increase the tolerance but it would not be accurate and we have no guarantee that it would group fields perfectly in the end.
So we are going to define our three orientations manually.

Step 1 : Deleting orientations

We select each orientation and delete it until there is no automatic definition left.

Step 2 : Creating the three orientations

We will create the orientations directly from the shading scene selected objects, this way it will be easier to make sure that the good fields go in the good orientation.
Let's start with the first zone (azimuth = -90°), we select the fields using the lasso selection tool in the scene.

When the fields are selected, we right-click on one of them in the right-panel and select Create orientation from selection

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 59 of 174

And now the orientation appears in the management dialog :

We notice that it has the correct area and close but different tilt/azimuth, due to the average calculations.
Now we repeat it for the two other orientations and get this result :

We open the System match tab to confirm that orientations don't match due to the averages being a bit different.

We know that we have it all well defined, and we want to use these shadings definitions in the variant so we click on the button to update them.

Conclusion
The orientation definition is now over, we have a valid system and a valid shading scene so we are able to perform simulations.
In this example we knew the area of each zone so we created the System accordingly, but if you don't know them exactly just do the same and you will be warned at the end that areas
don't match.
Just go back to the System part to adjust it with the values given by the orientations dialog and everything will match.

Near shadings: Backtracking strategy


See also Near shadings: Tracking planes.

Mutual shadings
The layout of tracker arrays should be carefully optimized with respect to mutual shadings. Constraints are much more critical than for the sheds disposition, as a significant yield may be
expected even when the sun is very low on the horizon.
The mutual shading problem is accentuated by the electrical behavior of the strings under partial shadings. As for sheds arrangements, identical shadings appear simultaneously on each
tracker and may block the yield of many strings at a time.
Backtracking strategy
Backtracking is now a widely used strategy for tracking arrays: when the mutual shadings begin, the tracking angle does not follow the sun anymore, but it instead goes back (decreases)
so that no shading occurs.
Let's analyze the case of a simple Horizontal N/S axis system.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 60 of 174

Beginning of backtracking Backtracking situation: lower sun


Collectors perpendicular to sun profile angle Tracker tilt decreased

When the backtracking is activated, the collector plane is not perpendicular to the the sun profile angle anymore; we have a loss of irradiance, due to the cosine (or transposition) effect.

Backtracking angle calculation


The collector tilt angle is closely linked to the relative parameters between two neighboring rows of trackers.
In PVsyst, the tracking angle is computed at each time step for a reference definition of the collector width and pitch, or more exactly of the width/pitch ratio. This tracking angle is applied
identically to all trackers of the scene. If all the trackers of the arrays do not have an identical width/pitch ratio, the backtracking becomes inefficient:
- A lower pitch will induce mutual shadings, and therefore possible electrical shading losses,
- A higher pitch will start the back-tracking before it is necessary, therefore losing some irradiance via the cosine effect.
If you have an occasionally larger pitch between some similar arrays (e.g. passageways between groups), you will not have mutual shadings. However the backtracking is necessary for all
trackers, including the extremity ones, due to mutual shadings.
If you have adjacent arrays, and the trackers of both groups are staggered, you may have mutual shadings from one group to the other one in some seasons.
If you have height differences between trackers, a "pure" backtracking is not possible, nether in PVsyst, nor in the reality. See "Backtracking on Hill".

NB:With systems imported from other software, the trackers are usually all independent. PVsyst has to check the pitches uniformity, and choose a pair of trackers as reference.
You have a tool for this in the 3D editor "Tools > Backtracking management"

Other Tracking configurations


We have just explained the backtracking for horizontal axis.
Similar ideas can also be applied to other tracking configurations. However the analytic calculation becomes sometimes very difficult.
Presently, PVsyst has elaborated algorithms and proposes the backtracking for:
- Horizontal N/S axis, as explained above.
- Tilted axis, as far as there is no misalignment between trackers of a group (i.e. "rectangular" arrays).
- Sun-shields: when the sun is high in the sky, the sun shields become highly tilted. This is also the case for sun's east/west orientations. The compatibility with comfort conditions has
to be studied.
- Two-axis frames: the backtracking has been implemented only for the angle of the tables tilt within the frames, i.e. a backtracking from table to table. There is no backtracking
between frames.
- Two-axis trackers: This is a very difficult problem. There may be several backtracking strategies.
In the present time, the backtracking mechanism between neighbor trackers is supposed to be a tilt of the plane following the sun's height, and a rotation around the vertical axis
ensuring no mutual shadings. It doesn't involve passing to the north of the East-west line. It doesn't take the shadings from one row to the other into account.
Please don't use this option, which is not yet finalized !
By the way even if we implement a strategy, nothing ensures that this will be used identically by the control system on the field !

Performance calculations
The backtracking strategy avoids mutual shadings between trackers, for the beam component.
However the diffuse and albedo received by the trackers are affected by the shadings of the neighbors. Namely the albedo is completely lost except for the first and last trackers. This
explains that even with backtracking, you always have a Near shading loss in the final results. This is usually of the order of 2-3%.
It should be noted that the Backtracking doesn't increase the total irradiance received. It only improves the electrical loss effects of the shadings. The total irradiance reaching the modules
is the same as if there were shadings: it corresponds to the total sun energy intercepted for this given sun direction, by the field area "seen" from the sun. Therefore a simulation with
"Linear shadings" (not electrically realistic) and another one with backtracking should give about the same results. See Backtracking performance.

Backtracking Parameter Management


When defining the backtracking strategy, PVsyst has to identify two reference trackers, to determine the relationship between them (tracker width and pitch). During the simulation, the
backtracking angle calculation will be the same for all trackers, based on this reference.

"Native" PVsyst scenes with arrays of trackers


When defined within PVsyst, the 3D scenes are usually defined with arrays of trackers.
In this case the pitch is specified in the array's definition. When there are several arrays, most of the times the GCR is the same for all arrays. If this is not the case, PVsyst will choose as
reference the array with the highest width/pitch ratio (GCR).
Even if there were some arrays with a lower GCR, the backtracking will not produce mutual shadings.

Imported 3D scenes with independent trackers


In the external CAD software, the trackers are defined independently, without gathering them as arrays. Within PVsyst, this is also the case when you fill a zone.
Therefore we have to identify a pair of two reference trackers as reference for the full backtracking calculation.
This is the objective of the tool "Backtracking management", available in the menu "Tools" of the 3D editor.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 61 of 174

This identifies and lists the pitch between all neighbor trackers, and sorts them as decreasing pitch.
You have simply to select one tracker (among the higher GCR) and the tool will propose (select) the neighbour tracker to be associated (in orange).
There is a relationship between this tool and the 3D scene: the chosen reference tracker appears in green, and its neighbor in orange. This allows to visually check that the chosen tracker
is really representative of the full set of trackers.
The detailed parameters involved in the backtracking calculation are shown in the frame "Heliostats parameters" on the left.
By deselecting the reference pair of trackers, one may also enter custom values.

Extended analysis
Furthermore, this tool allows refined analysis of your system.
If you have an irregular system, with some different pitches, and you are not satisfied with the "maximum pitch" choice, you can choose another pair of tables. The tool will show all the
tables with a higher pitch in red. For these tables the backtracking will not be perfectly operational: there will be some possible mutual shadings. If you accept this situation, you have to
activate the Electrical shading effects in your simulations.

Backtracking on a hill
The backtracking strategy is based on the relationship between pairs of neighbour trackers. See the description of the backtracking strategy.
It requires that the tracker's array is perfectly regular, with the same width/pitch ratio, as well as altitude. The altitude differences will necessarily be the same for all trackers (i.e. if not
horizontal, the tracker array will be on a same flat E-W inclined plane).
With different and irregular altitudes like on a hill, the Backtracking strategy is geometrically impossible, neither in PVsyst nor in the reality.

When the backtracking angle is calculated for the trackers A and B (at higher altitude), a shade on the tracker C (at lower altitude) is unavoidable. Here half the tracker is shaded.

Inversely when the tracker B is lower than the tracker A, the tracker C has not an optimal tilt for collecting the whole available sun's light. A better tilt would intercept more light, this
corresponds to a loss due to the cosine effect.

Workaround / only way on a hill: give up the backtracking strategy


In PVsyst, we don't advise using the backtracking on a hill.
However we will allow it, with a warning to the user that this is not a "true" backtracking.
- There may be some mutual shadings. Therefore the electrical shading calculation (according to strings or Modulelayout) has to be activated.
- There may be some irradiance loss due to useless low tilt on higher trackers.
These two effects are taken into account in the simulation. Namely the mutual shades of irregular trackers are correctly evaluated.

With these restrictions, it is not certain that the backtracking gives a better yield than a normal tracking with shades. Both solutions should be compared with a detailed simulation.

Commercial propositions

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 62 of 174

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 foreseeable future.
Moreover on the field, you should also wonder how you will physically implement such Backtracking control in your installation.

Backtracking performance compared with no backtracking


In tracking arrays, the mutual shadings may be very important, as the gains are mainly waited when the sun is low on the horizon.
The backtracking strategy tries to suppress the mutual shadings by reorienting the modules. But it is an illusion to think that you should obtain a much better yield with Backtracking.

Comparison of backtracking with "normal" tracking


When the trackers perform a "normal" tracking (most perpendicular to sun as possible, with mutual shadings), or perform a Backtracking (deviating from the optimal orientation) they
intercept about the same "Light tube" !
- With normal tracking, you have the mutual shading losses including the electrical mismatch shading losses.
- With backtracking, you have losses for mis-orientation (cosine effect), with additional losses due to shadings on diffuse and albedo, as well as higher IAM.

No backtracking: mutual shadings + electrical losses (yellow) Backtracking: no mutual shadings, but orientation not optimal

It is not clear which configuration receives more irradiance.


The electrical losses are penalizing the "normal" tracking, but this highly depends on the geometry. It is rather important with one only module in the width of the tracker. It is more
pronounced in portrait, except with twin half-cut cells modules. It diminishes when you have several rows of modules in the width of the trackers.
If the trackers are not continuous (tilted axis or independent not-jointive tables) the shade will usually only concern a part of the length of each tracker.
The main decisive advantage of the backtracking – if any – is to avoid the electrical effect of shadings (i.e. when a part of a string is shaded, the full production of the string is affected).

Yield comparison
As an example, we have done a comparison of the yield between "normal tracking" (with shades) and backtracking, for a N/S axis horizontal tracking system at Santiago (Chile).
The phi angles limits are +/- 60°, there are four rows of modules in landscape in the width of the trackers. The performance is very similar, except at very high GCR's:

Losses comparison
Now if we have a look on the different losses, we may observe that:
- With backtracking, the losses due to the mis-orientation are slightly lower than the "linear" shading losses without backtracking (irradiance deficit, including for diffuse).
- The electrical losses + IAM without Backtracking are very similar to the losses due to albedo and diffuse shadings + IAM with backtracking.
- We can notice that with backtracking, the loss on diffuse diminish and the IAM increase with high GCR, due to the fact that the backtracking limits significantly the tracking angles. Both
effects compensate each other.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 63 of 174

Performance ratio
Remember that the definition of the performance ratio is:
PR = E_Grid / (GlobInc * PnomPV)
It is normalized to the incident energy in the collector plane GlobInc (often named POA).
Now in backtracking situation, GlobInc is lower than in the "normal" tracking situation, as the collectors are not optimally oriented to the sun's rays. Therefore for a same yield E_Grid, the
performance ratio will be much higher with backtracking than in the normal situation.
In other words: in normal tracking, the mutual shading losses are "included" in the PR ratio (which is a summary of the losses), when with backtracking the irradiance loss due to mis-
alignment is not taken into account in the PR.

Try the no-backtracking solution !


As a conclusion, everyone wants to use the backtracking strategy, as it is a "must" in the PV industry.
However the things are not so simple, the results depend on many parameters, especially when we are not in optimal conditions.
It is worthwhile to check the "no backtracking" solution, and compare both results. This is particularly advised when you are on an uneven terrain, and the backtracking is not "perfect".

Backtracking Performance Ratio


With the backtracking strategy, even with a comparable yield, the PR is significantly higher than with a similar system without backtracking.
Remember the definition of the PR for a grid-connected system:

PR = E_Grid / (GlobInc * PnomPV)

With a backrtracking system, the incident energy GlobInc is decreased, due to the misalignment of the tracking orientation. Therefore the PR is "boosted". The reason is that the loss due
to the misalignement is not accounted in the PR.

As a contrary, with non-backtracking systems, the GlobInc is optimal, so that the PR is lower. A part of this irradiance is lost due to the mutual shadings; the shading loss is accounted as a
global loss of the system, included in the calculation of the PR.

Electrical shadings: partition model


The partition model for electrical shadings is an approximation that allows to compute electrical shading losses faster than with the detailed "Module Layout" mode. This approach
works best in regular row-based systems.
This page describes the definition and implementation of the partition model. For guidelines on partitioning see this page.

General definition
The partition model is based on the observation that shading even a single PV cell may cause important mismatch losses, often leading to losing the power of a whole string of modules.
On each PV table in the 3D scene, one defines rectangles called partitions, each of these representing an area that may be impacted electrically by a single shade. When any of these
partitions is sufficiently shaded, it is considered inactive (as far as the direct irradiance component is concerned). This electrically shaded partition is colored in yellow in the 3D scene
animations.
The electrical loss on the beam component is calculated as the difference between the electrically shaded area, i.e. the yellow rectangular partitions, and the “linearly” shaded surfaces,
shown in grey.

Figure 1: partitions with any amount of shading will be shown in yellow in the 3D scene animations.

The partition model is also called "according to module strings" in PVsyst. It is the historical way of computing the electrical effects of partial shadings in PVsyst, and the only way up to
version 5. The model has received several improvements since, including factors that try to better account for cases with very little shading.
This approach works best for regular row-based systems. Some factors allow to adjust results in the case of irregular shadings.

Procedure
 In the 3D scene, you have to define the "Partitioning" for each PV table or arrays of the scene.
 If the scene has several PV tables or arrays, you have the option of transferring this partition size definition to all other PV tables/arrays.
 When these definitions are complete, back in the general "Near shadings" window, you can choose "Use in simulation > According to Module strings" and define the "Fraction for
electrical effect".
Further notes:
 A “module layout” variant can be used as reference to help set the “Fraction for electrical effect”.
 As for the linear shadings, you have the option of a fast calculation (i.e. from the interpolation in the shading factor table), or a Slow calculation, with the full calculation of the shading
factor from the 3D scene at each step of the simulation (more accurate).

Model
The real effect of partial shadings on the electrical production of a PV field is non-linear, and depends on the interconnections between the modules. The only way to take into account the
interconnections in PVsyst is the "Module Layout" tool, but despite that in some situations the simpler partition model may be applied.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 64 of 174

To understand the limits and applicability of the partition approximation, a key point is the following diagram, showing the total shading loss factor (clear-sky) on a given string, as a function
of the number of shaded sub-modules, as well as the number of strings in parallel on a same MPPT. This graph is fully explained in the page "Effect of the by-pass diodes".

Figure 2: total shading loss factor as a function of the number of sub-modules shaded.

Results interpretation for regular, row-based arrangements


In the case of regular rows of tables or trackers, mutual shadings, when they are present, will affect at least the bottom sub-modules.

Modules in landscape
In the case of a longitudinal string with modules in the landscape configuration, the "bottom sub-modules" means 1/3 of the sub-modules. In Figure 2, this situation is shown by the vertical
dot-dashed line. More important shadings may happen but less often, for lower profile angles: the mutual shadings will increase, gradually leading to the right of the graph.
In this landscape and low shade situation, i.e. moving vertically along the dot-dashed line, you can see that when there are 3 strings or more in parallel (green curve), the shading loss
factor completely cancels the beam irradiance production. The loss reaches about 85% for clear-sky conditions. This justifies our hypothesis that in general, when part of the partition is
shaded the production is almost completely lost. The case of 2 strings in parallel can be fairly well approximated by this case as well.
However, with only one string per MPPT (blue line), the curve shows that when 1/3 of sub-modules are shaded, the loss factor is only around 35%. To adapt the model to this situation,
one can either increase the number of partitions, or define a "fraction for electrical effect" of the order of 42% (35% / 83% of beam). The former is to be preferred, since the fraction for
electrical effect may also be used to account for irregular shading effects. The situation where only strings that have similar shadings are put in parallel on the same inverter input also falls
in this case.

Modules in portrait
If the modules are in portrait, all the sub-modules are shaded at the same time, we are on the extremity of the curve, always fully shaded.

Half-cut modules
With twin half-cut cells modules in portrait, only half the current is lost when the bottom part is shaded, therefore the rectangle-string width should be the half-length of the module. The
landscape case doesn’t differ from the previous discussion on standard modules in landscape.

Model details
Based on the observations of the previous discussion, the partition model aims at implementing the behavior shown in Figure 3. Over a partition, assuming regular row-based mutual
shadings, the electrical shadings increase linearly with increasing linear shadings, until a cell width has been shaded. At this value the total shading loss reaches a plateau value. The
direct irradiance shining on this partition is considered lost.

Figure 3: partition model definition

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 65 of 174

In practice, shadings are not necessarily regular. PVsyst therefore implements internally a decomposition of all partitions in 3 stripes shown in Figure 4:
 a central stripe, which if shaded, will force the maximum shading losses value on the partition,
 two one-cell-wide side stripes, on which the shading factor is considered proportional to the shaded area.
In regular situations this replicates the behavior of Figure 3.

Figure 4: Model implementation with the central and side stripes. In the shading situation shown in black, the shading loss is maximum since the central stripe is shaded.

Fraction for electrical effect


During the simulation, PVsyst may reduce the electrical shading loss from the partition model using a factor named "Fraction for electrical effect", that can be defined in the near shadings
window. This allows to adjust the results to irregular shading situations, as discussed below.

Thin objects
The partition model also a special feature allowing to evaluate the shading effect of thin objects which only shade a part of one individual cell (like fences, HV lines above a PV array, etc).
Any shading object defined as “thin object” will impact electrical shading losses separately from regular objects. A separate thin object fraction for electrical effect can also be defined in the
near shadings window.
This kind of evaluation is currently not possible with the "Module Layout" tool.

Model validation
We run extensive comparisons against the “Module Layout” model, which is considered most precise given row-based situations. Validations of the full PVsyst model against real systems
have also been conducted in the past.

Caveats

Non-ideal irradiance conditions


As the diffuse fraction grows, the real MPP of a shaded system may move beyond the scope studied in Figure A. For this reason validation against the “module layout” model is important
as the latter captures better the MPP position in various conditions, as it is based on the combination of IV curves.

Irregular shadings and Fraction for Electrical Effect


With irregular shadows, it is difficult to know whether a cell has been fully shaded or not, therefore the partition model is not really applicable. However, since whenever the central stripe is
shaded the loss is maximum, we can consider that the calculation of the electrical factor according to the partitions gives generally an upper limit of the real shading loss.
During the simulation, PVsyst may reduce the electrical shading loss using a factor named "Fraction for electrical effect", to be defined in the near shadings window. The corresponding
value of the "Fraction for electrical effect" is dependent on the shades distribution on the PV filed and the electrical array configuration. For a row-based arrangement (where the shades
are very regular), it is near 100%. With more irregular shades like chimneys, far buildings, trees, it could be of the order of 60 to 80%, depending on the "regularity" of the shade (for
example a diagonal shade could have a lower impact as it would concern modules better distributed in the PV array).

Module Layout reference


The Module Layout tool provides an accurate way of computing the real electrical losses in a much more extended range of situations. This may help for the evaluation of the "Fraction for
electrical effect" in the case of irregular shadings.
A related example, in the case of a very large system, one may define a representative sub-system (for example corresponding to one central inverter), execute the simulation and
evaluate the Electrical shading loss with both tools: Module Layout and partitions model; this will allow to evaluate the "Fraction for electrical effect" representative of your system.

Model history

Up to 7.2.21
The model did not account for bottom cell stripes. In other words, as soon as a partition was shaded, the shading loss was considered to be maximum. To mitigate the supplementary
shading losses, a threshold at low linear shading values was implemented, that could cancel the electrical shading losses if there weren’t enough linear shadings.

Up to 7.3.4
Bottom cell stripe effects were implemented at the level of the whole scene. After the evaluation of linear shading factors, a general average shade height was computed. If that height was
higher than half a cell width, the electrical shading losses went from zero to their maximum value.
This implementation tended to underestimate the electrical shading losses in the case of irregular shadings. Indeed the average shade height was often well below the actual shade on
some of the most shaded partitions.

Partitioning to account for electrical shading losses

Basics of partitioning
The partitioning for the Electrical calculation is done in the dialog of each field/table definition in the 3D scene.
The gist of the procedure is as follows: on each table in the 3D scene, you have to define rectangles, usually representing a full string of modules, but also more generically a group of PV
cells that will cease to produce energy once mutual shadings are sufficiently spread out. You can define these rectangles either by their number in height and length of the table, or by their
sizes. A rectangle will generally have the height of one module, either in length or in width, depending on the orientation (landscape or portrait). However in some specific cases, the height
of the rectangles will be an integer fraction of the module height.
The definition of full and regular rectangle-strings is not always possible, they are accepted even if the rectangle sizes don't match the field sizes, see below.
In the dialog (page "partition" of the 3D field editor), you have to specify whether you want to define a partition for this table, and the number of rectangles. The partition will appear as
dotted lines on the PV table.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 66 of 174

Typical cases

Regular arrays, generalities


In regular fixed tilt arrays or arrays of trackers, for minimizing the electrical losses you should ideally gather all the modules of a string in a same row within a table, to ensure that all
modules operate in the same conditions. The width of this "rectangle-string" will therefore be the width of the PV module in landscape, or its length in portrait. Defining 2 rows (for example
U-cabling) may produce a little bit more shading loss when the modules are positioned in landscape. In portrait orientation this type of cabling may however be advantageous (see below).

Systems with "little" tables


Many systems are now defined by little tables (of less than about 10 modules in width), often imported from other CAD software, and often positioned on a hill, following the terrain.
 If all the modules are connected to the same string, the string partition is one rectangle in both sizes (i.e. 1 x 1).
 If the bottom and the top row of each table are connected to two different strings, you should split your table into 2 rectangles-strings.
One may worry that the string being laid-out over multiple tables would lead to problems with the partitioning. However, you shouldn't worry about the calculation: if your tables are
positioned in rows, side-by-side on the terrain, defining one little part of the string in each table will be equivalent as defining a full string in a wide table. All the bottoms will be shaded at
the same time, and the rest of the table will become inactive, in the same way as for a big table with multiple strings.

Half-cut modules
For Twin half-cut cells modules, the ideal is to put them in portrait. In this case you can define a rectangle of half the length of the module. In landscape, such a module will behave exactly
like a normal module: there is no specific benefit for the electrical shading loss from the cell layout.
NB: there is no simple way to define partitions for Twin half-cut cells module strings spread on several rows on the table: in this case the best course of action is to use the Module Layout
option.

String inverters / All strings on a single MPPT are shaded in the same way
In the specific case of single-string inverters, or whenever all the strings (laid-out on one row) on a given MPPT input are shaded in the exact same way, modules in landscape orientation
will suffer less from shadings than in the case of a central inverter. This is the case both for half-cut or standard cell modules (with three sub-modules in general). When shading the bottom
row of cells, the loss of production will only be of about one third on clear-sky conditions, due to modules having three sub-modules in the height of the partition. Once all effects are taken
into account, it was found that these strings are best modeled with two partitions per row of modules.

String optimizers
When connected to string optimizers, whether or not multiple strings are put in parallel with each other on the same MPPT, these will usually behave as in the string inverter case (see
above). For modules in landscape, strings on a single row, the best model is two partitions per row of modules.

Defining rectangles as one module / Module optimizers


Some people define each rectangle-strings as one only module. This is not the right way, except when you are using an optimizer on each module.
If the optimizer acts on 2 modules in series, you should define rectangle-strings representing 2 modules.

Other cases
It is not always possible to define exactly one rectangle for one string. Some strings may have modules irregularly distributed on 2 rows. In some other cases, there is no contiguous and
rectangular group of cells acting as a single partition that would turn on or off depending on the shadings.
Remember that this electrical calculation is only an approximation. The particular cases should be calculated using the Module Layout option. The module layout may also serve as a guide
to define partitions. In the case of a very large system for example, you can consider a smaller version of the system to calculate the effects of shadings accurately with the module layout,
and use these results to properly define the partitions.

Summary for common cases


To summarize the cases above, we identify the configuration of the strings in the following way: Number of rows - Orientation - (optional) U-cabling.
"Number of rows" (marked as an integer number) is the number of rows in the height of the table spanned by all the strings of a given MPPT input. By default we suppose that the strings
are laid out on one row. U-cabling (marked as U) is for the case where the strings are laid out over multiple rows in the height of the table. Finally the Orientation may either be L (standard
or half-cut modules in landscape), P (standard modules in portrait), or T (half-cut modules in portrait).
Case Partitions in height Example
1L 2 partitions

xL x partitions

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 67 of 174

xLU 3x partitions

xP x partitions

xPU module layout recommended

xT 2x partitions

xTU x partitions

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 68 of 174

Extension of the partitioning to other tables


To proceed with the electrical calculation based on the partitioning in the simulation, the partition has to be defined for each table of the scene.
You can extend the definition of this table to the other tables of the scene.
- Cancel all partitions allows to suppress the definitions;.the electrical calculation is no more possible.
- The selection of tables if you have defined a multiple selection in the global 3D scene, you can apply this partition to all selected tables.
- All tables of same size the partition may be specific for a set of identical tables.
- All tables of the scene defines all tables as "Partition defined" (even little tables 1 x 1), extends this choice when possible.

Thin objects: effect on the electrical losses (Module strings calculation)


NB: This procedure is only useable with the "Electrical shading loss according to modules strings" procedure. There is no equivalent in the "Module Layout" for the moment.

Overview
If a shading object is sufficiently thin, its shade will not cover a full cell. Even if it is rather far and produces a broad semi-shading (due to the sun's diameter), the irradiance loss should be
considered as the integral of the shading figure, and will be the same as the effect of a well delimited thin shading of the same wire.
This is the case of electrical wires above the array, handrails, etc. The case of electrical wires is particularly important, as it affects the array during the whole day.
In these cases the current in the cell will be reduced by a factor of the order of the wire diameter, with respect to the cell's size. We will call this ratio the "Thin Object ratio". Remember
that in a string of modules, the current is limited by the worst cell (i.e. the cell with lower current).
We can take this situation into account in the shading calculation mode "According to module strings". In this mode the production of the whole string is considered lost as soon as one cell
of the string is fully shaded.
In the case of thin objects, the cell current is not null, but reduced according to the "Thin Object ratio". Therefore the loss for the shaded string will be affected by the parameter "Fraction
for electrical effect". As a first approximation, we can use the value of "Thin Object ratio" for this parameter.
See the paragraph "Effect of distance" below for e refinement of this value.

Thin object ratio


When a thin object throws a shade on a PV module (cell), the current in the cell will be limited to the illuminated area.
Let's call "Thin object ratio" the ratio of the thin object shade area, to the total area of the cell. The shading current reduction will be proportional to this Thin object ratio.
Now the thin object's position may depend on the cable orientation, or will move according to the sun's motion. We will assume that - on an average over any evolving conditions - it will be
the wire width divided by the cell's size.

As an example, a wire of 300 mm2 has a diameter of the order of 20 mm. On a standard 6" cell, the thin object ratio will be 20 mm / 156 mm = 0.13.
Therefore, the current loss will be 13% in this cell. For the full string, the current will be the current in the worst cell, i.e. a loss of 13% whatever the number of cells shaded.

Effect of the distance


The sun diameter is 1.39 Mkm, at a distance of 149.6 Mkm of the earth. So that its apparent diameter (cone aperture) is 0,53°.
Now if you have a thin object of section S, at a distance D of the PV array, due to this diameter the shaded area will extend to a total width W = D * sin(0.53°) + S.
The Thin object tool is aiming to understand and evaluate this effect.
You will find this tool in the 3D editor menu, "Tools > Thin Objects Analyze tool".

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 69 of 174

You have to specify the object's width, the cell size and the distance of the object to the array.
This tool will show the shade trail on the PV module.
If the cable is very close, we will have a sharp trail of 20 mm in width, with a full shading on this cell (20 mm / 156 mm = 13%).
The example here shows a cable at 30 m over the PV array: the shade trail is about 30 cm wide, i.e. split onto several cells. Therefore the loss on one single cell will be lower.

Sun motion and shades distribution


You can move the sun's position with the red point: the shade will move on the cells. The global shading effect on each cell is shown on the plot as function of the sun's position: the
maximum shading factor on one given cell at a given time is 8.6%: this will be the value we have to attribute to the "Fraction for electrical effect" for this thin object.
NB: even if you have several wires over this PV modules string, the current of the string will be limited by this value. The shading effects are not additive !

Additional remarks
Whatever the distance of the thin object, the total shade on the array (i.e. lack of irradiance) is always the same. We can check with this calculation that the shade integral is always the
same (20 mm / 156 mm) whatever the sun position or the object's distance.
On the other hand, in our case the shade maximum intensity is 9.2% , but this doesn't mean that the shade on one cell reaches this value: what is relevant is the integral on the full cell at
a given time, which is shown on the plot.

Electrical shadings: Module Layout


The Module Layout tool is aimed at the detailed calculation of the Electrical shadings mismatch loss.
It requires a description of the position of each PV module in the 3D scene, and the module interconnection as strings according to the inverters defined in the "System" part.

General description
The evaluation of the electrical shading loss requires the calculation of the I/V characteristics of the PV array, by the addition of the voltage (I/V curve) of each module in a string, and then
the addition of the current of each string (see XXX).
The I/V curves depends on the partial shading on each PV module. Therefore we have to know the exact geometric position of each module, and the string it belongs to.
Therefore, this definition of the "Module Layout" part is based:
- on one hand on the the shadings 3D construction for the positioning,
- on the other hand on the electrical definitions of the sub-arrays (PV modules and inverters) in the "System" option.
These parts of the project should be well defined before the elaboration of the Module Layout tool. Any posterior modifications of these parameters may have consequences on the Module
Layout definitions. The Module Layout is the last step of your development for the study of a PV system.

Procedure
When opening this tool, you get a 2D representation of all fields that you have defined in your 3D scene. Each 3D sub-field element (for example a shed or a tracker) is named a "Table".
If you have defined several orientations, you will have a specific representation for each orientation.
The blue panel on the top right gives you some information about the actual state, and advices for the next action to be done.

There are 2 main steps to follow:


- "Mechanical" page shows the rough tables from the 3D scene, and requires to position all modules as defined in the "System" part, for each orientation.
- "Electrical" page is meant for the attribution of each module to a specific String (acc. to the inverter's definitions in "System").
Moreover, there are pedagogic tools, not necessary for the preparation of the Module Layout parameters for the simulation:
- "Shadings 3D" shows the real shadings on all tables of a selected MPPT input, and the corresponding I/V curves for each shaded PV module.
- "I/V curves" shows the detailed I/V curves for this MPPT input, as addition of voltages all modules in series in each string, and addition of currents for each string in the MPPT array.
The electrical calculations are done taking the beam and diffuse components into account. Even when a sub-module is completely shaded (regarding the beam component), there is a
remaining diffuse irradiance which ensures a minimum current in this string. The diffuse incident irradiance is coming from all directions, it is supposed homogeneous and to be affected by
a constant shading factor, calculated once only for the whole year. Eventual albedo is also evaluated using a constant shading factor.
These Module Layout definitions are mainly used within the simulation, for the detailed calculation of the mismatch electrical shading losses.

Module Layout definitions output


Incidentally, this tool may be also useful for an easy design of the module's wiring organization within your real PV system.
The ModuleLayout definitions may be printed independently, or may be shown in the final simulation report if desired, in different pre-defined ways.

Limitations

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 70 of 174

Thin film modules


This tool is suited for crystalline modules only, with usual rectangular cells.
It is not applicable to thin film modules, where each cell is a strip of typically 10 mm width, along the length of the module. In this case the electrical mismatch loss is null if the shades are
perpendicular to the cells, i.e. if all cells are identically illuminated (Cells in portrait in a row arrangement). However the shading loss will be maximal if the shade is parallel to the cell, as
one only cell in series may be shaded and block the current for the whole module.

Thin shadows
Due to the way shaded sub-modules are recognized, the module layout will underestimate the impact of long and thin shadings (e.g. poles).

Very large systems


The Module Layout is only useable with systems of the order of few MWp at most. Either because of the complexity of defining all the PV modules location definition if these are not
regularly interconnected, or due to the computing time during the simulation. PVsyst fixes a "reasonable" limit of around 1 MWp, and an upper limit (that you can modify in the advanced
parameters) of 5 MWp. The limits can be modified via the advanced parameters "Power limit for Module Layout warning" and "Power limit for Module Layout error".

For very large systems, we advise to define a representative sub-system (for example corresponding to a single central inverter), execute the simulation and evaluate the Electrical
shading loss with both tools: Module Layout and partitions. This will allow to evaluate the "Fraction for electrical effect" representative of your system (usually close to 100% for regular
systems).
Then you can simulate your full system using the option "According to module-strings", i.e. the partition model, applying this pre-evaluated factor. This latter calculation requires about the
same computing time as the linear shadings option.

Module Layout mechanical definition


The aim of this page (tool) is to dispatch the PV modules (as defined in the sub-arrays of the "system" part) on the Tables defined in the 3D shading's editor.
Therefore the "System" and the 3D scene should be well defined before entering the "Module Layout" part.
The number of PV modules should correspond to the number of modules defined in the Sub-arrays for each orientation. Therefore you have a specific view (of the 3D tables) for each
orientation.

Definitions of tables in the 3D scene


When defining your fields in the 3D scene, you are advised to use the option "By modules", so that the table's sizes are correctly predefined.
However freely defining tables with sufficient room for your modules is also possible. The tables will be resized at the output of this tool.

When opening "Module Layout"


All the tables of your system (in one specific orientation) are presented as in the 3D scene. They are labeled as Rows and Columns, so that they may be easily identified. This numeration
is automatic according to the geometrical arrangement, you cannot modify it.
The orientation is identified by a Compass on the top right of the drawing. If there are several orientations in your system, you can choose each of them by a combo-box.
On this example: the compass shows an orientation of azimuth 30° (south):

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 71 of 174

You select a table by clicking it (red contour).


You can define a multi-selection by "Ctrl-Left clic", and deselct by "Ctrl-Right clic" (orange contour).
You have tools (icons on the right) for:
- Zooming IN / OUT (also with the wheel).
- Saving the tables picture as a *.BMP file.
- Choosing the label kind mentioned above each table (name of the table in the 3D scene, "Orient#, Row#, Col#", or more condensed, etc).
- Exchanging the string attribution (see next page).
- Desecting all your multiple-selected tables.

Operating panel
The blue panel on the top right always informs you about the state of your definitions, and the actions to be taken.
The "Mechanical" dialog:
- Shows the main characteristics of the selected table.
- Allows to dispatch the modules on the tables. This may be done for the full system, for the actual orientation if several ones, or for a selection of tables only.
- You can specify here the spacing between modules, the filling mode (when the table is bigger than necessary), the module orientation (portrait or landscape).
- If the 3D area is not sufficient some modules required by the "System" sub-arrays definitions may be missing. You can add a row or a line of modules if necessary (NB: if the table
belongs to an array, all the tables of the array will be concerned in the same way).
NB: If necessary it is possible to suppress some modules in the table (by right-clicking on the concerned module). This allows to exactly adjust the number of modules required by the
"system". This may also avoid using Polygonal fields without necessity. The use of polygonal fields is very special, it should be reserved to very specific BIPV cases.
However don't suppress too much modules as the shading calculation may be slightly affected.

Match the tables to modules


Finally, for the next steps the 3D tables should perfectly match the PV modules. If this is not the case you have to press the buttons "Match this Table" or "Match all tables".
This is especially useful when you define a polygonal field in the 3D scene: the rough polygon (like for example a roof available area) will be initially filled with modules, you can add or
suppress modules with the mouse, and finally you have to press "Match to Table" for adjusting the definitive polygon around the PV modules.

Completing all these requirements gives access to the "Electrical" tool.

Module Layout Electrical definition


The aim of this page (tool) is to associate a string (specified in the Sub_arrays of the "System" part) to each module on the tables.
This is only possible after a correct definition of the "Mechanical" parameters.

Strings list
On the left panel, you have a list of all inverter (or MPPT) inputs as defined in the sub-arrays.
Each string is represented by a set of PV modules, of different colors according to their number (colors 1..10).
In this example we have 5 strings per Inverter, and 16 modules per string.

Modules distribution
On the tables drawings, each module is associated to a string. The color - and a possible string number appearing when the modules are sufficiently large - identifies the corresponding
string.
Colors
The colors are those characterizing the electronics components (except 9 and 0):
1 = brown, 2 = red, 3 = orange, 4 = yellow, 5 = green, 6 = blue, 7 = violet, 8 = grey, 9 = purple, 0 = dark grey.
Objective
In a rows (sheds) or trackers arrangement, the optimal distribution of modules is to allocate all modules belonging to a same string to a single row in the table.
This way all modules of one string will be shaded identically. This is the best situation for the row-to-row shading losses.

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024
Project design Page 72 of 174

Also, usual modules with 3 sub-modules in length should be positioned in landscape, when twin half-cut cells modules should be in portrait.

Orientation
If there are several orientations in the system, each orientation has to be managed independently.
You can choose the working orientation using a combobox.
On the right panel, you will see exclusively the tables of the chosen orientation. The orientation of each table is clearly defined in the 3D scene.
On the left panel, you always see all inverters. Each inverter input corresponds to a sub-array, and is therefore associated with the orientation of this sub-array. The inverter inputs not
corresponding to the chosen orientation will appear as desabled: you cannot of course associate modules of thie view to them.
When using mixed orientation in a sub-array, only strings corresponding to the chosen orientation will be enabled.
NB: When defining domes, both tables will be shown on the geometrical view on the right. In this case the direct or opposite table will be enabled, according to the chosen orientation.

Manual association of modules to strings


A simple way of associating each module to a string is to choose (click on) a string on the left, and then click the modules to be assigned (you can move the mouse on several concerned
modules). You can un-assign a module by right-clicking. The colored cases on the left correspond to the number of assigned modules. The blank cases indicate the number of modules
still to be attributed.
This way is obviously cumbersome with a big system.
Manually moving or exchanging the assignments
As an option (click icon on the right), you can enable a mode in which you displace the string assignment of a module to an unassigned module, or exchange it with another module, simply
by dragging it. This may be useful when you have finished the automatic attribution, and you want to perform some adjustments.

Automatic attribution
For big systems, the button "Auto Attribution" opens the dialog explained on the next page.

Automatic string-modules attribution


The allocation of each PV module to a string may be done manually using the mouse. However with big systems, this is obviously not viable.
PVsyst offers a wide set of rules for distributing the strings according to different strategies.
This tool is available with the button "Auto attribution", which opens the following dialog:

file:///C:/Users/jec/AppData/Local/Temp/~hhFDC7.htm 6/27/2024

You might also like