kjs55

Why not group this "separate loss" with inverter clipping, near the center of the loss tree, rather than placing it at the bottom of the loss tree? Thanks.

Bumping.

Bumping this again.

I have the same question as LauraH.

PVsyst V8.0.12: Hello, the "Operating losses at STC" sections of the PVsyst V8 output PDF report have disappeared (!). See below screenshots as example (V8 screenshot is missing the section; V7 screenshot contains the section on the right-hand side). (NB: Please note the value for Iron Loss Fraction in one of the screenshots is incorrect, as there was a typo in the input. This rapid example was for screenshot purposes only.)

There are common instances when we would apply different "soiling" assumptions (which includes dust, snow, etc.) for different PV module types (e.g., monofacial, bifacial). We would like the ability to apply a different set of monthly soiling values for each subarray in PVsyst V8. This would resemble the subarray dropdown menu for the MQA factor in Detailed Losses. Is it on the development roadmap? Thanks.

P.S. I am referring specifically to this message:

Hi, I'd like to specifically request a 10-min. editing time as an incremental (and meaningful) improvement. Thank you!

PVsyst V8 Problem Statement: How to apply spectral adjustments to certain subarrays (containing certain PV module cell types) and *not* to others? Ideas (example only): 1.) This could be handled in the PV module PAN file, through a checkbox which (if checked) will apply spectral adjustments IF the tab in Detailed Losses is applied 2.) This could be handled as a dropdown menu for each subarray on the spectral adjustment tab in Detailed Losses, similar to the MQA factor subarray dropdown menu, where you can toggle on/off spectral adjustments for each subarray 3.) (Least favorite option): If the spectral adjustment tab of Detailed Losses is applied, it could automatically apply spectral adjustments onto the specific technologies involved in each subarray according to PV cell technology type. This is the least favorite option, because not all PV cell technologies should use spectral adjustments (e.g., single-junction Si-based technologies). Conversely (and preferably), Options 1 and 2 above would allow the user to *only* apply spectral adjustments onto the (sub)set of PV cell technologies in the applicable subarrays which require spectral adjustments. Thank you!

Here's one way CCC could be incorporated into PVsyst, to enable more accurate modeling with standard hourly TMY datasets:

PVsyst V8.0.10 -> Grid-connected -> Load Demo utility project (_DEMO_Utility.PRJ) -> VC4 -> Detailed losses -> Ohmic Losses -> Uses a HV transformer -> Dropdown menu HV to MV Transformer does not work.

Let's imagine you have a 100 MWdc PV system with: - Split Si PV module design using half-cut PV cells in Orientation #1 with split partitioning, and - CdTe PV module design in Orientation #2 with no split partitioning How do you assign: - "according to module strings" with 100% "fraction for electrical effect" for Orientation #1, and - "linear shadings" for Orientation #2 ? Please advise. Thanks.

v7 and v8: Typo in the word "proportional"

Suggestion to add a third option for the ac losses power reference value, namely, a custom user-defined input value field. The reason for this is that sometimes ac losses are not defined at either of the two (2) presently available toggle options in PVsyst, namely, "PNomPV(ac) at STC" or "PNom (inverters)", but rather at some other ac losses power reference value (e.g., driven by the grid limit). Thanks.

Apologies if this is documented somewhere and I missed it (if so, please feel free to point me to the already existing answer). Are "secondary parameters" used in PVsyst's numerical simulations? Or, are these just informative settings? The only help documentation I can find says: "Secondary parameters": sometimes useful parameter. I'm not sure how to interpret this. Please advise. Thanks.

Apologies if this is documented somewhere and I missed it (if so, please feel free to point me to the already existing answer). Would you please explain how the internal transformer settings in the PVsyst .OND file are applied? Or, are these just "informative" settings? Thanks.

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.