-
Posts
2008 -
Joined
-
Last visited
Everything posted by André Mermoud
-
I don't know the kind of grid storage strategy you have used. However the grid storage treatment has been completely reviewed for the next version 7.4.6, namely securized for extreme parameters like very little or very big battery pack, very high load powers. This will be released at beginning of February 2024. In the previous versions, the definition of some intermediate variables was not so clear, namely EAvailB and EDirUse. In the new version, the final results should be close to the previous ones.
-
In the present version 7, you should gather some close orientations in order to not exceed 8. In the next version 8, to be released this spring, the number of orientations will not be limited.
-
The "Multi-orientation" option concerns full strings only. Although this would be possible with optimizers, it is not possible to define several orientations within a same string in the present time. This possibility involves a deep modification of the PVsyst simulation, it is on our roadmap, but will not be available before several months. Therefore in your first subarray with one only string, the "Multi-orientation" doesn't make sense. This should not appear in the possible options, we have to correct this. For the second question, the inverters list (specific to Huawei optimizers) only mentions the inverters equipped with optimizers. However this very special case of equipping one MPPT with optimizers and the other one without is not foreseen. It is not possible in PVsyst.
-
Don't worry, there is no impact on you other data. - The parameters concerning the Meteo data just enlarge a little bit the acceptability of data for exceptionnally sunny data. - The "inverter power is strongly oversized" allows to define systems where the inverter is very badly sized (more than 50% of the PV field). - The conditions on the P90 values for components uncertainty are indeed not very pertinent, we will put these default values at null in next versions.
-
First of all, this fraction doesn't make much sense. This completely depends on the system area you are considering for the shading loss fraction. It is not the same if you have a turbine on a field of 1 hectare or 10 hectares. The comparison should be done on the loosed energy itself (KWh loss). Now there is indeed an additional loss due to the flickering on the MPP tracking. But we don't have any information about this; this highly depends on the inverter's technology and tracking dynamic performance. It
-
The transposition model is obviously applied with the exact specified orientation. The values by 15° are simply for the table or plot presentation. However if you want an exact calculation of the GlobInc for your Meteo data file, you should use "Databases > Meteo Tables and graphs". Here you can choose "Tables" and the variable "Global tilted plane".
-
We don't have much references about the I/V curves degradation. The different publications are very contradictory. The Voc degradations is often reported as very low, but the Vmp is affected namely by the increase of the Series resitance. However it seems indeed that the degradation is mostly to be applied to the current Imp. In PVsyst, you may modify the Current degradation sharing in the Advanced parameters, topic "System design loss parameters, losses, shadings", item "Long term Pmpp degradation, current sharing" (#611). The value is now 50%, we will consider putting a value of 70% or 80% for this parameter in a next version.
-
If you want to measure the irradiance in the POA, you should choose an orientation for the solarimeter, corresponding to the average orientation of the concerned set of tables. However in your case it would be much better to measure the irradiance in the horizontal plane. In this way you only need one only solarimeter, and you can put more attention to the maintenance of this device. You could also consider measuring the diffuse component (DHI) as well, for improving the transposition. The accuracy of the transposition model in different orientation is sufficienly accurate.
-
How to run multiyear simulation with changing albedo factor.
André Mermoud replied to mohaned's topic in How-to
No sorry. You should perform these simulations explicitly without batch. NB: As the variations will not be very hight, you can just do 2-3 simulations and interpolate for missing years. I put this option on our roadmap. -
Yes, this is what I said.
-
Bifacial and Monofacial Panels in a same system
André Mermoud replied to Omama Zaheen's topic in Simulations
You can define a PV module by activating the Bi-facial feature, and specify a bifacial factor = 0. There is indeed a difference when simulating with the bifacial model (and Bifacial factor = 0) and without. The bifacial calculation includes a contribution for the reflexion of the near ground in front of the PV modules (named "Ground reflexion on front side" on the loss diagram). This uses the whole "mechanics" of the 2D bifacial model. This contribution cannot be calculated in a simple way. It depends on several parameters like the ground albedo, the height above the ground, the pitch, etc. It is neglected in the usual monofacial simulations. -
These parameters are applied to the MV wiring, at the output of the transformer. The wiring before the transformer is defined in the frame "AC wire loss Inverter to Transfo".
-
Using Bifacial and Monofacial Modules in different Sub arrays
André Mermoud replied to vijaykrishna.ds's topic in Simulations
No, this is not possible in the version 7. The bifacial model is calculated for the whole system. This will be possible in the version 8, to be released in spring of the next year 2024. -
This optimization tool provides a coarse evaluation for the estimation of your situation when you are choosing your plane orientation. This evaluation is depending on the period, and the season months are chosen as function of the hemisphere (sign of your latitude). However the seasonal dependency is much lower at subtropical latitudes. It is perhap more related to the mussons. If you need a more accurate optimization (and explicit choice of each month), you should use the dedicated tool "Tools => Transposition factor". NB: you are living in a strange region, where the summer is covering the whole year (April to March).
-
The design temperature for defining the max. Voc value (to be compared to the VAbsMax of the inverter and the PV module) should be the minimum temperature measured during the day. This is a safety condition, for avoiding overvoltages damages at the inverter input. This is specified in the norm IEC TS 62738 (2018), paragraph 7.2.1. Now for such low temperatures, the one-diode model doesn't work well. For many modern modules, the temperature behaviour is not quite correct below -10°C. In this case you should consider a linear increase of the Voc value as function of the temperature instead of the one-diode model. You can do that by: - defining a customized muVoc value for your PV module (page "Additional data > Secondary parameters") - in the "Project's settings", specify that your design should use this value (open "Project's settings > Design conditions", and choose "muVoc value: from specification".
-
String configuration bug with Solaredge
André Mermoud replied to Pranav Maheshwari's topic in Problems / Bugs
I have reconstituted your configuration. The problem is that when defining the inverter list, you have the following warnings in orange: Sub-array #1, NInv no match Sub-array #3, NInv no match This should produce an error, which doesn't appear when you do the design in this window, but appears when reopening the variant: The fact that this message doesn't appear when designing the system is indeed an mistake, but the specified configuration is well stored on the file. You should simply press the button "Adjust subarrays" and everythis will be OK. -
The data specified on the datasheets of these 2 battery blocks RESU7H and RESU10H are indeed incoherent. These correspond probably to 2 or 3 modules type RESU 3.3, i.e. 2x or 2x 51.8V with 63 Ah, with a DC-DC bidirectional converter for a 400 V external voltage. . This is not implemented as such in PVsyst. As a workaround, I have defined these devices as batteries of 108 cells in series (400V) , with reduced capacity (17 or 25 Ah). These will be available in the next version 7.4.5 of PVsyst.
-
MAX CHARGING POWER TOO HIGH-HIGH VOLTAGE BATTERY
André Mermoud replied to JaviC's topic in Simulations
Please have alook on your first dialog (top of your first post). You have defined a battery pack of 512V / 103 Ah, i.e. 52.7 kW "gross". You have defined a PV system which will deliver 5.4 kW under full irradiance, corresponding to a full charging in roughly 7.8 hours). This is quite correct. For this Power limit you could even define a smaller battery pack, corresponding to one day of overload (see "clear day excess energy" on the next page). Now on the page "Peak shaving", you have to define the "Battery input charger" power which will charge the battery. Here you have probably defined a device of 50 kW, which is highly oversized. You could define a charger of, say, 6 kW, and everythig will be OK. Same remark for the "Battery to grid" inverter power: this power will determine the speed at which you will discharge the battery during night. -
The number of cells is defined on the page "Size and technology". In your case, the Vmpp = 39.27 V at STC, indeed corresponding to 66 cells, i.e. a voltage of 0.595 V/cell, which is quite correct. Now when you are using the model under different irradiance and temperature, the Voc is obviously different (here higher than at STC as the temperature is lower then 25°C).
-
Yes indeed, we are aware of this problem. For the version 7.4.3, we have implemented the new complex rules specified by Huawei, for the implementation and use of their optimizers. For doing this, Huawei provided 2 very different protocols, for low power (450 and 600W) and high power(1100 – 1300 W) optimizers. The protocol for high powers specifies that you can only connect one string per MPPT. What we did and is on the basis of our new implementation. We thought that this statement was also valid for the low power optimizers, and we developed this complex tool with this hypothesis. But it appears that this is not the case. The only way of using your 450 W with several strings per MPPT is to revert to the previous version 7.4.2. However the versions 7.4.2 is not compatible with the patchs 7.4.3 (or 7.4.4, 7.4.5): you cannot use them in parallel, you will have to uninstall the V 7.4.3. If you really need to keep parallel versions, you can install the version 7.3.4, which may be installed/used in parallel with the versions 7.4.3. This will be corrected in a version 7.4.6, to be released in January 2024.
-
In PVsyst, all the AC losses expressed as percentages are referenced to a same power. This power may be either the STC power of the PV array, or the PNom output limit of the inverters. You can modify this choice in the Project's settings (button at top of the project's dialog). You can have a look on the help "Project design > Array and system losses > AC ohmic losses: reference power".
-
No, the LID loss only arises with P-type wafers.
-
First: the fact that the battery pack is provided by a manufacturer doesn't mean that this is correct. The definition of batteries in PVsyst is complex, and I have seen several BTR files from manufacturers which were erroneous. I am working on this Grid systems simulation with storage just now, and I have discovered errors is some specific cases, namely when the battery has several "blocks" in parallel, and with disproportioned loads or battery packs. You should wait for the next version 7.4.5 (to be released in December 2023) for a complete revision of this simulation in any case. NB: The fact that the EBatDis = 505.48 kW when the discharging limit = 500 kW is normal, as the 500 kW is the output of the inverter, when the EBatDis is the input. You have to account for the inverter efficiency.
-
Sorry, we don't know any problem of this kind. Please check that in your first simulation, you have the same degradation parameters than for the Aging tool. If so, please send your full project to support@pvsyst.com, with a detailed explanation of your problem.