kjs55

I suggest changing the default option of "AC losses power reference" in Project Settings from "PNomPV(ac) at STC" to the more physics-correct "PNom (inverters)". Thanks. I'm running PVsyst v7.3.

Hello, I'd also like to kindly request that PVsyst please update us (the userbase) on this. It's now common to mix multiple orientations in one single series string in the case of DC/DC optimizers (e.g., SolarEdge). However, PVsyst's above reply indicates it's not possible to model this common, real-world scenario in PVsyst. Is it possible as of today's latest version (PVsyst v7.3)? If so, how? If not, is it on PVsyst's product development roadmap? If so, what's the anticipated release date? If not, why? Any such guidance is much appreciated. Thanks.

Hi, I'd like to follow up on this post as it's becoming more common to have inverters which derate power output as a function of dc input voltage. I don't understand the above response by PVsyst as to why this cannot be directly implemented in PVsyst (e.g., via additional inverter characteristic definition settings in the .OND file) in a straightforward manner. Please clarify it. Thanks.

Thanks for the above dialogue. Thus, it seems to me like it would be more clear and consistent if each usage of "Tmod" in the PVsyst Help Menu (I count approx. 5 instances) changes to "Tcell". Also, if the output of PVsyst is Tcell (not TArray). Or, if it stays TArray, it could be more clear that TArray is "Average CELL temperature during running" (not MODULE). This is because module temperature, implying PV module backsheet surface temperature during operation, is not the same as cell temperature. There's also the option to export columns of both Tcell and Tmod, where the difference is attributed to the temperature delta (gradient) from backsheet surface to PV cell according to the King/Sandia equation & corresponding coefficients in [1], where PV cell operating temperature Tcell is higher in temperature (i.e., runs hotter) than PV module backsheet surface temperature during operation Tmod. One more note: The same PVsyst thermal model equation appears twice in the help menu in different forms: One using Tmod and one using Tcell. By and large in the PV industry (e.g., in literature on PV performance such as [1]), these are two different physical variables representing two different physical measurands. [1] King, D. et al, 2004, “Sandia Photovoltaic Array Performance Model”, SAND Report 3535, Sandia National Laboratories, Albuquerque, NM.

I think having a specific/dedicated, labeled placeholder (user input field) for it would make it clear to the PVsyst user that it's essential to include in the uncertainty propagation used to derive the P90s, etc. (being a primary, & often the #1, source of uncertainty in the propagation).

Hello, I see several options to mark items on the PVsyst Forum as "read" (e.g., here [1]), but I don't see any options to mark items as "unread". Is it possible to add such a feature? Or, would you please tell me how to mark items as unread (if the feature already exists)? Thanks again! [1] https://forum.pvsyst.com/forum/3-your-questions-about-pvsyst/

@dtarin: "Typically" according to whom? Please provide a reference (preferably written by the PVsyst team, unless you work for PVsyst in which case I accept your reply).

The weather (solar resource) data uncertainty contribution (e.g., solar irradiance measurement uncertainty) appears to be missing from the uncertainty propagation in PVsyst (?), thus leading to significantly overly aggressive P99s. Please consider incorporating this #1 source of uncertainty into the uncertainty analysis in PVsyst. Thanks.

Edit: Even simpler option, b/c there's already a section on "3D shadings parameter": Existing language: """Plane orientation - Modify tilt, azimuth, or shed characteristics (pitch, electrical effect) if unlimited sheds defined.""" [1] https://www.pvsyst.com/help/batch_mode.htm New proposed edit: """Plane orientation - Modify tilt and azimuth for fixed tilt orientation (presently limited to a single orientation) plus shed characteristics (pitch, electrical effect) if unlimited sheds defined."""

Hello, I saw this post at the same time as the other. In the PVsyst help documentation for batch mode [1], it presently says: """Plane orientation - Modify tilt, azimuth, or shed characteristics (pitch, electrical effect) if unlimited sheds defined.""" [1] https://www.pvsyst.com/help/batch_mode.htm Of course, I defer to the @PVsyst team, but I propose this edit: """Plane orientation - Modify tilt and azimuth for fixed tilt orientation (presently limited to a single orientation) plus shed characteristics (pitch, electrical effect) for unlimited sheds and certain other characteristics (Nb. of trackers, backtracking, phi limits) for tracking PV arrays."""

Hello, I happened to see this post and discussed it with a colleague and we have a few initial Qs: 1. What's the GCR in both cases (fixed tilt and tracking)? 2. What's the tilt angle of the fixed tilt PV system? 3. What's the tracker rotation limit (for the tracking PV system)? Thanks.

Is it on PVsyst's product development roadmap to enable users to run custom 8760s of tracker (phi) angles? I see this as becoming increasingly important given the increasing prevalence of custom tracking/backtracking algorithms, hail + wind stow strategies, etc. Other, PVsyst-competitor PV simulation software programs (e.g., DNV's SolarFarmer) are reportedly already offering this modeling feature in their energy production simulations. Thanks.

I just set a Grid power limitation such that the Hidden Parameter "High Grid Power limitation Power Ratio" set point value is exceeded. I was able to run a simulation with no errors/warnings/error messages/warning messages. I did not test whether the Hidden Parameter "Low Grid Power limitation Power Ratio" is also ignored.

I can't figure out how to apply a grid power limitation of <1 kW. I tried changing the Hidden Parameter "Low Grid Power limitation Power Ratio", and it didn't work. Also note that the the simulation says "Ready for simulation" in green, but the option to "Run Simulation" is not available (grayed out).

