Jump to content

Michele Oliosi

Moderators
  • Posts

    788
  • Joined

  • Last visited

Everything posted by Michele Oliosi

  1. IAM losses and transposition: Yes, the average is used. Until now, trackers always have a single average orientation. I assume you are talking about the backtracking strategy. In this case, yes the same pitch and width information is given to all trackers in the scene. There is only a parameter which is defined for each tracker independently, the axis tilt. Trackers with different axis tilts will move a bit differently under backtracking. Regarding the pitch and width, they are defined in Tools > Backtracking managament. In fact the "up to 8 orientations" is only the maximum limit for fixed tilt orientations. It is not related to the shading scene nor to trackers. In all cases, the shadings are computing taking the full complexity of the shading scene into account, including the topography. Basically yes, the calculation of the backside irradiance uses an idealized flat and regular model of the tracker positions.
  2. The above information only concerns version 6. Versions 7 and above work along a novel premise altogether. The parameters "Threshold shading factor from.. " do not exist anymore.
  3. To my understanding, the diffuse acceptance is for a point: The diffuse fraction on ground is what you get once you integrate all points of the ground.
  4. In PVsyst, the diffuse component is considered isotropic. Therefore, it is sufficient to know for every point on the ground what portion of the sky (top hemisphere) isn't covered by other tables. This can be integrated for all positions on the ground. This fraction is purely geometrical, and is then to be applied to the total diffuse irradiance.
  5. The following parameters : Axis azimuth / Phi min / Phi max / Uses backtracking / Pitch / Shed total width, in the bifacial window do not affect the simulation in any way. They are in this window for educational and studies purposes only. (See the text in dark red at the top of the window). The default values taken for the simulation (e.g. 44°) are taken directly from the 3D scene, if it exists, or the orientations window whenever you are using an "unlimited" orientation. My first guess is that 44° is the effective axis azimuth once you take all the trackers in your scene into account. Do you happen to have different patches of trackers with different azimuth? The value 44° should correspond to the axis azimuth value found in the orientation window. Could you check that they match ? Thank you for the suggestion, it could be a nice addition. At the moment we only work with the axis height above ground, because that would be specified once you choose a specific tracker model.
  6. Hi this peak is due to the clipping, indeed any power above the grid limitation or inverter nominal power will be clipped to the value, the generation distribution is therefore biased towards values close to the clipping value. There is therefore probably nothing wrong with your system. However at the moment the scaling of the plots is automatic in PVsyst, and there seems to be a bug on that level. At the moment there is nothing that can be done to change the scale of plots when printed in the report, unfortunately. We'll be looking into how to improve this situation...
  7. Should be out in the next patch ?
  8. Hi, While the injected current is not an output in PVsyst, given E_Grid and the specific HV voltage, you can easily calculate the average current during each simulation hour. Just use the Advanced simulation > Output file tool to output E_Grid for each hour as a csv.
  9. Did you have any unavailability time periods affected in the detailed losses parameters ? This may be the reason for this.
  10. No in principle the total inverter power is maintained.
  11. If you consider the "usual" sun path at equator, basically the sun will rise quite to the east and go up in the sky quickly and then go down to the west. The time spent by the sun around azimuth 0 or -180 is really shortened, with respect to a sun path at higher latitudes, with the sun being lower on the horizon. Essentially you want to maximize the time your sun is facing the modules, i.e. the azimuth and sun height match the plane orientation. If you are close to the equator, and your POA is north / south or south oriented, the time spent with matching azimuth will be quite low. However with a POA facing east or west the azimuth will match quite well for about half the day.
  12. The view factor is calculated with the following idea: given a point on the ground, what is the part of the top hemisphere that corresponds to the back side of the modules. Indeed some of the light reemitted reflected by the ground will go towards the sky, other towards the structure, maybe some shading objects etc. With the view factor we are interested what is the proportion of reemitted light that actually goes to the back of the modules and not to some other direction. Now, imagine that the size of the tables with modules varies. Depending on the size and spacing of the tables, for a given point of reemission on the ground, the fraction of light rays that reaches the back of the modules will vary. In short, the point on the ground may "see" more or less of the back of the modules.
  13. Hi @Ronald you can export a CSV file via the project window > Advanced simulation > Output file and then re-running the simulation from the Advanced simulation window. See https://www.pvsyst.com/help/output_file.htm for more details.
  14. Hi @NoamD, Thank you for the feedback. In this case, I see that the simulation version is 7.2.3. There have been many corrective patches since then, so I would strongly suggest you update to the latest version, or at least to the latest version 7.2, i.e. 7.2.21. This will allow you to obtain more accurate results, and I believe this specific warning message should be resolved.
  15. Thanks @kjs55 indeed that makes more sense. @MarVF6 indeed at the moment there is no native way to modify several orientations through the batch mode. In the medium long term we should be able to develop the feature along this direction, but to my knowledge it will take some time.
  16. @Haus Yes I believe it is due to this new calculation. The overhead poles and wires probably cause very little shadings overall. Some of these situations were neglected in version 7.2.21, and are not neglected in version 7.3.2 anymore. I would suggest trying to change the advanced parameter controllling the cell width to 0, as in the screenshot above, and then making sure that the thin shading fraction is low enough. However depending on the original amount of shadings I believe the electrical shadings may increase even more. If you can let us know the results that would be very valuable. If the discrepancies are too high, I would invite you to send us your project at support@pvsyst.com (exported via the main window > File > Export project), this is the best way for us to check in details on a case by case basis.
  17. In the system window, if you activate the "multi-MPPT" mode, you will be choosing a number of MPPT inputs for a given sub-array. In PVsyst, it is common practice to group MPPT inputs (or inverters when disabling "multi-MPPT") that share the same properties into a sub-array. You can create a sub-array with one or several MPPTs that will receive strings with the same shading situation, for example to prevent mismatch. If you do so, when you are using the module layout, you should be able to assign the corresponding modules to that specific sub-array. In the system window, do not forget to implement the "power sharing" between sub-arrays that belong to the same inverter configurations.
  18. Hi you can have a look at https://www.pvsyst.com/help/ageing_general.htm The STC maximum power point average degradation will be the same no matter the modules, if the ageing rate is the same (%/year). However, since different modules have different one diode model parameters, the same ageing rate may lead to different behaviours for conditions such as temperature behaviour or low-irradiance behaviour. Then, if the plant has the same string layout, the mismatch degradation calculation will lead to the same mismatch due to the degradation (another loss that is due to ageing). But different stringing may lead to differences in the mismatch.
  19. Hi Laura, Thanks for the feedback, we'll be looking into the issue, it was not a bug known to us yet.
  20. Hi this tool uses monte carlo for the evaluation. Basically random trials are done every time. The values will only converge with many trials.
  21. No sorry, PVsyst only works with hourly simulation steps. This is why PVsyst can import sub-hourly data but will always eventually summarize the data as hourly data.
  22. @sujinlee If you have a 3D scene, in fact you do not need to use the "unlimited sheds" orientation. The "unlimited sheds" is a special orientation that allows you to make an rough evaluation of mutual shadings when you don't have a 3D scene at all. However, if you have a 3D scene, using it is the preferred option. The 3D scene will allow PVsyst to compute mutual shadings and shadings from other objects accurately. Nota bene: whenever you have a 3D scene that is active, you should choose the orientation "fixed Tilted Plane", and not "unlimited sheds". You do not want to count shadings twice. NB2: The orientation in "fixed tilted plane" will correspond to the average orientation of the planes. When using unlimited sheds, you can have only a single value of pitch: this is because it is a rough evaluation only.
  23. The most accurate is the second option. However if the system is too intricate to split into two (e.g. two orientations on the same inverter), I would suggest to group all modules as one orientation.
  24. Thank you very much for reporting this. I haven't been able to reproduce the error on a simple project. Could you give us some specifics on the project? I'd invite you to send us your project (Main window > File > Export project) at support@pvsyst.com.
  25. Indeed, you cannot establish a gap between each string length in a PVsyst 3D table or tracker. Only a homogeneous gap between each module, and an extra gap for the torque tube / longitudinal central spacing (central gap) if needed. I would suggest splitting the tracker into three trackers, already in the PVcase design. Is that an option for you ?
×
×
  • Create New...