Soldnerkugel

maybe it is also an issue raised by "true north vs. grid north" pls see here: https://en.wikipedia.org/wiki/Grid_north

It's quite some time ago I did a bifacial simulation...so I hope that I do remember properly 1) Structure shading factor: from my understanding this the surface of a pv panel which is covered by rails, beams etc. of the substructure in relation to the total surface of a pv panel. This is not easy to deal with as there is scattered diffuse irradiation but also some direct irradiation which might cause shadings on the rear side of the cells. 2) the efficiency of bifacial cells on the front side is normally higher than the one from the back side. This parameter should be th ratio of these different cell efficiencies.

most probably: yes but it is very hard to figure out what is wrong without having detailed information. Is it possible that you upload the reports of both simulation versions here?

...and additionally have alook at this map... https://www.ngdc.noaa.gov/geomag/WMM/data/WMM2015/WMM2015_D_MERC.pdf

So... - click the link I provided before - select yout region by defining a rectangle - select SRTM Global Data as data source (select the raster version, for every spot on earth there is at least a 90 metres resolutions, sometimes also a 30 metres solutions is available) - select "GeoTiff" as output format - enter an email address and a job title then download the file you now can open the file in several CAD or GIS products, following is a description of how to extract the data using AutoCAD Civil - start AutoCAD Civil - select "create surface from DEM" _CreateSurfaceGridFromDEM ("digital elevation model", GeoTiff is available to select in the GUI). You now have a raster surface in AutoCAD Civil - now create an empyt TIN-surface in AutoCAD Civil - expand the tree of your new TIN-surface in the prospector tab - edit your sufrace by selecting "add surface" and add the raster-surface you created before - now you can see your surface in WGS84 projection - transform the coordinates from WGS84 to a metric projection - display the points of your surface by editing surface style (if not already enabled) - select the TIN surface and the use the ribbon to extract its point _SurfaceExtractObjects - select points only in GUI - now use a visual style so that the surface is not displayed and you'll see ACAD points in the dwg now - now enter _dataextraction in the command prompt and select points only - then select only X,Y,Z positions - export to a *.csv-file - open *.csv-file and eventually edit it (depedning on local country settings, remove header line and first two columns, save this file - open a new dwg in AutoCAD Civil and apply your desired grid reference to it -create a new TIN-Surface - add point data by right clicking and select the *.csv-file you created (check also point data format!) and enable check-box for transforming coordinates - now you have your TIN surface in a metric system, you have access to the point data by extracting the points from the surface it works similar in GIS applications. biggest challenge could be to understand mapping projections and select a proper one.

I once wrote a guideline how to do...hope I can share it here tomorrow. Btw: be careful using these data, afaik for the US it is offered a 1 arcsecond resolution (tiles of approx. 30x30 m),ROW is in 3 arcseconds (approx. 90x90 m resolution), so do not use it for construction execution purposes. In an initial stage it is though really helpful for preliminary eatimations. I use AutoCAd Civil for processing these data, maybe it also works with other AutoCAD products and also with some GIS applications but i cannot confirm.

btw: there's no need for windPro, you can simply download SRTM-Data in GeoTiff from here http://opentopo.sdsc.edu/datasets?listAll=true

Imperial vs. Metric?

Currently I'm using PVsyst Version 6.45, but I cannot find the "Parameter Optimization Tool". Where can I find it? or is it available only in higher versions of PVsyst?