Suggestion is to add one decimal place (significant figure aka significant digit) to the azimuth and tilt in the PVsyst output report PDF (instead of rounding to the nearest integer) to match the inputted azimuth and tilt model parameters in the PVsyst model.

Please add a "Clear Formatting" option to the PVsyst Forum. e.g., When you paste content into a new forum post and then add a carriage return somewhere within the text, it results in extra line spacing. It'd be helpful if we could then highlight the entire text and click "Clear Formatting", so we can resolve this formatting issue.

A useful starting point would be a clear specification of the measured GPI (see my comprehensive list of real-world options above). Namely, please instruct us clearly on how to properly measure GPI data for application/import into PVsyst. I thought at one point I'd seen it written that the measured GPI data must be entirely unshaded (within geometrical/physical limits), but I just looked through the PVsyst Help Menu, and I can no longer (easily) find this instruction (so perhaps it never existed). Considerations: - Monofacial (front-side irradiance only) vs. bifacial (rear-side irradiance also) - Pyranometer (dome-shaped) vs. reference cell (flat-glass) - Shaded vs. unshaded Keywords (search terms): ASCII text file Back-side irradiance Bifacial Custom file import tool Dome-shaped Front-side irradiance Global Plane-of-array POA Irradiance GPI Global Tilted Irradiance GTI Incidence Angle Modifier IAM Measured data Measured GPI Meteorological meteo weather data Monofacial PVsyst Pyranometer Rear-side irradiance Reference cell Shadings Sunny-side down Sunny-side up Unshaded

I think it would be a useful feature to allow the custom import and direct use (simulation) of measured weather data (without hourly averaging). I think it would be relatively straightforward to write a PVsyst wrapper where the data is preprocessed into several 8760s on the front end, run through the core PVsyst tool as normal, and then post-processed on the back end. Namely, 1-min. measurement data is split into (60) 8760 files, 5-min. data is split into (12) 8760 files, etc. on the front end. Then, normal PVsyst is run over a loop (60x or 12x, respectively), with the appropriate time shift for each run. Then, the resultant output files are recombined on the back end (back into a 1-min. or 5-min. data set, respectively). In other words, there are really no major changes to the core PVsyst tool needed in order to implement this feature to enable simulations of (at least) custom, imported subhourly measurement data. Thanks.

Help Menu Navigation: Project design > Shadings > Calculation and Model > Treatment of the Diffuse component > Global calculations on diffuse Emphasis mine (bold italics): """Therefore for each direction, we should evaluate the product of the Far shadings, Near shadings and IAM loss as parameter for the integral. Along with the last irradiance loss (soiling, independent on the direction), this leads to a constant global loss factor for diffuse, used for the calculation of the "Effective diffuse" component in the simulation.""" The use of the word "should" here leaves me w/ the question: Would you please confirm that Near Shadings are included in diffuse irradiance shadings? Even for unlimited sheds, i.e., not only for 3D scene modeling? Many thanks.

Would like the option to time shift imported data by, e.g., 2.5-min. (or 7.5-min., etc.). Presently, it appears PVsyst only allows imported data time shifts in integer intervals (increments).

Sorry, I must have made a typo. I meant to say that I'd like the option to set Energy units to Watt-hours Wh in this GUI Window #1: 1. PVsyst > Settings > Preferences > Default values Presently, you do have the option to output data in Watts (Watt-hours), not just kW (kWh), in this GUI Window #2: 2. Grid-connected > Advanced Simul. > Output File > Units As I said above in this thread, in general, I'd like the settings of GUI Window #2 to draw from the user-defined settings of GUI Window #1. If you don't want to use W (Wh), then I suggest to remove the option altogether from the PVsyst software program (i.e., from GUI Window #2). Finally, I'm not sure why the unit in GUI Window #2 says "Power" while the unit in GUI Window #1 says "Energy" (I think this confusion led me to make my previous typo). Hope that makes more sense. Thanks again.

Suggest to allow modeling multiple sub-arrays w/ the same orientation. Presently, you get the error "The orientation X is redundant. Do you want to delete it?" Would eventually like to assign albedos (#1) and shading scenes (#2) to different sub-arrays, even if those sub-arrays have the same orientation. I've already added posts to the PVsyst Forum requesting these two (#1 & #2) features.

Would like the option to model multiple albedos for a given project (rather than the existing, project's global implementation). Not sure how to best implement this; perhaps associated w/ each sub-array. I'll follow up if I think of any other ideas. Thanks.

Following up on this. ~1-min. is not enough time to make important edits to our PVsyst Forum posts. Thanks.

It is reported in literature [1] that the p50 (median) derived from a Monte Carlo- or convolution-based uncertainty analysis [2] is more appropriate to use (and not always the same) as the primary AC energy into grid value (E_Grid simul) that comes out of PVsyst. e.g., Not all the distributions that feed into the Monte Carlo are normal Gaussian distributions (e.g., the Gamma-shaped degradation rate distribution from Dirk Jordan [2]-[3]). Does the p50 in the PVsyst p50 estimation directly use E_Grid simul? Or is the p50 derived from the uncertainty analysis? Is it really a median p50 (or is it simply E_Grid simul)? [1] https://www.researchgate.net/publication/318259323_A_Framework_to_Calculate_Uncertainties_for_Lifetime_Energy_Yield_Predictions_of_PV_Systems/ [2] https://www.eupvsec-proceedings.com/proceedings?paper=19917/ [3] https://onlinelibrary.wiley.com/doi/10.1002/pip.3566/