Jump to content

Michele Oliosi

Moderators
 View Profile  See their activity

  • Posts

    743

  • Joined

  • Last visited

 Content Type 

Everything posted by Michele Oliosi

  1. Michele Oliosi
    Hi indeed, I think you don't need to add up voltages, the strings are basically in parallel.
  2. Michele Oliosi
    The horizon model has been improved in 7.3.3 and it should also cover the bug we mentioned. The results may still differ a little from 7.2.21 but this is due to the improvement: we now consider more correctly, within each hour, the fraction of the sun trajectory that is behind the horizon. Please let us know if you experience anything strange agin.
  3. Michele Oliosi
    Thank you for your comments! Okay, thanks for the remark. We will then have to review again the different data sources and see what usable data we find. We'll see to keep up to date on this. Indeed physically it is not so complex (although one needs to be careful with a few models, for example the thermal one as you mention). But purely in terms of code we would have to change a lot of things. As mentioned, we are actively working on the subject of subhourly clipping, since there are still few questions to be elucidated. We will present further conlcusions of our studies at PVPMC2023, and the poster should be made available online. With these studies we are gaining a lot of new understanding that should also help in the longer term to transition to sub-hourly simulations, if necessary.
  4. Michele Oliosi
    Hi, The Orientations management works in the fixed tilt tables case, but not for trackers. At the moment in PVsyst, you can have only a single tracker orientation. If you want to proceed by considering the average tracker angles nonetheless, you can change the following advanced parameters (home window > Settings > Edit advanced parameters): This should help you bypass the error.
  5. Michele Oliosi
    Glad I could help !
  6. Michele Oliosi
    Glad I coud help ! In the release notes: Basically there was a correction to the way the horizon is accounted for, in the hours in which the sun passes behind the horizon line. Consider hypothetically a tall mountain peak, behind which the sun passes in less than one hour. Before the update, the corresponding hour would have had no far shading losses. Indeed one considered the beginning and the end of the hour to verify whether the sun passed behind the horizon. We now account for the time span behind the horizon. even though it is only a fraction of the hour.
  7. Michele Oliosi
    Indeed that is correct.
  8. Michele Oliosi
    I agree with @dtarin Since you have selected "limit applied at injection point", if there are sufficiently high losses between inverter and the injection point, the power will be too low to be limited.
  9. Michele Oliosi
    it's the colloquial name for a hourly output file (8760 hours in a year) see https://www.pvsyst.com/help/output_file.htm
  10. Michele Oliosi
    If you have a .MET file, you can use Main window > File > Import components > From a folder.
  11. Michele Oliosi
    Only in the presence of irradiance. By definition there will be no thermal losses at night.
  12. Michele Oliosi
    Hi the help page will be updated after our upcoming patch 7.3.3. Hopefully it will make things more clear. The basic idea is that any partition that is partially shaded will contribute as if it was completely shaded. That's what is meant in the text when saying "become inactive". There is no notion of "shaded string" when using the partition model, only of shaded partition. If you have only half the modules in the string that have the same shading, the resulting electrical shading loss is difficult to model with the partition model. There are two cases: the string is on a single table in a 2x15 configuration. This is in general fairly well modelizable with the partition model. Depending on the type of module (half-cut cells or not) and its orientation (landscape or portrait) you may need to put a different number of partitions to model this properly. the string is on two tables in a 2x(1x15) configuration. In this case, there is not much you can do with the partition model to model this accurately. In general however, this situation is marginal on your whole system, so it is okay to assume that in "most cases" the shading is the same for the two trackers.
  13. Michele Oliosi
    This should be fixed in the upcoming update !
  14. Michele Oliosi
    Hi, I assume that the .pvsyst format is the same as our standard format: https://www.pvsyst.com/help/meteo_pvsyst_standard_format.htm I think you can just add the extension .CSV to your file name. You can then import it via the home window > Databases > Known format, and choose PVsyst standard format in the list. You should be able to import your file.
  15. Michele Oliosi
    By thermal losses we only account the losses due to the loss of efficiency when the module heats up during the day. Unless you are concerned with infinitesimal variations of temperature, since the thermal inertia of modules is about 10 minutes, you don't need to merge the heat transfer throughout the year, day and night to simulate in hourly steps. Considering the heat transfer within the hour is enough.
  16. Michele Oliosi
    No the batch mode doesn't allow to modify the horizon at the moment. It could be implemented at some point. The horizon line values are indeed truncated to the 1st decimal number. We consider this precision sufficient: note indeed that the sun moves of about 15° per hour. For the horizon: the 4th decimal number is what is used for all latitude/longitude evaluations. This means a localization of your PV plant to about 10 m, which is small enough for most systems.
  17. Michele Oliosi
    Hi @VUG, In the "module layout" mode aka "detailed electrical calculation", the half-cut technology is accounted by PVsyst automatically. However in the "partition mode" aka "according to module strings", you have to define the partitions as half the string by yourself. A string on one row should indeed be setup as two partitions.
  18. Michele Oliosi
    Dear Hossam, the cell temperature is calculated with the ambient temperature at each specific hour.
  19. Michele Oliosi
    In other words: The graph selected (Yearly, Summer, or Winter) has no impact on the simulation. What matters for the simulation are the Azimuth and Tilt values you have entered in Field Parameters. The graph shown by default (e.g. winter for stand alone systems) is not a recommendation. It just reflects what (we think) most stand-alone users are interested in. If you want to choose the tilt and azimuth that optimize the yield for the whole year, you can do so.
  20. Michele Oliosi
    @laurahin indeed my bad, i was using the term reemitted not really carefully..
  21. Michele Oliosi
    10 times the size of the system: it is an approximation of course. By size of the system you can take the distance between the two PV tables that are furthest apart. No sorry there is no tool to calculate the horizon profile. You would need to consider these objects in your horizon line manually, for example after having made some measurements. Example: there is a high rise building but quite in the distance, you can calculate the height above the horizon that the buildng would appear at.
  22. Michele Oliosi
    Hi since there are 7 inverters and 6 inputs of type 1 / 8 inputs of type 2, it is not clear for PVsyst how these are to be arranged. Here a possibility (but there could be others!) would be for example: - 6 inverters with one input of type 1 and one input of type 2 - 1 inverter with two inputs of type two. In this case you can prepare the following sub-arrays: - subarray of type 1, with 6 inputs -> assign to configuration 1 - subarray of type 2, with 6 inputs -> assign to configuration 1 - subarray of type 2, with 2 inputs, does not need the power sharing.
  23. Michele Oliosi
    Hi, Just a small comment on points 1 and 2: as a rule of thumb in PVsyst we consider that whatever obstacle that is at a distance of about 10 times the size of your system (or more) can be included in the far shadings. Since this depends on the size of the system, you can see how this also will make the point (2) less problematic.
  24. Michele Oliosi
    Hi, You are looking at an average/accumulated curve for the whole month, if I understand correctly. Simply put: on some days the available energy is not sufficient for the user. Some other days the energy is more than sufficient for the user. On average, there is more than sufficient for the user, but still some days the user needs to consume from the grid.
  25. Michele Oliosi
    In the bifacial model the working assumption is that the axis is in line with the table. This is an approximation, and the impact of it is very minimal compared to other sources of inaccuracy. Indeed, sometimes the axis center is a bit lower than the back of the modules in the horizontal position. In this case, for the "height above ground", you can take the average value of axis center and back of module height, that should give you a good compromise.
×
×
  • Create New...