spelland74

I am having the same issue, with a system with 5 sub-arrays. I hit "all modules" rather than "available now", but PVsyst keeps changing this and then giving the same error message you got.

Hello, One of my colleagues was recently able to upgrade to PVsyst 6.69 from the software. It was indicated that this allowed modeling tracking bifacial systems. But it looks like this version is no longer available, and not on your website? Could you clarify the status of this? We are particularly interested since one of our clients would like us to model a tracking system with bifacial modules. Best regards, Sophie

Thanks André. You wrote "During the simulation, PVsyst estimates the efficiency of the module with an initial efficiency, and then uses it in this expression (one iteration)." Can you specify how the estimation is done? Is the estimate equal to the STC module efficiency? If not, can you indicate how it is calculated (what equation, or reference to the method you are using)?

I forgot to ask: In the same formula "U · (Tcell - Tamb) = Alpha · Ginc · (1 - Effic) ", could you clarify how PVsyst calculates "Effic"? For example, is Effic is the STC efficiency? Or maybe one of the hourly output variables such as maybe EffArrR, or EffArrC, or other ? We want to use measured back of module temperature, wind speed, ambient temperature and Ginc to derive Uc and Uv for one of our clients who has gathered these measurements, and want to make sure we correctly understand your equation so that we can fit the coefficients appropriately.

Thanks André, that clarifies things!

In the PVsyst help, the formula for calculating thermal losses is given as: U · (Tcell - Tamb) = Alpha · Ginc · (1 - Effic) http://files.pvsyst.com/help/thermal_loss.htm The word "Tcell" suggests that this is the temperature of the actual cells inside the PV module, which is generally different (up to about 3 degrees Celsius hotter) than back-of-module temperature. But in the following post, Andre Mermoud seems to be using back-of-module / Array temperature interchangeably with cell temperature: http://forum.pvsyst.com/viewtopic.php?t=37&p=37 Can you please clarify, in the formula above, what "Tcell" refers to? We want to extract Uv and Uc from measurements that a client of ours has made of Ginc and back-of-module temperature, and want to know whether we should do some modeling to obtain cell temperature from back-of-module temperature to apply in that formula?

Hello, We recently modeled a project where the .pan file had a custom IAM. We found out when we were done that the "user defined profile" that appears automatically is not the one from the .pan file. If possible, it would be great if the IAM profile from the .pan file got loaded up automatically / by default into the "detailed losses" (I think this was the case in earlier versions, but not in version 6.63). Another difference along these lines with 6.63: when we run batches, we find that the variables we choose for "results" don't get saved from one run to the next. Same issue with variables chosen as output of hourly simulations. It would be great if PVsyst could "remember" what we chose last time, as I believe was the case for most of the previous PVsyst versions.

Simply writing here to indicate I received a reply by email, and PVsyst uses the Erbs model to estimate diffuse from global horizontal (not the Liu and Jordan model, which is what was mentioned in the online help that I consulted). When I use the Erbs model, I can reproduce the PVsyst diffuse values properly.

Hello, I have just sent an email to support@pvsyst.com with multiple files. This concerns the separation model used by PVsyst to calculate diffuse (and direct) irradiance when GHI only is imported using the ascii meteorological data import tool. Here is the situation: -We are importing GHI only (because this was adapted to ground measurements) and importing using ascii import. PVsyst calculates diffuse and direct irradiance. -I am checking whether the diffuse and direct calculated by PVsyst make sense. My understanding based on the PVsyst help was that the Liu and Jordan algorithm is being used. -However, I calculated diffuse irradiance using that algorithm, and the values are very different from what is in PVsyst (I used the clearness index from PVsyst). In terms of annual total, the PVsyst DIF value is 27% higher than what I find using Liu and Jordan. -The equations I used are fits to Figure 7 in the original (1960) Liu and Jordan paper taken from a 2015 article by Christian Gueymard (see reference below). I checked that the equations indeed match Figure 7 extremely well. Here are the equations (Kt is clearness index): If Kt<=0.75 (DIF/GHI)=1+0.006381*Kt-3.2315*Kt^2+2.2448*Kt^3+0.081882*Kt^4 else (DIF/GHI)=0.16 I was wondering if you could please help us in understanding what’s going on. Ideally, if you can give more details about the equations you were using, that would be much appreciated. Best regards, Sophie Gueymard 2015: https://www.researchgate.net/publication/283570186_Extensive_worldwide_validation_and_climate_sensitivity_analysis_of_direct_irradiance_predictions_from_1-min_global_irradiance