Magnetic declination is not constant, it is varying. magnetic meridians are not parallel, therefore it is not useful to use magnetic north/ south as a reference. You need a reference which is constant, so you only can use geographic north/ south (although this reuqires an approximation of the shape of planet earth as it is not able to be modelled by mathematic functions. Grid north/ south is also not applicable as grid north/ south depends on the mapping projection. I.e. there are mapping projections which are non-cartesian: Lambert projection in France, Krovak projection in Czech republic etc etc. always bear in mind that there is a difference between grid north and true north. I.e. in check republic this difference can reach up to ca. 12 degrees. Even cartesian projections like Gauß-Krüger, OS Grid, UTM differ from true north.

A fraction of these 4-5 % might result from a change in the transposition model from Hay to Perez. btw: how is it possible that an "identical simulation" delivers a non-constant result like "4-5 %" is...every run should deliver the same result.

Do I get you right: this discrepancy only appears when using a "customised" IAM parameterisation (either manually entered in PVsyst or as information in a .pan-file). As a standard the ASHRAE parameterisation is used, but it is not calculated by using a cubic spline. In older versions of PVsyst a cubic spline was calculated using the nodal points either manually entered or from the pan-file. So if two (or more) consecutive points were of value "1", the calculation of the cubic spline returned false values (because cubic splines are defined only in sections using the delimiting nodal points and between two points of the same value you cannot define a curve but only a straight). But - as I already mentioned - this only appears using a "customised" IAM parameterisation.

Not really, as this is missing ECET and BCMT and alread during ECET and BCMT there's some irradiation available, which in fact can only be diffuse beam.

0.25 is less than 0.1% of one year. ...did you already check the accuracy of the meteo data and the transposition method you use? ... Most probably it will exceed 0.1% * operating years by far. Additionally a more conservative prediction is always preferred (due to my experience). And finally: although one full orbit may have ~365.25 days....one year still has 365 days with 24 hours each, so the "missing" 1/4th day will not really appear in a database, it will probably "falsify" somehow the hourly values as there will be a time shift, which will increase and in year four will be set to zero again.

Backtracking shall avoid shading on your pv-panels, so you define a limitation on the angle of tilting the pv-panel at a certain pitch. Maybe this limitation is kept for also for other pitches. If you increase the pitch you could change also this limitation, you could allow a higher tilt (because there's more space between two adjacent rows of racks), so you could benefit from a gain in incoming irradiation on your array at low solar zenith angles. ...but if the limitation will stay the same, there'll be no gain in incoming irradiation. Only you could benefit maybe from less "near shading" losses. (This now depends on your location and the specific amount and hourly distribution of irradiation, if you should use an SAT with an east-west tracking the gain from less "near shading" losses most probably should be very low. Locations far away from equator should benefit - if the irradiation at this locations early in the morning and late in the evening would not be that low. Locations (relatively) close to equator normally show a significant irradiation already early in the morning / late in the evening but they probably also will show no benefit or only a small benefit as the sun much faster reaches high solar zenith angles than at locations far away from equator. This maybe could be an explanation, but: 1. the information about your project is very limited and still there are maybe parameters of interest which could affect the result that I do not know. 2. I yet did not use the "PV Syst optimization tool" as I do have my own one since 2011, which shows also some other results that are of interest when it comes to optimizing a solar farm. ;) ...so this is only an assumption what could be

Maybe it is an issue somehow related to the maximum tilt angle in case you should use a tracking system with "backtracking" option?

One question: where is the solar farm located? In France? Afaik the national grid (not the electrical one, the mapping one ;) ) is a conic Lambert one, maybe you need to obtain a transformation to the coordinates you were provided by the land surveyor as it could be possible that grid-north is not coincident with true north which Is the reference for solar simulations. I think a more convenient solution would be to do the design in a CAD software and do the yield simulation in PVsyst as you surely will need some plans to hand over to the local planning officer to get your development permitted.

How is the scale defined in PVsyst? Using google maps or google earth should not make any difference as for a few years both products use the same data (afaik). In standard google maps is using geographical coordinates in WGS84 (DMS). So importing a bmp or png most probably is without any scale. Even of google maps should UTM projection (metric) saving an image will most probably get rid of the scale, additionally UTM uses a scale of 0.9996 and UTM grid north is not "true" north due to mapping a "sphere" to a plane view. Maybe using a so called "world file" could solve this issue. Example if you use a *.tif you would also need to use a file with extension "*.tfw", wich contains onl six lines with information about scale and rotation. Such world files are common within GIS and exist also for other image formats like jpg etc.

It also depends in which time intervals you compute your yield simulation... E.g. 2 degrees should be only a few minutes after sunrise or before sunset at any location on the globe. So imagine using an intervall of 1 hour PVsyst (most probably) will use not the "full" hour but the middle between two fulls hours (30')... So 2 degrees is not relevant, even using an interval of 1/2 hour dor your computation will not have any impact at nearly all locations on the globe on far shadings. I thin questions like this one only arise because most user of pv simulation software products have no idea or only a reduced knowledege about e.g. Sunpathes, climate databeses etc. To me this is one important field which still needs lot of improvement within PV. How shall one know how to properly design a pv plant without knowing how the behaviour of the plant is modelled? The most advanced software is only as good as its operator.

I'm also struck by this problem. Initiallay I used Meteonorm data, now I have to use SolarGIS data. I checked both files and discovered that the time zone in Meteonorm is "-3" and in SolarGIS "2". Ok, forget about the "-", 'cause it probably depends on how you define Azimuth (geodetic vs. "photovoltaic"), but there's still a difference of one hour. So: what's the proper time zone? Meteonorm or SolarGIS? ...or is this eventually an issue because of daylight saving time?

Thank you very much, that's exactly what I wanted to know

but actually changing those values should have an impact on the simulation results?

Module manufacturers always add tolerances to their datasheets, like "300 Wp, 0 to +5W tolerance". In PV-Syst I can edit this tolerance: "Definition of a PV Module", tab "Basic data". There's two textboxes: one for entering a minus tolerance, and for entering a plus tolerance. I just entered different values theres but the result in the pv-syst report after simulation is still the same. How does PV-Syst incorporate these plus and minus tolerances in its simulation?