Jump to content

André Mermoud

Moderators
  • Posts

    1994
  • Joined

  • Last visited

Everything posted by André Mermoud

  1. The nuVco may either be the result of the one-diode model (and it depends itself on the temperature), or you can specify the value given by the manufacturer. See our FAQ How to adjust the Voc temperature coefficient ?
  2. I will correct it for the next version 5.72
  3. I don't know. I can't reproduce this problem. When puttin 1° for the azimuth, it appears correctly on the report.
  4. This comes from nowhere: you can put its value to 0 if you want. The value given here is just a default for a usual value. This represents the cost of the capital in general. Even if you don't perform a loan, you perhaps would like that your inversted capital yields some annual profit. This is equivalent to an interest which would have been obtained if you had invested your capital on the market: perhaps you want to recover this and it should be included in the final price of the energy.
  5. For the first table (null anywhere), you have defined a tracking system with backtracking strategy. By definition, this mode avoids any mutual shadings, so that the shading factor (on the beam component) is always zero. In this table the orientation of the trackers is adjusted for each position of the sun. However the shading effects on the diffuse will not be 0 (see our FAQ How is calculated the shading loss on diffuse with tracking ? The second table seems to be quite correct, corresponding to an obstacle at south of your system.
  6. Your 2 fields are on the same orientation, therefore you don't need to define heterogeneous fields. In the "Orientation" part, you should simply choose "Fixed tilted plane". Then, choosing to define "PV planes in sheds" is quite correct in the 3D shading part. You can construct any number of "PV planes in sheds" objects in your system, provided that you have the same orientation and a sufficient area for putting all the modules you have defined. NB: When you choose "Heterogeneous fields", the 3D shading construction waits for 2 fields (or groups of fields) in 2 different orientations.
  7. There is no limit, the calculating time will simply increase, perhaps becoming prohibitive. And this doesn't depend on the total Power of the system, but on the number of "tables" (elementary mecanical rectangles receiving PV modules). For a 5 MW plant and reasonable tables sizes, there should not be problems with the version 6, where the shading factor calculation has been optimized.
  8. There are indeed several "new" performance reports about the IAM. However this measurement is rather difficult to perform with accuracy, and there are high discrepancies between the results of different laboratories. I can just propose my own theoretical calculations, according to the Fresnel's laws, for a standard flat glass without Anti Reflective dispositives. IAM Fresnel calculation taking 2 reflexions into account, compared to ASHRAE parametrization. I took 2 reflexions into account, i.e. the first Air-glass interface, the reflexion on the bottom of the glass side (against the PV cells), and the secondary refraction from glass to air. The next contributions are completely negligible.
  9. For the first problem of disposition: Putting modules in several orientations on a same shading object is really not easy to do, and we decided not to allow this. This is a relatively rare case, and it doesn't justify the big amount of development. However you can always redefine your planes as independent rectangular areas, for portrait and for landscape modules dispositions. For the area calculation error: I will check in the program For the third problem of deformation: This is only a display problem, the filed area itself is not affected. We will also check this for a next version. By the way we are just elaborating a tool for the direct positioning of modules during the 3D shading development stage. It will become possible to redefine the polygonal field as the envilope of the real modules, positioned by mouse.
  10. The far shading losses are indeed depending on plane tilt. When the modules are at low tilt, the losses arise with a higher incident angle, and the loss applies to a lower beam irradiance amount (due to cosine effect). With a high tilt, the shades apply with a lower incidence angle, when the sun's rays are more perpendicular. For understanding this intuitively, you can take the exrtreme cases of an horizontal plane (which "sees" the horizon line quite marginally) and a vertical plane, which will be affected by low sun's height, when it should be very well irradiated.
  11. Thank you for the suggestion. This is indeed on our ToDo list since a long time. But not at the top, sorry ... In the present time you can - export (copy/paste) the Tables of monthly values in EXCEL, with your chosen output values, and compare them in EXCEL. - use the "Batch Mode", which allows to perform several simulations with different parameters in one operation, and directly compare the results in EXCEL.
  12. I am indeed preparing a multi-orientation option for the next version 6.13 of PVsyst (up to 8 different orientations). With a shading calculation specific for each orientation, without any angular restrictions between planes as previously. "I'm not a programming expert, but I would imagine that a small piece of code would be able to dissicate a 20 orientations project": I'm working on this implementation since more than 2 months. I can confirm that this is not "just a little bit of code". It is a very deep improvement, which involves namely many user dialog issues. It affects all parts of the software (orientation, system, shadings, module layout), and I'm really not sure that this will work perfectly just from the first issue.
  13. The meteo data are the irradiance as measured at ground. They include the cloud losses of course... If you want to evaluate the cloud losses, you have to calculate the "Clear day" model ("Tools" / "Tables/Graphs of solar parameters") and do the difference.
  14. I don't know what happens. Probably a corrupted file. Please check that in your project, the Project's site is well defined (with valid Monthly data). In versions before 6.12, some manipulation could lead to a corrupted project's site. Then, the project's site is used for the orientation optimization in the "Orentation" part. If corrupted, you have to destroy and recreate the project's file *.PRJ. This will not affect the calculation versions already constructed (with the same filename).
  15. Sorry, it is not possible in the present time. Developing this possibility is on my ToDo list.
  16. OK, I will check this in the program. But please admit that this will have a marginal effect...
  17. In PVsyst the final yield is meant as the net energy delivered to the grid (produced - consumed). The not-operating loss (by night) is apparent on the loss diagram as parts of the transformer MV losses and the eventual auxiliaries loss (if arising by night). If we don't include them in the final yield, we should represent them as an input arrow representing an input gain drawn from the grid, which may be confusing. And still more confusing if we consider that these losses arise indeed during the full operating time (not only the night).
  18. Sorry, this has not been completely managed in the PV module definition yet. These values should be used as default inputs for the Module Layout part. The submodule partition indicates how the submodules (sets of cells protected by one by pass diode) will be arranged. For example with a 72 (6 x 12) cells module: - "In length" means that the submodule is divided into 3 longitudinal bands of 2x12 cells, - "In width" means that the submodule is divided into 3 transverse parts of 6x4 cells, - "Mixed" would mean a crossed arrangement (for more diodes or cells). I will probably suppress this unprobable possibility. I will put a little drawing according to the user's choice. For a future version ...
  19. Each point of the graph represents the production of one day. On the x-axis, you have the daily irradiation in the collector plane [kWh/m2/day] On the y-axis, you have the system's production [kWh/day] For Grid-connected systems, this is usually very linear (points below correspond to days with special losses like shadings or system unavailability). You have often a curvature in the upper part, corresponding to higher operating temperatures in summer. For Stand-alone or pumping systems, it is much more instructive: a plateau indicates that the storage is full: if the plateau is low (begins very early), your storage (battery or water tank) is not sufficient: for many days the production is limited by the full filling of the storage. A well-sized storage will give a little plateau in the upper part of the graph.
  20. When you are in the project's definition dialog, you have a button "Albedo-Settings" Pushing this button you have the item "Limit overload loss for design". This defines the amount of overload energy you accept to loose over the year. The help is available from anywhere in the software, by typing F1 (or sometimes little orange questionmarks for more targeted answers).
  21. When you define heterogonous fields, you may define a sub-array in one orientation, a sub-array in the second orientation, and a sub-array "Mixed" in which some strings are in the 1st orientation and other ones in the 2nd orientation. Only the "mixed" sub-array implies a combination of the I/V characteristics observed in both orientations, and the result is according to the total nominal power if the "mixed" sub-array. Now the shading calculations have nothing to do with this. The shading factor is calculated once for the whole system, and applied identically to irradiances in both orientations.
  22. This is normal: even with backtracking you have a shading contribution on the diffuse. Please see the FAQ How is calculated the Shading Loss on diffuse with tracking systems ?
  23. There is nothing to be fixed. It is just a new (enhanced) behavior of the program.
  24. I had fixed this problem in a previous version (I don't remember which one). Please update to the latest one.
  25. Yes of course the row-to-row is calculated in PVsyst. There are two ways: - a direct analytic calculation, in the "orientation" choice, option "Unlimited sheds". This is valid under the hypothesis that your rows are "infinite" in length, that is we can neglect the edge effects. - the elaboration of your system in the 3D near shadings tool. For not too big systems this will allow to use the "Module layout" option for an "explicit" electrical loss effect. For the optimization: see What is the sheds shading optimum?.
×
×
  • Create New...