All Activity

Summarizing what we found with the data: the diffuse was not the same depending on the time granularity. This is likely a problem that the weather data provider should address. In PVsyst if the diffuse data is different, then the simulation results will be different.

That warning might be a bug, would you be able to send your .csv data and .MEF conversion file to support@pvsyst.com ? Did you read the dates on file or use the sequential dates option? But in any case, the PVsyst convention is that 31/12/20 at 23h00 corresponds to 23h00-24:00 so your file should indeed be complete

Dear Sara, You need to adjust your PV area to make it 1,100 m², but you also need to know its position on the façade. At first, you have two orientations — one for the façade and one for the rooftop. So, you need to create two orientations, and in the system, create two sub-arrays where you can assign the appropriate PV modules for each orientation. Then, in the 3D scene, when you place the PV modules, you need to select the initial orientation. If the PV module brand or size is different, Near Shadings will automatically detect it. What’s important to know is that Near Shadings is used to calculate shading losses on your PV surface. Once calculated, it applies the percentage of shading losses to the final simulation results. Regards,

There is already a huge amount of literature on this topic. As a start I would recommend [1]. As is usually the case with models, the parameters have been tuned for certain locations, so it makes sense to test them at many locations. In general one can say that Erbs usually overestimates the diffuse component under clear sky conditions, and this bias is severe (of the order of 25% using 10 minute data from a location in Western Europe). You won't see that statistic when looking at all the data (all sky), but if you specifically look at clear sky conditions, you will see that basically Erbs overestimates the atmospheric turbidity / aerosol optical depth, leading to a higher diffuse component. Put another way, the sky is clearer than what Erbs models it to be, there is less scattering due to aerosols and more direct light. This error leads to underestimation of the direct component and underestimation of shading losses in PVsyst It would definitely make sense to include DIRINT [2] in PVsyst, since that model uses more predictors, not just the clearness index. Specifically, DIRINT has a time component that takes into account variability, i.e. the change in clearness index. That helps then to distinguish between different weather conditions, and thus model them differently. All of that being said, the best is to import diffuse irradiance, which is however not always possible if it is not measured on site. [1] Gueymard, C. A., & Ruiz-Arias, J. A. (2016). Extensive worldwide validation and climate sensitivity analysis of direct irradiance predictions from 1-min global irradiance. Solar Energy, 128, 1–30. https://doi.org/https://doi.org/10.1016/j.solener.2015.10.010 [2] Perez, R. R., Ineichen, P., Maxwell, E. L., Seals, R. D., & Zelenka, A. (1992). Dynamic global-to-direct irradiance conversion model. ASHRAE Transactions, 354–369.

I recently imported high-resolution (1 minute) weather data (GHI, DHI, ambient temperature) from a BSRN station for the year 2020, which was a leap year. This was to estimate sub-hourly clipping losses. The CSV file has 527040 lines of data, which corresponds to 366 days of one minute data, starting at 2020-01-01 00:01 and ending at 2021-01-01 00:00, with end-of-interval convention. However, the CSV import gave the error "Error while reading date 31/12/20 at 23h02 Limitation of the custom file import at 12 months." The resulting MET file ends at 23:00 on the last day of the year, so in the end all is good and it won't make much difference to the simulation. However I am not sure why this error is thrown, since the data is correct and the "limitation" should not be there.

As Michele said, if the diffuse component was not also imported from satellite, it would have to be estimated using the Erbs model, which is highly inaccurate for high resolution data. It was developed using hourly, daily and monthly data. In general Erbs often overestimates the diffuse irradiance under clear skies, thus underestimating the direct component and underestimating shading losses. However I am not sure whether this explains your discrepancy. In general, satellite data does not have such high granularity, at least the raw data such as cloud properties may only be in 15 minute intervals. So it is important to know the limitations of the data. Some satellite data is also instantaneous and not really averaged over an hourly window for instance.

Thank you very much for your time and support. I am currently considering near shading effects in my simulation for vertical façades and have imported a 3D model of my building. I would like to clarify a few points: 1) For one of the façades, the total area is approximately 7,000 m², but the PV installation will cover only a specific section of about 1,100 m². Is there a way to define or limit the PV installation area within the Near Shadings scene? 2) For this same building, I will be using two different PV module types, one for the rooftop and another for the façades. What is the correct way to model this setup in PVsyst? 3)Finally, are there any additional considerations or best practices to ensure accurate simulation results for vertical PV façade installations?

It is not in our most urgent priorities, but it is in our roadmap. Indeed, it would make the reverse transposition when importing POA data more reliable. However, to our knowledge, it does not address the bias inherent to applying the Perez model to sub-hourly data.

Hello, It would be great if we could specify .SHD files in batch simulations.

Will the Perez-Driesse model be included as an option in the future?

Hi Anybody can advise me? I keep encountering the error during bifacial simulation. The error code is "Your PV system is not suited for bifacial 2D computation....." PV system is tilt 25degree and 2 different orientation.

Hello, Indeed the PVsyst simulation is hourly based, so any sub-hourly phenomenon has to be averaged. This includes the weather data or self-consumption. The main reason for this limitation is that we currently consider that Perez’s transposition model is not well calibrated for sub-hourly data (EUPVSEC 2023). Sub-hourly simulation should be available in PVSyst 8.1, but the release date is not yet defined (it will be after 2025). Nonetheless, we included a sub-hourly clipping correction in PVsyst 8.0, allowing the simulation to consider sub-hourly irradiance fluctuation for clipping (EUPVSEC 2024) You can refer to the dedicated section in our help page for more information. The last option is to use the so-called pseudo-subhourly simulation. The idea is to run n hourly simulations (in your case n = 60min/15min -> 4 ) then recombine the results. You can find a PDF tutorial about the whole process in our website: pseudo sub-hourly simulation This process can even be automated if you have a PVsyst CLI licence. You can find an application of pseudo-subhourly simulation using PVsyst CLI in python in the help Please note that pseudo sub-hourly simulation cannot be used with energy storage systems. Best regards,

