Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by julmou

  1. Does this scene/terrain exist somewhere or could be imported from somewhere?
  2. Do you think having a database for tracker systems could be relevant for PVsyst?
  3. I still don't quite get this... Thanks in advance :)
  4. Hello, Here is my thought process: I thought Meteonorm was the most accurate in terms of irradiation data (mixture of satellite and weather stations data, accumulated over many years, great algorithm etc), so I was mostly relying on it to do my simulations. Recently, I've been studying a site near Canberra (Australia), and these are the various annual Global Horizontal Irradiation I get depending on the source (always using same coordinates): Meteonorm 8.0 -> 1915 kWh/m2 PVGIS 5.2 (ERA5) -> 1670 kWh/m2 Global Solar Atlas / SolarGIS -> 1750 kWh/m2 NASA-SSE -> 1693 kWh/m2 SMA Meteo. data / Sunny Design -> 1753 kWh/m2 As you can see, they are ALL around 1700, EXCEPT Meteonorm... which bothers me as I thought it was the most trustworthy. Which is why I would be happy to share experience from fellow developers about your experience regarding accuracy of different weather sources. When importing this Meteonorm data in PVsyst, it shows "Sat=93%" which means 93% of the data are from satellite sources, and only 7% from weather stations. I'm guessing, the bigger the part with actual ground stations (so the lower the sat. part), the better? I'm also guessing this has to do with the site being in the Southern Hemisphere. I'm pretty sure Meteonorm is great with Europe, but if some of you guys have feedback on the accuracy of these various meteo data sources in the S. Hemisphere, I would be very interested. Because now, I'm really doubting if I should keep using Meteonorm at all here (I get 1716 kWh/m2 if I average the 4 other sources, so Meteonorm in that case has a deviation of 12% from that value!!).
  5. OMG, yes, it's so simple it's almost embarrassing... I was convinced the options were not available in the menu anymore. But all I had to do was to keep the Orientations management tool open đŸ˜„ To my defence, when I wanted to do my selection on the scene, I would try to reduce the Orientations management dialog, which would in turn reduce the whole PVsyst program in the windows taskbar, so yeah, I ended up closing the dialog every time I wanted to interact with objects from the scene, but by doing so, the Orientation options would disappear from the right-click menu. Anyway, solved now! Thank you!
  6. Good morning, So, I was able to create the terrain of my site of interest in PVsyst. This website EarthExplorer from USGS now provides Digital Elevation data (SRTM) at a resolution of 1 arc-second for the whole globe. Using a GIS, one can reduce the downloaded data to a smaller site of interest, and then convert them into XYZ data, which can then be imported into PVsyst. Screenshot below of the resulting ground object in PVsyst. Now, I wanted to practice the Orientations Management tool, in a similar manner to the "Use case : Complex PVsyst scene" in the Help. So I created an array of tables, which follows the ground slopes. Quite naturally, I get quite a number of different orientations detected. To homogenise of all this, I select the whole array and try to create a new orientation based on the selection. To my surprise, the option is not available anymore... (contrary to what is shown in the "Use case : Complex PVsyst scene). See the 2nd screenshot below. When right-clicking the selection, the "Create orientation from selection" or "Add to orientation" options are nowhere to be seen... I think the management of the orientations is an essential function of this program. I'm quite surprised we can't manage them anymore as shown in the Help. Have these options been removed by choice or is it a bug?
  7. Good day, While learning more about the "Near shadings: Orientations", I would very much like to get some practice on complex terrain cases. In the Help, we see a very interesting example titled "Use case : Complex PVsyst scene" -> is there a way to get hold of the modelled scene in there? So we can do the case ourselves too. I couldn't find it in the templates, neither in Sketchup 3D Warehouse. That would be amazing to have this scene. Or perhaps even just the XYZ .csv file, for the terrain ? Thank you so much to anyone in advance :)
  8. Just a quick question, I couldn't find the answer anywhere: when we define the Pnom threshold for a Master/Slave configuration, is the value a percentage of the Pnom power of the inverter? Or is the kW value? (see screenshot below)
  9. I'm not sure if I was clear with this suggestion. I just think the ArrayON variable (Duration when the PV array is producing) would be a really good indicator to give us an idea of how much the PV array is disconnected during a year (when battery reaches full capacity). By comparing different simulations, we would be able to compare in which configurations the PV array is the least disconnected (so more direct use). But at the moment, the ArrayON variable is still counting even when the "Array Current" and "Effective energy at the output of the array" drop to zero (in practice, PV array not producing anymore, so ArrayON should stop counting).
  10. Good morning, In every single project with Grid Storage and Peak Shaving strategy, one of the values displayed under "Peak shaving System Information" is always at 0 kWh... It's the "PV array daily production (summer clear day)". See snapshot below for illustration.
  11. Good morning, When sizing/creating new Stand-Alone Projects, and when the project is bit more complex, I find two tools missing when sizing the PV array which would be really useful. These tools are present in Grid-Connected version but not the stand-alone. Having several sub-arrays -> it seems we can only have one array with a Stand-Alone project. However, we can easily imagine several controllers, each in charge of a different section of the PV array, and they would have different SOC thresholds, for instance disconnecting only one sub-array when reaching full battery, instead of disconnecting the whole system. Similarly, if we have MPPT controllers, we can have several sub-arrays with different orientations (their input voltage is managed by separate controllers/converters, but the converter output voltage to the battery would be the same). The "Show sizing" graphic tool, which shows us the Vmpp min and max and the Voc etc -> really useful to see visually the limits of our system. To illustrate, please see below a screenshot of the PV array sizing with Grid-Connected, and with Stand-Alone. The two mentioned tools are highlighted. Grid-Connected: Stand-Alone:
  12. Good morning, In a grid-connected system, when using storage with a "Weak grid islanding" strategy, we have the define a grid unavailability profile. We can generate it randomly and export it as file, which is great, or create a file of our own. For the test, let's us export a file and try to reload it. A CSV file is created/exported, as seen on the picture below. So, we can try to load the file by selecting "Input mode" -> "Defined from a file", as seen below, then click OK, everything normal until here. But then, if I go back to Storage (to change a SOC threshold value, or the sizing of the battery pack for instance), then the software crashes... systematically. Hope this can help to identify and solve the problem. Regards, Julien
  13. Good morning, I've noticed in some instances the big arrow from the Loss Diagram is not displayed properly. Here are two cases: With a Grid Storage with "Weak grid, islanding" strategy (here, DEMO residential with storage, adapted for weak grid islanding). As you can see the resulting Diagram Loss is quite different from how it's supposed to look like in the Help. Obviously one side of the main arrow is missing, but also the kWh value for the "Energy from the grid" is brought down next to "Missing" which makes it really confusing. And we don't have the % for the "Energy from the grid" Grid storage with "self-consumption" strategy, but where the option "Allows solar injection into the grid" was deactivated (DEMO Residential, self-consumption with storage, NOT allowing injection into grid). Here also, one of the side of the main arrow is missing. This is also visible in the Report.
  14. Good morning, From PVsyst Help: From André Mermoud in a previous post: All solar chargers sold on the market now are either PWM or MPPT. We know that, with PWM controllers, when the battery reached the defined maximum SOC or voltage, instead of disconnecting the array, the controller will modulate the width of the pulses in order to maintain a constant voltage on the battery that is not too high and stay below the Gassing region. This modulation will also limit the charging current into the battery. In the end, this "floating mode" prevents the PV array to be disconnected, and this one will be able to provide just the current needed for the load => we maximise the use of the PV array (direct use) and limit the use of the stored energy (thus increasing battery lifetime). Similarly, we know that on normal solar inverters, if we have a grid limitation, the inverter is able to displace the operating point on the I/V curve, so that the power delivered stay below the grid limitation. MPPT solar chargers (DC converter) are now also able to adjust I/V operating point when the battery is full, so that the PV array can keep running and supply just the right amount to meet the load: search Google for "mppt float voltage" or "mppt float charge" to see that it is now a well-known and common feature. So my question is just: is there a planned update/upgrade to incorporate PWM floating mode and/or MPPT floating mode into Stand-Alone systems? Julien
  15. Hello, I've noticed a small bug. If I go to a big project like 25 MWp (own project), where the results in the loss diagram are displayed in GWh, and then I go back to a smaller project (9 kWp, DEMO Residential Geneva, Self consumption with storage), and go to Detailed results and Loss diagram, the results values stay in GWh and they indicate 0.00 or 0.01 GWh... The only option to bring it back to normal is close the software and reopen the small project again first. Here you can see the screenshot where all values are around 0.00 GWh: And here you can see the same project with values normally displayed in kWh:
  16. Good morning, In this section of the Help "Self consumption with storage", we find some valuable information regarding the sizing: Therefore, we want to be able to adjust to "Max. charging power" and the "Max. discharging power" values, in the "Storage" dialog box of the system, in the "Self-consumption" tab, so that we get appropriate charging and discharging times. However, I find very tricky that, as we change these values, we have no indication of how the charging time is changing. I mean, I know we have some charging and discharging time information in the previous tab "Storage pack", but they are fixed values and don't change as we adapt/play with the "Max. charging power" and "Max. discharging power" values. I think it would be very useful to have an indicator in each boxes ("Battery input charger" and "Inverter Battery to user's consumption") that gives the charging and discharging times and updates the value as we play with the before-mentioned parameters. I don't think it should be too hard, since we already get the information as a warning message when we enter too high values (e.g. "The Charging max. power (10.0 kW) is too high. It corresponds to a battery charging rate of C1.2 (1.2 hours)" or "The discharging max. power (15.0 kW) is too high. It correspond to a battery discharging rate of C0.8 (0.8 hours)"). I just think it would be really helpful to have the information constantly.
  17. Good morning, I am using the DEMO Residential Geneva Project, with the variant VC5 "Self consumption with storage". I have a question about some of the information when we open the "Storage" dialog box. Under the "System information" part, there is "Charging Time during full sun conditions". Now what are these "full sun conditions" exactly? The STC conditions (1000 W/m2, 25°C) or the summer clear sky conditions? Because, on the next tab "Self-consumption", we have the PV array max. output power (clear sky) at 7.79 kW, which would take the 10.7 kWh potential stored energy 1.4 hours to recharge, not 1.2 hours. But under STC conditions, the 9.0 kWp of the array would produce 9 kW which would indeed charge the 10.7 kWh in 1.2 hours. So I just want to clarify, because the "during full sun conditions" confuses me... Specially because in the same tool, we also see the "(summer clear day)" and "(clear sky)" terms. What does "full sun conditions" mean in this case?
  18. Thanks so much for the explanation :)
  19. Hello, I noticed a few times, in the Simulation Report with Stand-Alone project, the PV module and Battery manufacturers always show "Generic", even when it's not. For example, I have here a system with SunPower PV modules and Sonnenschein Batteries, but they are displayed as Generic in the report:
  20. I don't argue that at all. I just think that, when this is the case (array disconnected because battery full), then the variable ArrayON (Duration of the PV production of the array) should also reflect that. At the moment ArrayON just counts the hours as long as the sun is out. I think ArrayON should not count the hours when the array is disconnected and not producing any current and energy (as I tried to illustrate above -> i.e. when the array current or when the effective production of the array is zero). Also, I haven't tested with MPPT or DC-DC converter yet. This is just with Direct Coupling.
  21. Good morning, There is something that I find tricky to evaluate with stand alone projects, and that is highly influential on the entirety of the system. I noticed that with "oversized" PV array (PV modules cheaper so most systems tend to decrease cost on battery by having more kWp which would provide current even under cloudy conditions), there's more wear on the battery because it is actually used more. The reason being that it reaches the max. SOC more often -> and we have the charging thresholds at 90% (triggered OFF -> array disconnected from battery) and at 75% (triggering back ON -> array reconnected) -> so what ends up happening is that the PV array is disconnected often, thus the load is often working on battery only, without direct use from the PV array -> therefore, even though we have plenty of energy available, the battery wears down more quickly. See below snapshot of the Charging Thresholds and Hourly Graphs showing the PV array disconnecting: NB: this is with direct coupling Anyway, where I am getting with this, is that it would be great to have a variable helping us estimate the importance of this phenomenon, such as how many hours the PV array is actually ON every day -> the ArrayON variable (Duration of the PV production of the array) should be perfect! Unfortunately, ArrayON always have the same value as long as the sun is out -> which is where I think it's wrong and I can only suggest to re-assess this variable for stand-alone systems -> when the Array Current is 0 (not delivering any current to the system, PV array disconnected at the charge controller level), then ArrayON should also be 0 ArrayON in "normal behaviour" (charges battery and provides direct energy to the load): ArrayON when the PVarray is disconnected -> still ON, even when the array is not producing anything Thanks so much for reading this (a bit longer that I intended it to be sorry). Let me know what you think. Julien
  22. Hi, I was just randomly checking this tool again when reading my notes, and it seems that with the new version of PVsyst (7.2.15), now I can't even select a type of inverter anymore within the Inverter Modelisation Analyzer (see above post).
  23. Hmm, I didn't realize we could "count" the number of cycles through the energy used by the battery. When you say the "battery use" energy in the loss diagram, do you mean this one (circled in red) ? In that case, we have: 8.0 kWp -> SOWCycl 88.2%, SOCmean 82.4%, Battery Charging/Discharging energy 5540 kWh (7611 kWh eff. array energy, 72.8% stored, 27.2% direct use), SF = 1 6.4 kWp -> SOWCycl 89.1%, SOCmean 82.3%, Battery Charging/Discharging energy 5088 kWh (7527 kWh eff. array energy, 67.6% stored, 32.4% direct use), SF = 1 4.0 kWp -> SOWCycl 92.6%, SOCmean 43.3%, Battery Charging/Discharging energy 3733 kWh (6799 kWh eff. array energy, 54.9% stored, 45.1% direct use), SF = 0.915 3.2 kWp -> SOWCycl 93.9%, SOCmean 33.9%, Battery Charging/Discharging energy 3070 kWh (7611 kWh eff. array energy, 56.4% stored, 43.6% direct use), SF = 0.728 => for the same given yearly load, and with the same battery size, the bigger the PVarray the higher the part of the energy transiting through the battery (not sure I understand why that is btw, especially between the 8 and 6.4 kWp, the part of direct use decreasing as we increase the Pnom...) and thus the more wear in the battery. I guess where I'm coming from is this part of the Help telling us that a low average State of Charge could be damaging for the battery (snapshot below). So in my mind, it was better to have a SOCmean of around 60% than one of 30%. Which is why I was totally surprised to see the opposite in the simulations, the lower the SOCmean, the less wear/damage I have on the battery... (SOCmean circa 30% -> SOWCycl 94% !) It definitely feels quite contradictory.
  24. @André MermoudSorry to raise this again, would you mind helping me regarding my post from the 12 May (where I compare different tracker PV plants at different latitudes) ?
  • Create New...