|
<< Click to Display Table of Contents >> PV fields |
  
|
|
<< Click to Display Table of Contents >> PV fields |
|
See also: Near shadings, general organisation.
In the 3D scene, you can create several different kinds of PV fields:
| - | Single PV table: this is a rectangular sensitive area receiving PV modules, with possible extensions on the edges representing mechanical structures, |
| - | Array of tables: often named "sheds" or "rows": several tables one behind the other, |
| - | Array of domes: arrangement of east-west opposite arrays of tables, |
| - | Array of trackers: one or several tables tracking the sun for optimal irradiance reception, |
| - | Rectangular PV planes: sensitive rectangle, without frame. You may define several non overlapping rectangles at a time, in a same plane, |
| - | Polygonal PV plane: you can draw a field of any shape with the mouse, |
| - | Array of Sun-shields: special array of tables aligned vertically one above the others, for façades. |
In an existing scene, you can open a field by double-clicking on its border, or through the menu "Edit > Edit an object".
NB: we will name "Field" one of these composite objects; and "Table" one element of these objects.
In the field dialog, you have a page "Basic parameters" defining the main properties of a field, as well as parameters for its insertion in the 3D scene.
This page defines specific parameters for each kind of fields, like the orientation, number of tables and disposition, pitch between tables, etc.
In its own referential, the PV-plane is defined by its tilt, but always facing the OY coordinate. Plane azimuth will be defined only when positioning the plane in the global scene.
For the Tables (and arrays of tables), you can define a "baseline slope", which means that the base of the table is tilted (for example following the terrain on a hill or transversally on a 2-sided roof). When doing so, the real orientation of the plane is modified. So that, for example, a set of tables following the terrain will have a set of different orientations: PVsyst can treat these systems by defining an average orientation (which is not necessarily the nominal orientation).
cf Tracking planes for the basic definitions of tracking planes.
The table has a sensitive area meant to receive PV modules. Therefore when defining a field, you should define the associated PV module (as defined in the sub-arrays of he "System" part). A given table can only receive PV modules of the same sizes.
You may define a field:
- Either by modules: this option (strongly recommended) defines an area exactly suited for the desired number of modules, and a specific spacing between them.
- Or by the sensitive area: you specify the required size of the PV table, without constraints in a first stage. However at the end of your design, you can retrieve the exact required size for your modules by clicking "By modules".
Both of these options may be handled by the mouse (dragging the red points): the modules will fill the available area when modifying the sizes.
The arrays are made of identical tables. You also have to define the frame sizes around the sensitive area.
For the multi-rectangular fields (suited for BIPV), you may define rectangles of different sizes.
The polygonal planes may be drawn using the mouse. This area will be filled by modules. When defining it "By modules", you can add modules by clicking on a position, or suppress a module by right-clicking.
This defines the partition in rectangle-strings, used for the approximated electrical shadings option "according to module strings".
| - | You are advised to define tables as large as possible. This will simplify the drawing and lead to faster treatment during simulation. |
| - | You should choose the construction by arrays when it is possible. This is much easier than defining each table individually, and allows easy modifications. |
| - | Defining a table for each module individually is not the right way. This produces very high execution times, and the electrical losses are not accounted correctly. |
| - | When defining a partition for electrical calculations, each rectangle should represent one string, not one module. |
| - | When importing scenes from other software, the tables are usually little tables, Some models in the simulation (bi-facial 2D, backtracking) require that the spacing between tables be very regular (with possibility of circulation ways between groups). PVsyst will check this, and will soon provide some tools to analyse this situation in detail, table by table. Such a tool is already available for tracking systems (in the main menu of the 3D editor, choose "Tools > Backtracking management"). |
| - | In many big installations, the base of the tables is tilted, following the terrain. This leads to variations of the real orientation between these tables. PVsyst may group these tables and define a common average orientation for the simulation, which represents a little approximation. However even in this case, the linear mutual shadings will be calculated correctly for each table. |