Jump to content

Robin Vincent

Moderators
  • Posts

    43
  • Joined

  • Last visited

Everything posted by Robin Vincent

  1. Sub-hourly simulation is a simulation with a time step lower than 1 hour. It may be useful to correctly account for non linear phenomenon such as clipping and curtailment. It is currently not directly available in PVsyst, even though workaround exist to run pseudo sub-hourly simulation https://www.pvsyst.com/wp-content/pdf-tutorials/pvsyst-tutorial-v8-pseudo-sub-hourly-simulation-en.pdf or to have a better clipping correction estimation https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html?h=clipping. In both case, sub-hourly weather data is necessary.
  2. Please contact the support by email at support@pvsyst.com with your project (project => export project) so we can have a better understanding of what is happening.
  3. The results export is restricted to the same time step as the simulation, which is set to 1 hour. Smaller time steps will be available once the sub-hourly simulation is.
  4. No, the simulation itself is still hourly-based. We only extract additional info from sub-hourly weather data to correct the clipping losses.
  5. With unlimited sheds, pretty much all the parameters you mentioned will impact the near shadings losses. You may be able to find more detailed information in the help page for diffuse losses with tracking systems : https://www.pvsyst.com/help/project-design/shadings/calculation-and-model/diffuse-losses-with-tracking-systems.html#tracker-diffuse-shading-definition-window-from-version-730
  6. This issue must have been fixed by now, in PVsyst 8.0.2.
  7. The backtracking strategy avoids direct mutual shadings, but not the other irradiance components. If you extract the simulation results with all the near shadings variables, you should be able to see that the Beam loss due to near shadings (ShdBLss) are equal to 0, but not the diffuse (ShdDLss) and albedo (ShdALss) components.
  8. Yes, all you need is a text file containing all the commands you want to pass through. Each command must be on its own line. For instance, to convert a weather data file, you can set up a text file (TestCLiCmd.txt) containing the following lines : -icf:path/file.csv -imf:path/file.MEF -isf:path/file.SIT -omf:path/file.MET And then simply run the command : PVsystCLI convert-meteo -cof:TestCLiCmd.txt from the same directory.
  9. PVsyst integrates a set of rules, as requested by Huawei, to authorize or not some inverters / optimizers combination. A side effect is that if you create your own inverter it will not be compatible with any Huawei optimizers. You'll be able to use Sun5000 inverters with MERC optimizers in PVsyst8, which should be released in a matter of days or weeks.
  10. Dear R. Polášek, Thank you for bringing up this issue. We are aware that the multi-string attribution on a single MPPT with Huawei inverters/optimizers currently has some limitations. If you're working with just one subarray, this shouldn't pose any problems. However, given your situation with multiple subarrays, unfortunately, it will not function as expected. We are actively working on a fix, which will be implemented in PVsyst V8. Until then, you won't be able to simulate your project as it is currently configured. As a temporary solution, we recommend ensuring that each inverter is connected to only one subarray. This should allow you to proceed with your simulation in the meantime.
  11. There is no real justification for limiting the number of periods to 5. It will be changed in a future PVsyst release.
  12. We cannot help you in the definition of the periods themselves, as they are only related to your project. This information must be provided by your client or be part of your simulation assumptions.
  13. @sarah95 When setting the unavailability factor to default, PVsyst will split the total duration onto 3 separate periods of equal length. These periods are randomly selected when you enable the unavailability factor for your different variants the 1st time. Thus, two variants using the default (random) unavailability period may end-up with very different unavailability losses. If you consider the unavailability of both systems should be the same, you can specify the same date, time and unavailability duration manually. @Auxi Madero In your variant, detailed losses ==> unavailability you can set a unavailability probability to 5%. With the rest of the settings unchanged, it will generate three random unavailability periods for a total duration of 5% of the whole year. You can find more information in the help page dedicated to the topic : https://www.pvsyst.com/help/index.html?unavailability_loss.htm
  14. Dear Krishantha, To properly answer your question, you need to contact support@pvsyst.com and share your project with us.
  15. Dear sarah95, The unavailability figure defined in PVsyst represents the time fraction during which the system won't be able to produce electricity. The unavailability losses are not directly linked to the unavailability fraction, but also to when the system is not available (day, night, summer, winter, ...). Thus a same unavailability duration can give dissimilar unavailability related losses. You can find more details on our help page related to the subject : https://www.pvsyst.com/help/index.html?unavailability_loss.htm
×
×
  • Create New...