Dear Renan, Thank you for reaching out. Even if you got the information message The license file "C:\ProgramData\PVsystCLI\PVsystCLI.lic" is missing. You can run "lic-activate" command to activate your license. the simulation should perform if you are still in TRIAL mode. Could you please export and send us your PVsystCLI log files to support@pvsyst.com (you can generate PVsystCLI logs with the command "PVsystCLI export-logs") Best regards.

I was testing PVsystCLI normally, and suddenly the following error started to appear: The license file "C:\ProgramData\PVsystCLI\PVsystCLI.lic" is missing. You can run "lic-activate" command to activate your license. When I run the command PVsystCLI lic-info, I get the following information: The license file "C:\ProgramData\PVsystCLI\PVsystCLI.lic" is missing. You can run "lic-activate" command to activate your license. Status: TRIAL Remaining days: 17 Remaining executions: 208 Host ID: HARDDISK=0000_0000_0000_0001_8CE3_8E05_00AE_DC3E., ETHERNET=0A0027000004||70A8D3D028D0||72A8D3D028CF||70A8D3D028CF||70A8D3D028D3||B44506AB2282, WIN_PRODUCT_ID=00342-43291-73682-AAOEM, BIOS=752V6R3 It clearly says that my Trial license is still valid, but the CLI doesn’t run any simulations — it just stops with the “license file missing” error. I didn’t change anything in my system configuration, and this issue appeared suddenly. What should I do to make PVsystCLI work again during the trial period?

Hello, I would like to ask, since I know it's not possible to do it for now, are you planning to add i some time possibility to simulate results in 15 minutes intervals, not only in hourly system like right now we have? If yes, then when we could expect to see it implemented in PVSyst, more or less at least? I'm asking mostly in terms of hourly data we can generate in csv. file but of course also about basic reports. We are getting more and more questions regarding this topic from our clients and banks when looking for proper financing for our projects and it would be good to know if there is something we can hope for in the future.

Hello, The available area in the Pre-sizing help in the System window, serves as a guide for a first order of magnitude of how many panels you can fit on a dedicated surface. This tool take only the size of the panels into consideration (not the spacing between the panels or a pitch). If no 3D scene is defined, no configuration other than what is defined in the system and orientation window is considered (no shadings). Defining a 3D scene with the surrounding shading elements, include electrical shading definition etc. will more accurately simulate the system. You find a tutorial for the 3D tool in the following link: Another potential important parameter for a vertical system would be the reflection on the ground. For a monofacial system, this is discussed in the following forum page:

Hi, From the information you provided, this behavior does not seem normal indeed. The 1st graph looks ok, having 5.8% losses due to the grid limitation with 320kVa installed and 250kVa does not strike me as unusual. The fact is has been lowered to almost nothing in the second case is strange. I tried to reproduce your test case, but the results I obtain are correct. Please contact support@pvsyst.com and share your project so we can have a better look at what's happening.

You can add a battery in your database from scratch by using "Databases => Batteries => New". But you are strongly advised to choose a similar battery in the database, modify its parameters according to your own component datasheets, and save this as a new battery. For defining an hybrid system, you should choose the button "Storage" in the project's dialog, and probably choose the option "Self consumption" for your case.

I would like to inquire about the correct procedure for simulating PV façade installations in PVsyst. I have specified the available façade area and set the tilt angle to 90°, but I am uncertain how the software interprets this configuration. Does PVsyst arrange the panels vertically on a single flat surface (side by side), or are they positioned one behind another? Additionally, is there an alternative or more accurate method to simulate façade-mounted PV systems in PVsyst?

No, in the present time PVsyst doesn't consider the charging of the battery from the grid.

We update the database using the requests of the manufacturers, and publish it with each new release of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. You have a tutorial for that on youtube: https://www.youtube.com/c/PVsystTutos. The inverter database already includes microinverters.

Hi. How can I run a simulation using a microinverter? Also, how can I include a microinverter in the database? Thank you.

Dear PVSYST Support, I have a question about the grid limitation in PVSYST. Indeed, in my simulation, I put the grid limitation at 250 kVA this way with AC ohmic loss =3% And the result is -5.8% of unused energy. It seems very huge and the impact on the productible is very strong. I did the same simulation with 0% Ohmic loss, and the result of unused energy is -0.1% How is calculated the Unused energy ? It seems that the more you have ohmic loss, the more you have Unused energy due to grid limitation. It's not logical for me. Do you have more informations about this please ? Thanks a lot Sincerely Mickaël BLEIN

Hello How can I add Batteries and use the hybrid systems on the PVsyst

We update the database using the requests of the manufacturers, and publish it with each new release of PVsyst. We can't of course follow all the new products of all manufacturers in the world. We don't want to include data without the acknowledgement of the manufacturer. Nevertheless you can easily create your own components by yourself. The easiest way is to choose a similar existing device in the database, modify its parameters according to the manufacturer's datasheets, and save it under a new name, therefore creating a new file in your database. You have a tutorial for that on youtube: https://www.youtube.com/c/PVsystTutos.