Auriane Canesse

Yes that is correct

That's an interesting approach but I am surprised by the mismatch. It looks to me like the RPOA (darker curve?) was measured on a tracker and the fitted ones (brighter red?) are done for a fixed tilt setup. Or one is backtracking and the other is not? Maybe cross check the tracker definition in the bifacial window. If you have a complex setup, make sure the parameters here match the one tracker your RPOA measurement is installed on.

From a rear side measurement of the POA, you still have to apply a shading factor corresponding to the torque tube, cables, etc ("structure shading factor") in order to compute how much light effectively reaches your panel. This effective light corresponds to GlobBak. All relevant irradiance for bifacial calculation are defined here https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-results.html

I meant you have to change the date itself from 2059 to 2049 in your csv data before importing. The other files should not be changed. File name should not matter. If you struggle to do it, please send a request at support@pvsyst.com with your input csv data attached

Unfortunately, this is a known bug and I'll ping the developer team about it. In the meantime you should change the year from 2059 to 2049 when generating your .MET file for that year. It won't change anything when generating the TMY from your 10 files that they are labeled 2049-2058 instead of 2050-2059

Getting high quality irradiance measurements in the field can be difficult and the two main sources of errors we see from our users are: Shaded sensors, especially for trackers. This can be identified by comparing your data to clearsky expectation on good weather day, and looking for unexpected decreases. The pattern should repeat from one day to the next. Sensor misalignments, either in azimuth or tilt (or both). Even small discrepancies have an impact. If you can easily download POA irradiance from solargis, chose a clear day and download data for several azimuth and tilt values around your expected geometry. Then check if one of the alternative geometries fits your measured data better. If your sensor is misaligned, you can still use the data in PVsyst as we first decompose POA irradiance into GHI and DHI. You just have to use the real tilt and azimut when importing data.

Did you try to define the time shift as indicated in the error message? You should also check that you have input the correct time reference If the time shift information you input is not taken into account or if non of the time base work, could you please sent your csv data file, .MEF file and PVsyst version to support@pvsyst.com so we can have a closer look at your problem

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.

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 Andres, Unfortunately, this is a bug with PVsyst version 8.0.16 and we will fix it in future releases. The bug also affects importing "meteonorm software (*.hor)" data. In the meantime, several workarounds are possible: Import horizon data from meteonorm API ("horizon from web sources") Copying your .hor file in the PVsyst8.0_Data/Shadings folder and importing it with the "PVsyst internal file" option If neither options above work for your situation, reverting back to PVsyst 8.0.15 https://www.pvsyst.com/old-versions/ I hope this solves your issue

By default we recommend Uv=0 as this coefficient is trickier to measure and varies even more from one PV installation to the next. There can be a large difference between the wind speed from a data provider (measured at 10m above ground, not always close by) and local conditions at the module level. But yes to be more accurate you simply need to measure this coefficients on your installation. https://www.pvsyst.com/help/project-design/array-and-system-losses/array-thermal-losses

Hi Zahra, PVsyst has only one temperature model as described here: https://www.pvsyst.com/help/project-design/array-and-system-losses/array-thermal-losses/index.html?h=temperature#thermal-model Our recommendation is using Uc = 15 W/m²·k for modules with a fully insulated backside (eg. PV roof tiles). But BIPV has a very wide range of PV designs so no we do not have recommendations for BIPV in general. If you import cell temperature measurements they will be used directly in the simulation insteand of using the temperature model. For the long tem losses, the degradation factor is applied to Imp/Vmp. The one diode model is fitted again to compute the IV curve of the modules and these are used in the simulation. The mismatch factor on the other hand is an effective correction. Individual modules are expected to degrade at slightly different rates, hence increasing the mismatch losses over time. For each module, a degradation loss is drawn from a gaussian distribution (defined in the ageing tool). The modules are assumed to degrade at that rate over the years an the mismatch factor is computed from that. The mismatch factor is added to the array losses. Unfortunately, we do not have white papers describing these 2 points, only the help pages.

Dear Zaki We do not cap negative values in the Perrez model when computing the circumsolar brightness. They arise when implementing the model and we keep them to avoid biasing the result towards positive values. This term is added to the isotropic component and the irradiance itself is never negative. The horizon is not implemented as a band. The horizon component is calculated using the Perez/Ineichen's 1990 model, but it is directly added to the diffuse irradiance. Horizion shadings are applied as a fraction on the diffuse irradiance but not to the horizon irradiance component separately. For the air mass, we use the the Kasten model described in Ineichen's thesis "Mesures d'ensoleillement à Genève", which is corrected for altitude as well (exp(-0.00013*altitude)) https://unige.swisscovery.slsp.ch/discovery/fulldisplay?vid=41SLSP_UGE%3AVU1&search_scope=MyInst_and_CI&tab=41SLSP_UGE_MyInst_CI&docid=alma991006463789705502&lang=fr&context=L&adaptor=Local Search Engine&query=sub%2Cexact%2CKANTON GENF (SCHWEIZ)%2CAND&mode=advanced&offset=0 I hope this helps you in your study

Currently, the only way to import sub-hourly data in PVsyst is to use the "custom file" import format. https://www.pvsyst.com/help/meteo-database/import-meteo-data/custom-meteo-files/index.html

The formula you have been applying is for a 2-sided test (~chances that the result is different, larger or smaller) whereas in this case a 1-sided test is appropriate (~chances the result is larger only) https://en.wikipedia.org/wiki/One-_and_two-tailed_tests