kjs55

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.