laurahin

Thanks for your reply, but I don't understand the answer. As stated above, the help section indicates that EArray is like EArrMPP when inverter operating point displacements are taken into account. To me, this means that any energy lost because the inverter is unable to maintain proper PP tracking is subtracted from EArrMPP to get EArray. As far as I know, that's nothing like "the mppt DC energy minus the [inverter and POI] clipping losses," so either the documentation is unclear or I don't understand PP tracking (or both). Perhaps the equations shown above could be included in the documentation, for clarity. I don't see why EarrMPP - (IL_Pmax + EGridLm) would be of any interest and wouldn't have paid it any attention if I'd seen the equation. We are modeling the storage system outside of PVsyst, so the question is which value gives the full available DC energy out of the array, regardless of whether the battery is charging or the energy is being sent to the grid. The answer appears to be EArrMPP. Thanks!

Hi, I printed out EArrMPP, EArray, EOutInv, and E_Grid from my recent PVsyst runs so I could track the losses through the simulations. Based on the PVsyst help info, my understanding is that EArrMPP is what would come out of the array if MPP was always maintained and EArray is what the array actually delivers, accounting for power point offsets. When no inverter or POI clipping was involved, everything made sense: EArrMPP > EArray > EOutInv > E_Grid. However, as soon as any limiting occurred, EArray decreased so that it was approximately equal to E_Grid, giving EArrMPP > EArray < EoutInv > E_Grid, which makes no sense. Can you explain this? (I fully admit that my understanding of EArrMPP and EArray might be incorrect.) I’m concerned about this because we sometimes report available energy out of the array to clients wanting to employ BESS on the DC side and I believed that EArray would be the appropriate value to use. Thanks.

Perhaps you thought I meant ground tuning. I strongly support the use of ground tuning to reduce local biases in satellite resource data sets. This can be very effective, if performed using quality measurements and appropriate tuning algorithms. I lean towards letting the satellite data providers perform the tuning because they are the best experts on what affects solar irradiance in their models.

You're welcome. I spent quite a lot of time reading Meteonorm's materials. At the moment, I would only use data from the major commercial providers, such as CPR, Vaisala, or Solargis. Unfortunately, it's difficult to know which is the most accurate at any given location -- only validation work can prove this and the companies won't let anyone publish intercomparisons. By "careful tuning," I'm referring to the fact that it's not enough to start with good satellite data and throw some equations at it. The provider must work on calibrating the satellite data, adjusting methods for different satellite instruments and different land surface types, and verifying that the results are consistent around the globe in order to produce good irradiance estimates.

Thanks!

We've been confused by seemingly contradictory information about the application of time shift data to imported meteo files. The question is what you have to do to get a time shift to be applied in the calculations, and whether it's sufficient to click on "Apply time shift correction" on the "Check data quality" window or whether the data must be reimported. Differences in the documentation are as follows: 1) https://www.pvsyst.com/help/meteotables_graphsform_datacharacteristics.htm: This page implies that you can just click on the "Apply time shift correction" button to use the time shift. Note that no one in our group has ever found a way to save the MET file from the "Check data quality" window. During the simulation PVSyst has the possibility to apply a time shift correction, expressed in minutes, to the calculation point which is always the middle of the hourly interval. Setting an adequate correction is extremely important to get good calculation results. The time shift defined in the .MET file is the result of an iterative process. The correction is considered as active when the user checks the box "Apply time shift correction" and saves the file. Once again, this correction shall not be confused with the values specified in the source file. As an example, in the screen shot given below : [Screen shot shows "Apply time shift correction" checked.] - the user has first defined a -1 hour shift together with a + 2 minutes time shift in a PVSyst standard file - he finally decided to set a +3 minutes time shift after considering the Check data quality tools of PVSyst. - the +3 minutes time shift is the value written in the .MET file. It will be applied during the simulation. [Screen shot follows, then] In the screen shot given below [Screen shot shows "Apply time shift correction" unchecked.], the user decided not to apply the Time Shift defined in the source file. By doing so, PVSyst will not consider any minute shift during the simulation. [Screen shot follows] Both screen shots include the following, which seems to imply that a time shift has been recorded in the MET file in both cases. 2) https://www.pvsyst.com/help/meteo_notes_timeshift.htm This page says that you have to reimport the data to apply a time shift: - First import the data without precautions. The program will guide you to the graphs for the assertion of the correct time shift. - Evaluate the effective time shift of your data. - Apply the observed TimeShift corrections in the format protocol, and re-import the data. Toward the bottom of that page, a flow chart of instructions for adjusting time shifts is shown. It has one place where it says to reimport the data to correct the time shift, but later says to re-adjust the data and save it. What gives? As mentioned, we have never found a way to resave the MET file after applying the time shift by clicking on "Apply time shift correction" and we have never observed a time shift to be noted for future use of a file using this method. Of course, on https://www.pvsyst.com/help/meteotables_graphsform_importeddata.htm, we have "Do not confuse between the time shift defined in the source file and the time shift used by the simulation, whose value is shown in the Data characteristics section of this form." ?

