All Activity

You can import 15 min data via the custom file function of PVsyst. Just note that the data will be averaged and the simulation will still be in hourly steps https://www.pvsyst.com/help/meteo-database/import-meteo-data/custom-meteo-files/index.html Now for the merging part, you cannot do this in PVsyst. If you would like to use a mix a data sources, you should first create a .CSV file that has all your data. Please be careful when doing so that your data corresponds to the same place. But please also note that in your case having global horizontal irradiance and ambiant temperature should be enough to create a .MET file and run your simulation. There is no need to merge anything.

Hello, Thank you for reaching out. Arial Unicode Normal font may be missing from your computer. Could you please check that you have it installed in your C:Windows>Fonts folder (Normal and Bold should appear for Arial Unicode MS) : https://desk.zoho.eu/api/v1/threads/200072000001797064/inlineImages/edbsn7b09642fb0c92558ad8ffc2319c06c6aae8eae894ba35cc03ed977ae672c483390bfd10deca24a57142d1e0249d0d3edbb5657da68ac8273f7de1e0bd4309326faa955ca0dfb52784be482642ded7957?et=19a59591169&ha=ec3fec97486c37d0383b8b56f46c6dca941a44e833e4fcab4f70546a8c67d2a8&f=1.png If not you can install it from here: https://freefontsdownload.net/free-arial-unicode-ms-font-36926.htm Should you need any further assistance, please do not hesitate to reach out directly at support@pvsyst.com. Kind regards, Laurent

The files created in the V8 cannot be used with the version 7.

Good morning, I have a quarter-hourly meteo file from a photovoltaic solar plant containing wind speed, horizontal irradiance, and ambient temperature data. I would like to know how I can import these data into PVsyst while keeping the rest of the meteo parameters from the PVsyst site file, so that I can run a simulation and check whether my plant is performing the backtracking correctly. Thank you very much.

PVsystCLI can run simulations,import and convert meteorological data,but some PVsyst tools can not running by PVsystCLI,I strongly suggest our PVsyst team update PVsystCLI，then we can use the following PVsyst tools: 1、Import and generate weather data-by Known format 2、Import and generate weather data-Synthetic Data generation Reason:it is very useful in early stage of project development,and in this project stage,we should simulate lots of sites with solargis/MN data to chosing suitable sites,it is impossible simulate with measured data

After writing that, perhaps the issue is that your prj file itself is missing the .SIT information, in which case manual creation might be the solution.

You can always create one from notepad just to get it loaded or extract the site information from the .prj file. Look for the following (and remove the text after the underscore). Some changes will need to be made; I think you just need to add the version below the "Comment=..." line. If you're creating from scratch, I think the main things you need are coordinates, altitude, timezone. The meteo data that is contained in the site file is not used in simulation. PVObject_SitePrj=pvSite .... .... End of PVObject pvSite

There is no corresponding SIT file in the Sites folder. That's the problem. I got the project file from another user and can't upload the met file because there IS no site file. This has always been the problem with project exports. I tried downloading the SIT file by using "Export table" after clicking to open the site on the project's main page. That gets me some of the info, but not a SIT file.

I ran pvsyst but the reporting section is showing blanks and choppy. When i ran the Shading Factor table, the number does not show up. Currently running PVsyst 8.0.17

I have created a custom Pan File in PVsyst 8 and imported it in PVsyst 7, there are few param (eg: Rsh and Rs. ) that has been changed. What could be the reason?

Oh, I thought I would be notified when I got a response. Basically, I have two PV module arrays. One array is on top of the other array, which is why they overlap. So, when I want to manually create an electrical string with my mouse, I can only modify the modules from the bottom array in the area where they overlap

Hi @James Barry Thank you for the feedback. This comes in very timeline as we are currently assessing models for the decomposition of irradiance from GHI for minute data. We are aware that diffuse fraction models such as Erbs can be biased when applied on sub-hourly scales. Providing an alternative to Erbs is thus a necessity.

The simulation models both the location and the temperature, provided you have parametrized these properly. If the inverter malfunctions, you could also derate the inverter in PVsyst. Moreover, it is important to import the historical weather data corresponding to the monitoring period. Can you confirm whether you are using the corresponding time series for your simulation? If you are using a compatible time series as input for the simulation, it is then worth to compare the measured and simulated time series to understand whether the discrepancy correlates with any factor. Usually comparing the yearly PR and measured PR is not very telling per se. I think you should use the standard PR. However, it depends on how you are calculating the PR for the measured performance data. You should match the definitions of simulated an measured PR.

Buenas tengo una consulta, al generar el informe de pvsyst quiero que muestre la energia util a la salida del sistema ya que esa es la energia que se entrega. Pero no veo la opcion de añadirla en el informe. Les adjunto las variables disponibles para añadir al informe, gracias de antemano

As quick extra note: according to the comparison paper by Gueymard and Ruiz-Arias [1] quoted above, the best performing model is in fact "Engerer 2" [3], since it is developed specifically for one minute data. However the next best model is the DIRINDEX [4] model, which is basically DIRINT with an additional predictor based on applying a clear sky model. It would be great it PVsyst could consider using some of the more modern decomposition models, especially considering the use of high-frequency irradiance data. [3] Engerer, N. A. (2015). Minute resolution estimates of the diffuse fraction of global irradiance for southeastern Australia. Solar Energy, 116, 215–237. https://doi.org/https://doi.org/10.1016/j.solener.2015.04.012 [4] Perez, R., Ineichen, P., Moore, K., Kmiecik, M., Chain, C., George, R., & Vignola, F. (2002). A new operational model for satellite-derived irradiances: description and validation. Solar Energy, 73(5), 307–317. https://doi.org/https://doi.org/10.1016/S0038-092X(02)00122-6

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.

Hello Michael, I would like to clarify my question. Does the simulation calculate the PR while taking into account the system’s location and the fact that the inverter experiences early clipping? I’m asking because, according to the system monitoring data, I can see a difference in PR between the simulation results and the actual performance on site. Another question — regarding the panel temperature: Does the simulation consider the temperature variations of the panels? Since when the temperature rises, the panel’s output decreases, this factor also affects the system’s PR. In addition, does the PR value shown in the report reflect the PR including temperature effects, or should a PR corrected value be presented in the report instead?

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.