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