Personally, I would be hesitant to trust Meteonorm data, except possibly in Europe. If you read the documentation carefully, you will find that the data at each location is a mish mash of measured and satellite data. Within the measured data, values can come from multiple locations different distances away from your desired location, and the number of years covered by the satellite data depends on location, with only two years used in many areas: "The hourly pictures of the visible channel of the 5 geostationary satellites have been used (period 2008–2020 for MSG, 2019-2020 for Himawari and 2018-19 for GOES-E and Indoex)" (Meteonorm 8, Handbook Part II: Theory, p. 4) (I have also never seen documentation of the quality of the satellite estimates, but it may be out there.) The methods used to select and combine data from various sources is described in the same document. As you are aware, more ground data is available in certain regions than in others. I don't want to completely knock Meteonorm. At the time it was first developed, it made excellent use of the data that was available, which is likely where its good reputation originated. These days, though, it's possible to produce more consistent resource data sets using long satellite records and careful tuning. You still can't beat a long-term, high quality measurement, though!

Hi, Questions about 3D scenes seem to come up in multiple places in the forum, so I will ask a summary question here: Is it true that PVsyst's ability to handle 3D scenes is different for fixed tilt and tracker systems? My understanding has been that PVsyst can only handle a limited number (8) of fixed tilt orientations in a single scene and that bifacial modeling cannot be included in this case, but we have had no problem treating PVcase scenes with 3D terrain and trackers, whether we use bifacial modules or not. We assume that the difference is caused by the potentially infinite number of "compound angles" produced when the terrain skews fixed tilt racking because PVsyst cannot model this many different geometries in a single scene. Thanks, Laura

Great, I'll give it a go. These are 1P tracker tables that were created individually then copied. I tried to change them by selecting all of these objects and using "Modify selected objects." I have a second question, which is why you have to click on the parameter you want to change twice to enter the new value in the "Modify selected objects" interface. Why can't you just enter it on the line instead of spawning a popup box?

I made a shading scene with groups of trackers using strings of 26 modules and now the designer has requested an update to 25. I thought I would be able to change all of the tracker groups at once, but the results never match my inputs. For example, there are groups with three strings, i.e., 78 modules per row. When I select multiple groups and put in 75 for the length in modules, they all change to 160. If I also enter 1 for height (not needed but...) then I get 36 modules in width. Has anyone else had this experience? Am I going to have to change the string length separately for every group??

dtarin -- Thanks for the time you spent on your reply. I agree that the difference in production when you change the order of IAM and soiling losses should be small. However, applying the IAM loss first doesn't make physical sense. If sunlight is blocked by dirt, it never reaches the glass, so is not affected by IAM loss. So the incoming irradiance should first be reduced by the soiling loss before applying the IAM loss. Changing the order shows that you understand these processes (and should make the calculation ever so slightly more accurate). So I would recommend that to the PVsyst folks.

Hi, It's happened fairly frequently in our group that the specification of table sizes in the shading scene has changed when we reopen a PVsyst project to do an update (could be days or months since the original project was completed). Tables that were defined in terms of numbers of modules are now defined in terms of sensitive area. We have to go back and compute what the numbers should be, then change all of the settings ("by module," "number in x," "number in y," and sometimes orientation as well). This requires a great deal of effort. For example, I had to recreate 60 separate groups of tables today because I couldn't modify several of them at once. Can this be fixed? Note: This is separate from the problem that the objects sometimes move relative to the background upon closing and reopening PVsyst. At least in that case groups of tables usually move together so it's faster to fix. Thanks, Laura H.

Is it true that the losses are applied in the order shown in the waterfall diagram? If so, why is the IAM loss applied before the soiling loss when the IAM loss only occurs when the light impinges on the module surface? By definition, light doesn't reach the panel if it encounters soiling. I don't know how much difference this would make to the overall calculation, but the current ordering doesn't make physical sense. Thanks.

Thanks. I'll check it out. Life has improved since 2014, then?

Would it be possible to just allow limited functions, like building shading scenes, at the same time a simulation is running? It's inconvenient to be completely unable to work in the meantime. Thanks.