Jump to content

dtarin

Members
  • Posts

    774
  • Joined

  • Last visited

Posts posted by dtarin

  1. In my experience, Ga-doped modules are still susceptible to LID, and I have also seen LID loss in TOPCon tests. The LID loss for these types are less than p-type boron-doped modules, but I have not seen zero LID in Ga-doped or N-type TOPCon modules. I am not familiar with HJT type modules. 

  2. Hello, 

    It would be very useful to see two features related to the shading factor table:

    1. Increased resolution in the shading factor table 
      • Allow user to define additional points in the table, or provide additional preset tables with additional values. The purpose of the shading factor table is to reduce simulation time, but it adds additional shading loss. This is fine in principle, but it would be helpful if users could investigate and find that balance between reduced simulation time and reducing the overestimation of shading losses. Additional points in the lower elevations would valuable.  
    2. Allow users to manually enter or import shading factor tables, linear and mod. strings
    3. Allow shading factor tables to be a variable for batch processing. This could be a file reference in a PVsyst-defined format.
      • User-defined/imported shading factor tables could be used in other projects for site characterization and evaluating different scenarios in development. 

    Plants are getting larger, and when modeling trackers with terrain, the simulations times can be quite large, but when using fast mode, the overestimation is not always acceptable depending on the purpose of the simulation. 

  3. You might have undersized your inverters or have too high of losses prior to the injection point. Posting your waterfall results will help identify. 

  4. Running unlimited sheds with a fixed tilt angle, where phi_min = phi_max, does not fix the tilt angle of the tracker, and it continues to backtrack. This was possible in 7.4.2, but has not been since that version. It does not matter whether backtracking is checked or not, or whether it is done through batch mode or regular simulation. 

  5.  For terrain following trackers we model all trackers 1 string in length to adapt as much as possible while retaining the electrical shading effect one would expect. 

    Using the module layout shading calculation you can assign strings to cross multiple tables, and the limit in PVsyst can be bypassed in the settings (I think before it was 5MW, not sure if that is still a thing). One other possibility is if you were originally modeling half cell modules with 2 in width by 1 in height (for single string racks), you could model half racks 1x1. Running a test between this method and a module layout simulation might inform you on how accurate it is. 

     

  6. One point to clarify, if the meteo data is taken directly from the pyranometer, then it is to be excluded. If the pyranometer data was used to adjust satellite data, then it is possibly excluded from the resulting adapted data (you will need to verify this), and thus you would include the horizon profile. 

  7. If the ground terrain is not set to be a shading object (and hence not cast shadow itself), alternatively, you can leave it as-is. Note that if you do set the ground terrain to be a shading object, your simulation time will increase dramatically. For large sites, it may not be feasible. @Stéphane As far as I am aware, without it being set as a shading object, it is effectively transparent when it comes to the simulation, is this still the case? 

  8. 1 hour ago, dtarin said:

    A monofacial fixed tilt test with two arrays with different ILR, orientation, and external shading had a difference of 0.05%, comparing the individual runs summed with a single combined run, which is reasonable (all on fast sim). With only a glance, it looks in the shading calculation for the 20/15 orientation there is a difference in the attenuation for diffuse and albedo in the combined run vs the individual run. 

    The reason there was a difference in the attenuation is because I had trees present on the other array (20/0) to create a significant difference in the shading calculation to see how PVsyst compared in individual vs combined runs. With the trees removed, the attenuation in the combined run for the 20/15 orientation now matches the individual run of the same orientation.  So it is worth noting there will be a small deviation in shading calculations if external objects or irregular terrain are present (my assumption on the latter).

  9. I have not. As noted in the other thread, among the other considerations for bifacial, there is rear side IAM loss, which is not a loss that's provided but built into PVsyst, so there will invariably be a difference (and might be the largest contributor to the difference one sees). 

  10. 42 minutes ago, dtarin said:

    For tracker systems, this is not possible, but if the several orientations menu in the 3D scene was enabled and the user allowed to create orientations  with certain tables and allocate to different subarrays, then this would separate out the shading losses and be very convenient and moving the software forward to more realistically capture inverter level behavior to match operational data. 

    This is worth highlighting. If PVsyst enabled this and users were able to define each inverter and their associated tables (or approximately close) as a unique subarray both electrically and with respect to 3D shading, then they each become an independent calculation path down the inverter level, and we could then get individual inverter outputs from PVsyst instead of a single combined figure, in addition to POA and other variables. There are some factors I am probably glossing over and other restrictions still in place (bifacial), but its likely better than a single model all mixed together with averages. 

     

  11. A monofacial fixed tilt test with two arrays with different ILR, orientation, and external shading had a difference of 0.05%, comparing the individual runs summed with a single combined run, which is reasonable (all on fast sim). With only a glance, it looks in the shading calculation for the 20/15 orientation there is a difference in the attenuation for diffuse and albedo in the combined run vs the individual run. 

  12. If PVsyst, 

    1. removed the restriction to allow identical orientations in the orientations for fixed tilt systems, and
    2. allowed multiple orientations with tracker systems under orientation and enabled the option in the 3D scene,

    then users could model subarrays with independent shading. If there are other restrictions in place for trackers such as with POA or bifacial calculations, then for tracker systems, a straightforward implementation would be to require all orientations to be of the same orientation.

  13. The ability for PVsyst to model different portions of a plant in the 3D scene to different subarrays is possible, it's already there for fixed tilt systems, there are just restrictions in place preventing it from working for other systems. For example in fixed tilt, several orientations must be defined in the orientations menu and they must be unique orientations, otherwise it prevents you from moving forward. Computationally there is no reason why we couldnt define two orientations at the same tilt and azimuth, its just a restriction. But if you had two unique orientations in the orientations menu defined, then in the shading scene , you could allocate one or more portions of the plant to different subarrays. I presume that when doing so, the shading calculations will be specific to the modules defined in the orientation menu of the 3D scene and thus apply correctly to the subarrays when using according to strings. 

    For tracker systems, this is not possible, but if the several orientations menu in the 3D scene was enabled and the user allowed to create orientations  with certain tables and allocate to different subarrays, then this would separate out the shading losses and be very convenient and moving the software forward to more realistically capture inverter level behavior to match operational data. 

×
×
  • Create New...