Hello, I am trying to model a fixed tilt, Megawatt-scale PV system on complex terrain. For this, I thought I should create a ground object and somehow position the PV array on this object. I have tried multiple times unsuccessfully, and was wondering if you could provide more instructions on this (I've looked at the PVsyst help already). The attached file shows a screenshot of a test case I'm doing: I created a simple ground with a constant North-South slope. I also created a "PV tables as sheds" object and put them in the same area in the X-Y plane. When I hit "Tools -> Position tables on scene", this doesn't place the sheds at the Z height of the ground, and doesn't change the shed-to-shed slope along North-South, as I would expect it to. Could you please provide some instructions for placing tables on ground? Or else, indicate the best way of modeling arrays in complex terrain. Best regards, Sophie (Note: I can send a .shd file by email if helpful - the attachments here did not allow me to attach a file with a ".shd" extension)

Hello, We had been importing our own (3TIER) weather data for India successfully with past versions of PVsyst (6.42 is the one that we used for the longest time) using the ASCII import tool. Now, with version 6.47, we are having several issues. One seems to be a bug, the other is simply quite time-consuming. To start with the time-consuming issue: -We use ASCII import often, especially for India, where the time convention is UTC+5.5 (tm2 format doesn't correctly handle the half-integer UTC difference). -Now in version 6.47 (and possibly some earlier ones too), we are asked to import with hour shift =1 if PVsyst calculates a time shift greater than 30 minutes, and with hour shift = 0 if PVsyst calculates a time shift less than 30 minutes. This is problematic for our India data, where the "normal" time shift is 30 minutes (i.e. data runs from 0:30 to 1:30, 1:30 to 2:30, etc). That means that for any non-zero deviation from this that PVsyst calculates, we need to import one way or the other. That's time-consuming, as it means potentially re-doing all our file imports twice (sometimes we import up to 25 or so weather files) Now with the bug: -I will send by a separate email one file that we have not been able to import properly in PVsyst 6.47 at all. When we put hour shift=0, time shift=30, PVsyst calculates an average time shift of -37 minutes and asks us to import with hour shift =1. When we import with hour shift=1 (time shift=-30), then PVsyst calculates an average time shift of 30 minutes (inconsistent) and asks that we import with hour shift of 0. -Note: I tried importing with PVsyst 6.42, and there is no bug in that case, and the .MET file is judged to be ok. With PVsyst 6.47, we cannot even run it! -If possible, it would be helpful if "hour shift=1" would be reserved for cases where the average time shift on clear days is one hour or more...

Hello, I recently uploaded PVsyst version 6.44. I am having issues with the near shadings tab (which I was not having with previous versions). I create a shading scene, then calculate the shading factor tables, then close this. I also click "Use in simulation -> According to module strings". When I click on OK, I get a "no shading scene defined" message - so somehow the shading scene information is not being properly saved. I have done this multiple times successfully with previous versions of PVsyst, so I think this is a bug. Best regards, Sophie

Hello, I am simulating a PV system in a location where minimum daytime temperatures in winter can reach about -30 degrees Celsius. Based on this, I think the minimum winter operating temperature for design should be around -10 Celsius, but PVsyst does not allow for values below 0 Celsius. Could you give some feedback on this? Best regards, Sophie

Andre: Thanks for pointing me to the modifications list - this is very helpful, and I'm glad it exists! Jose: I tried the work around you suggested, thanks. It works roughly, but somehow now the file name that I enter doesn't get respected (it gets overwritten by another name). I'll stick with 6.4.2 in the meantime. That one doesn't have this bug.

Hello, I just started using version 6.4.3 of PVsyst, and found a bug in importing ascii meteo data. When I click on the "start conversion" button after having filled everything else out, the reference year value keeps going back to zero. This causes repeated error messages and bad import of data. As a check, I did the same thing in version 6.4.2 and had no problem. So I think this is indeed a bug. Congratulations on all the new features (such as degradation)! BTW: One suggestion: It would be nice if, when you release a new version, you indicate differences from the previous version such as new features and bug fixes. Best regards, Sophie

Hello, When a PV module is not in the database, I sometimes create a new .pan file by modifying the specifications of a module that is in the database. Now I am wondering about the proper way to fix Rseries and Rshunt in this case: should I just modify the "Basic data" tab in the .pan file and let Rseries and Rshunt be adjusted according to whatever algorithm was in place, or should I also go to the "Model parameters" tab and set Rsh and Rs to "Default" values? In other words, when creating or modifying a .pan file, should we pick "default" for Rseries and Rshunt, or not? Best regards, Sophie

I have just downloaded again version 6.3.8 and can confirm that there is no issue running my simulation with the batch parameter file I showed in the previous post. The issue only occurs for 6.3.9, so I believe there is a bug in the 6.3.9 batch algorithms.

Hello, I have been using the batch mode of PVsyst to run several meteo files for a project. With previous versions, this was working fine. In the current version, somehow PVsyst is running the first simulation in the batch twice instead of once, and doesn't do the last simulation. I have tried various solutions and been unable to fix this. I am giving an example of input batch parameters below (I have changed the files a bit to protect client privacy). In that example, when I run this batch file, the TMY gets simulated twice rather than once, and everything else is offset. The 2014 .met file does not get simulated. Best regards, Sophie -- Batch parameters file (site name modified) PVsyst simulations Batch mode; Simulation parameters definition; File Modified on 27/08/15 12:11; ; Project ;;;Site TMY; Variants based on;;VC0;Detailed losses; ; Please define the parameters to be varied for each run; Don't modify anything in the column titles !; Only the lines beginning by "SIM_" will be executed; ; Ident;Meteo data;Simul;; ;*.MET file;Comment;; ;;;; ; SIM_1; Site_TMY.MET;Detailed losses;; SIM_2; Site_2000.MET;Detailed losses;;; SIM_3; Site_2001.MET;Detailed losses;;; SIM_4; Site_2002.MET;Detailed losses;;; SIM_5; Site_2003.MET;Detailed losses;;; SIM_6; Site_2004.MET;Detailed losses;;; SIM_7; Site_2005.MET;Detailed losses;;; SIM_8; Site_2006.MET;Detailed losses;;; SIM_9; Site_2007.MET;Detailed losses;;; SIM_10; Site_2008.MET;Detailed losses;;; SIM_11; Site_2009.MET;Detailed losses;;; SIM_12; Site_2010.MET;Detailed losses;;; SIM_13; Site_2011.MET;Detailed losses;;; SIM_14; Site_2012.MET;Detailed losses;;; SIM_15; Site_2013.MET;Detailed losses;;; SIM_16; Site_2014.MET;Detailed losses;;; ;; Don't forget to close this file in EXCEL before returning to PVsyst for executing the simulation !!!;;

I have now figured it out :) The lines need to read: SIM_1; Site_TMY_MOS.MET;file1.csv;First simulation all losses included;; And so on. I had not understood that the hourly output file name needed to be at that location. Problem resolved!

I have named the three files "file1.csv", "file2.csv", "file3.csv". Maybe I am not writing this in the right place? If you could show me an example of properly written lines to generate hourly batch files, it would be much appreciated. I am having trouble understanding the required format.

Hello Andre, I have tried several times, but haven't been able to generate hourly output files when I run a simulation in batch mode (I do get the annual results though). I will paste below an example of the file I am using to try to generate hourly outputs in batch mode. If you can tell me how I should modify this, it would be much appreciated (note: I can send files by email if this is easier). Best regards, Sophie -- PVsyst simulations Batch mode; Simulation parameters definition; File Modified on 24/07/15 10:15; ; Project ;;;Grid-Connected Project at Site; Variants based on;;VC0;First simulation all losses included; ; Please define the parameters to be varied for each run; Don't modify anything in the column titles !; Only the lines beginning by "SIM_" will be executed; ; Ident;Meteo data;Create hourly;Simul;; ;*.MET file;file;Comment;; ;;File name;;; ; SIM_1; Site_TMY_MOS.MET;Y;First simulation all losses included;; ;*.MET file;Site_TMY_MOS.MET;Comment;; ;;file1.csv;;; SIM_2;Site_GHI_plus_2_percent.MET;Y;First simulation all losses included;; ;*.MET file;Site_GHI_plus_2_percent.MET;Comment;; ;;file2.csv;;; SIM_3; Site_GHI_minus_2_percent.MET;Y;First simulation all losses included;;;; ;*.MET file;Site_GHI_minus_2_percent.MET;Comment;; ;;file3.csv;;; ;; ;; ;; ;;; Don't forget to close this file in EXCEL before returning to PVsyst for executing the simulation !!!;;;

Thanks Andre. I guess this will be something to look forward to in the future version.

Thanks Andre!

Hello, I am modeling a one-axis East-West tracker. I have been doing some verifications on the irradiance data in the plane of the array. For certain times of day, PVsyst gives direct normal irradiance non-zero, and incidence angle less than 90 degrees, but direct irradiance in the plane of the array is 0. I am wondering why that is. Is direct in the plane of the array always calculated using DNI*cos(incidence_angle), or are there cases where there are added complications? I am attaching the file I used which includes data from PVsyst. I am including only the 29 hours for which DNI*cos(incidence_angle) does not give the same value as the BeamInc reported by PVsyst. For all other hours, the results were the same. Best regards, Sophie Note: I was unable to attach the file. I am copying a csv version of it below. The two last columns are the direct irradiance in the array plane calculated by PVsyst (BeamInc) and the value calculated using the direct normal from PVsyst and the angle of incidence from PVsyst. kT,date,GlobHor,DiffHor,BeamHor,T Amb,GlobInc,WindVel,HSol,AzSol,AngInc,AngProf,PlTilt,PlAzim,PhiAng,DifSInc,Alb Inc,BeamNor,BeamInc,BeamNor*cos(AngInc) 1.416,19/11/97 06:00,6.007,1.0027,5.0043,22.7,1.0028,1.8,1.0426,-68.597,87.872,1.1199,1.166,-90,-1.166,1.0027,0.0001,275.8,0,10.24102444 1.22,20/11/97 06:00,5.0033,1.9986,3.0046,21.4,1.9987,2.5,1.1185,-68.319,87.717,1.2036,1.2533,-90,-1.2533,1.9986,0.0001,154.3,0,6.146590466 0.831,18/11/97 06:00,3.9995,1.9986,2.0009,22.6,1.9987,2.3999,1.1827,-68.789,87.586,1.2686,1.3211,-90,-1.3211,1.9986,0.0001,97.2,0,4.094043028 1.17,21/01/97 18:00,6.9953,3.9973,2.998,19.9,3.9974,0,1.2118,68.361,87.526,1.3036,1.3576,90,1.3576,3.9973,0.0002,141.4,0,6.103676527 1.755,07/10/97 18:00,10.995,1.9986,8.9962,25.1,1.9989,1.4,1.3064,83.445,87.333,1.315,1.3694,90,1.3694,1.9986,0.0003,393.7,0,18.31930339 1.486,16/11/97 06:00,9.0028,1.9986,7.0041,23.3,1.9989,2.3,1.2437,-69.284,87.461,1.3297,1.3847,-90,-1.3847,1.9986,0.0003,323.4,0,14.32642847 2.392,08/10/97 18:00,14.006,1.0027,13.003,25.3,1.0031,0.3,1.3287,83.024,87.288,1.3386,1.394,90,1.394,1.0027,0.0004,559.5,0,26.47310991 0.867,20/01/97 18:00,5.0033,3.0013,2.0019,21.3,3.0015,1.1,1.2754,68.092,87.397,1.3746,1.4316,90,1.4316,3.0013,0.0002,89.7,0,4.073751876 1.352,17/11/97 06:00,7.999,3.0013,4.9977,23.4,3.0016,2.8,1.3223,-68.987,87.301,1.4164,1.4752,-90,-1.4752,3.0013,0.0003,217,0,10.21831664 1.916,11/03/97 06:00,11.999,1.9986,9.9999,16.3,1.999,0.3,1.4166,-85.554,87.108,1.4209,1.4799,-90,-1.4799,1.9986,0.0004,405.4,0,20.45384568 1.788,22/01/97 18:00,11.999,1.9986,9.9999,21,1.9991,0.6,1.3641,68.543,87.215,1.4656,1.5265,90,1.5265,1.9986,0.0004,419.2,0,20.36820752 1.931,15/11/97 06:00,13.002,1.9986,11.004,23.2,1.9991,2.5,1.3818,-69.495,87.179,1.4753,1.5365,-90,-1.5365,1.9986,0.0005,457.3,0,22.50640733 2.667,06/10/97 18:00,21.001,1.9986,19.003,25.2,1.9994,0,1.5174,83.774,86.902,1.5264,1.5898,90,1.5898,1.9986,0.0008,716.2,0,38.70628232 0.98,13/11/97 06:00,7.999,1.0027,6.9963,23,1.003,1.7,1.4372,-70.028,87.066,1.5291,1.5927,-90,-1.5927,1.0027,0.0003,279.5,0,14.30637049 0.838,24/01/97 18:00,6.9953,1.0027,5.9926,23.7,1.003,2.2,1.4509,69.018,87.038,1.5539,1.6186,90,1.6186,1.0027,0.0003,236.2,0,12.20531107 1.496,14/11/97 06:00,11.999,3.0013,8.9972,22.4,3.0018,2.5,1.5192,-69.712,86.898,1.6197,1.6872,-90,-1.6872,3.0013,0.0005,340,0,18.39864728 1.975,23/01/97 18:00,15.998,1.9986,13.999,23.7,1.9993,2.0999,1.5162,68.73,86.905,1.627,1.6948,90,1.6948,1.9986,0.0007,528.1,0,28.51300305 0.335,12/11/97 06:00,2.9958,1.9986,0.9971,21.8,1.9988,1.5,1.5726,-70.257,86.789,1.6708,1.7405,-90,-1.7405,1.9986,0.0001,36.4,0,2.038880146 1.337,05/10/97 18:00,11.999,1.9986,9.9999,24.4,1.9992,0.3999,1.7305,84.103,86.467,1.7397,1.8125,90,1.8125,1.9986,0.0006,330.5,0,20.36653824 0.323,28/06/97 19:00,2.9958,1.9986,0.9971,25.2,1.9988,2.6,1.6039,114.5,86.725,1.7625,1.8363,90,1.8363,1.9986,0.0002,35.6,0,2.033771492 0.674,11/11/97 06:00,6.9953,3.0013,3.994,18.5,3.0017,1.0001,1.7071,-70.493,86.515,1.811,1.8868,-90,-1.8868,3.0013,0.0004,134.3,0,8.163724501 2.199,30/06/97 19:00,21.001,1.0027,19.999,25.1,1.0038,4.5,1.6514,114.39,86.628,1.8131,1.889,90,1.889,1.0027,0.0011,692.8,0,40.74948071 0.352,09/11/97 06:00,3.9995,3.0013,0.9982,19.4,3.0016,1.5,1.7528,-71.074,86.421,1.8529,1.9307,-90,-1.9307,3.0013,0.0002,32.7,0,2.041288325 0.305,08/07/97 19:00,2.9958,1.0027,1.9931,24.5,1.0029,1.7,1.7003,113.68,86.528,1.8565,1.9344,90,1.9344,1.0027,0.0002,67.1,0,4.063626431 0.537,10/11/97 06:00,6.007,6.0027,0.0043,18.6,6.003,1.3001,1.8405,-70.734,86.242,1.9496,2.0316,-90,-2.0316,6.0027,0.0004,0.1,0,0.006554246 0.429,06/11/97 06:00,6.007,6.0027,0.0043,19.4,6.0031,0.9,1.9206,-71.943,86.078,2.02,2.1052,-90,-2.1052,6.0027,0.0004,0.1,0,0.006839837 0.78,30/01/97 18:00,10.995,6.0027,4.9921,22.4,6.0034,2,1.9119,70.497,86.096,2.0282,2.1137,90,2.1137,6.0027,0.0007,149.4,0,10.17189034 0.724,29/01/97 18:00,10.007,5,5.0065,22.7,5.0007,3.8,1.9832,70.173,85.95,2.1081,2.1972,90,2.1972,5,0.0007,144.5,0,10.20559947

Hello, I have a follow up question concerning creating a shading scene for tracking planes in complex terrain. Is this possible? I tried creating a "ground" object with different elevations, but this ground object seems to have zero impact on the shadings calculated (I get the same answer with or without the ground object). Is there a way of positioning tracking planes on top of a "ground" object? If not, is there a way of creating tracking planes on a sloped surface? Or is the only possible approach to this problem to just create tracking planes that are at different elevations? Best regards, Sophie