kjs55

P.S. Please note the 5xxxx3 MWh value also shows up in the Report on the Loss Tree, in the "Balances and main results" table, etc.

PVsyst v7: Sum over E_Grid 8760 is 5xxxx2.3 MWh, which rounds to 5xxxx2 MWh. NB: 8760 has night losses. PVsyst Loss Tree (copied to Clipboard and pasted into Excel) yields 5xxxx3 MWh (no decimal places provided). If you remove one row from the 8760 summation, you get 5xxxx2.5 MWh, which rounds to 5xxxx3 MWh. So this tells me the PVsyst Loss Tree is missing a single row from its summation (namely, it's summing 8759 rows, not all 8760 rows). Please confirm it. (NB: Exact values masked for confidentiality reasons.)

PVsyst v7 & v8: In the PVsyst Report (output PDF file), please note the ambient temperature of all inverter power ratings. For example, please include: Unit Nom. Power (~>50 oC) = 765 kWac where the "at 50 oC" is added. Similar to: Max. power (~> 25 degC) = 840 kWac Please see attached screenshot. Thank you!

Open PVsyst v8.0.8 / demo projects within it, get this pop-up: Please advise.

Sorry, I don't have time to do a detailed bug report. If you cannot reproduce this, please add a comment and I'll add more details. v7 & v8: Activate Power Factor on PF tab of Energy Management. Then go to next tab Grid Limit and activate w/ Apparent Power basis. You'll see the units of Grid Limit change from MW to MVA. Now return to PF tab and deactivate it. Now return to Grid Limit tab. Units of Grid Limit remain as MVA instead of changing back to MW.

I also noticed that the value entered into Grid Limit doesn't round, it truncates. Why? And the allowable significant figures is inconsistent. You can either enter 0.17 kW with max. two (2) sig figs or 999.17 kW with max. five (5) sig figs. Why? The relative (%) impact of the truncation will of course depend on the value entered. It seems like an easy enough fix to allow a fixed number of sig figs, e.g., several (more is better, e.g., so that we can exactly match utility contracts which can be defined as irrational numbers). It also appears that the units go from kW to MW depending on the project's power capacity, so ideally the increased number of allowable sig figs could also be consistent regardless of the units. Thanks.

@S.Faulkner: See PVsyst Release Notes for v8.0.0 ("Corrections"): https://www.pvsyst.com/help/release-notes/index.html#exec-1--corrections "Simulation: the bifacial mismatch loss is now proportional to the Bifaciality factor"

@S.Faulkner: See PVsyst Release Notes for v8.0.0 ("Corrections"): https://www.pvsyst.com/help/release-notes/index.html#exec-1--corrections "Simulation: the bifacial mismatch loss is now proportional to the Bifaciality factor"

bifiMMF = Bifacial Mismatch Loss Factor bifiCoef = PV module bifaciality coefficient ## v8 Help Menu: https://www.pvsyst.com/help/project-design/bifacial-systems/bifacial-systems-results.html v7 Help Menu: https://www.pvsyst.com/help-pvsyst7/index.html?bifacial_results.htm Suggestion #1: I suggest updating the v8 Help Menu loss tree to represent a PVsyst v8 loss tree. Suggestion #2: For this (v7 & v8) Help Menu example, I suggest reporting the assumption used for Bifacial Mismatch Loss Factor, for the benefit of the PVsyst user. Comment #1: It is difficult to reproduce the "Mismatch for back irradiance" value of -2.6% on the loss tree for this example without knowing the value from Suggestion #2. My best guess is the value of bifiMMF must be 16% when using PVsyst v7. NB: I don't think the example is accurate for the updated v8 calculation method. Comment #2: In general, I think this loss value was calculated incorrectly in v7, as = (bifiMMF*GlobBak)/(GlobBak + GlobEff). I say "incorrectly" b/c a statement on the v7 Help Menu page says, "NB: Here, the GlobBakEn is GlobBak * Bifaciality factor." I don't think bifiCoef is used in v7 (I'm running v7.2). Suggestion #3: If I'm correct, I would suggest fixing this comment re bifiCoef in the v7 Help Menu. Comment #3: I think bifiCoef is now used in v8 as (accurately) described in the v8 Help Menu. The difference in results between v7 (no bifiCoef) and v8 (bifiCoef) can be significant, esp. for large values of bifiMMF. Please confirm it.

Hello, Would you please point me to the PVsyst v8 Help Documentation for how to apply the subhourly clipping loss when all you have is hourly meteorological (aka solar resource) data for a given site (which is almost always the case)? I was just reading this PVsyst Help Documentation <https://www.pvsyst.com/help/physical-models-used/grid-inverter/subhourly-clipping-correction.html>, and I noticed this sentence: "The only prerequisite to apply the model is to have a MET file that has been generated using sub-hourly irradiance data." Are you aware that this "only" prerequisite is almost never available, in the standard PVsyst modeling use case? Therefore, I think I must be missing or misreading something. I'm hoping you can please explain this to me here and point me to the relevant PVsyst Help Documentation that I'm presently unable to easily find. Thank you.

Spatial Smoothing is the newly released supplement to Triple-C. CCC-modeled clipping losses can be reduced by 1% per annum with Spatial Smoothing with a sufficiently large PV array size. See proceedings of Sandia PVPMC 2024: Spatial Smoothing Reduces PV Clipping! by Tim Townsend <https://pvpmc.sandia.gov/download/7908>. Please implement CCC+SS immediately in PVsyst.

P.S. I forgot to include the title of the newly published CCC white paper by Townsend and Sauer: Full title: Triple-C: Clouds, Capacity, and Clipping A Method to Correct Traditional Hourly-Based PV Simulations to Account for Subhourly Clipping Loss Short title: Triple-C: A Subhourly Clipping Correction for PV Modeling

The Triple-C ("CCC") white paper is now available at the following URL: https://www.linkedin.com/posts/tim-townsend-93a4a711_triple-c-a-subhourly-clipping-correction-activity-7138341773319331840-kNWO/ The authors, and many other major PV industry stakeholders, would like PVsyst SA to please directly incorporate this specific modeling option into the PVsyst software program as soon as possible. Thank you.

My understanding is that a fixed var output for all timestamps would not require any grid data. Is this not the case?

I was reviewing Slide 115 of the presentation linked in Ref. [1]. I'm wondering which of the following four (4) operational modes listed on that slide (pasted below for convenience) can be modeled in PVsyst? Thanks. A couple other general, related Qs: 1. Is it possible to model fixed var operation (mode) in PVsyst? 2. Is it possible to model fixed var operation (mode) in PVsyst for BESS-coupled PV systems? (i.e., when modeling both the BESS and PV system in PVsyst) BESS = Battery energy storage system [1] https://www.nerc.com/comm/PC/IRPTF Workshops/IRPTF_Workshop_Presentations.pdf Excerpt from Slide 115 of Ref. [1]: 1. Constant power factor or VArset-point Configure inverter with fixed Varoutput. 2. Controlled power factor or VArvia comm’s) Send Varsetpointcommands to inverter via Modbus/TCP 3. Autonomous VArcontrol (depending on V) VoltVArcontrol based on curve 4. Autonomous power factor control depending on real power output VArsas a function of Watts