kjs55
-
Posts
126 -
Joined
-
Last visited
Posts posted by kjs55
-
-
Hi,
Someone recently pointed out to me that there's a mismatch between the equation for shunt resistance (Rsh) in the PVsyst help menu linked in Ref. [1] and Eqs. [5]-[6] of the paper in Ref. [2] (incidentally, also Eqs. [6]-[7] of the more recent paper in Ref. [3]; the latter paper incorporates the temperature-(not just irradiance)-dependence of PV module performance into the PVsyst one-diode model). Firstly, Eq. [6] of Ref. [2] is not in the PVsyst Help Docs in Ref. [1] at all. Reportedly (according to Ref. [10] within the paper in Ref. [2]), Eq. [6] in Ref. [2] came from a personal/private communication with the paper's author. Secondly, the term Rsh_base is replaced by Rsh_ref in the PVsyst help documents. It would be good if the PV community can reference the PVsyst help menu in Ref. [1] instead of the papers in Refs. [2]-[3] when it comes to applying the PVsyst one-diode model. For example, the Photovoltaic Performance Modeling Collaborative (PVPMC) community's website (Ref. [4]) and the associated, relevant PVLIB Toolbox function (Refs. [5]-[6]) could then reference the PVsyst Help Docs in Ref. [1] instead of the paper in Ref. [3]. If possible, please advise, and, if necessary, please update the PVsyst help menu in Ref. [1] in order to clarify this point. Thanks.
References:
[1] https://www.pvsyst.com/help/. Then navigate to "Physical models used" > "PV Module - Standard one-diode-model" > "Rshunt exponential behavior vs irradiance".
[2] K. J. Sauer and T. Roessler, “Systematic approaches to ensure correct representation of measured multi-irradiance module performance in PV system energy production forecasting software programs,” IEEE J. Photovoltaics, vol. 3, no. 1, pp. 422-428, Jan. 2013.
[3] K. J. Sauer, T. Roessler, and C. W. Hansen, “Modeling the irradiance and temperature dependence of photovoltaic modules in PVsyst,” IEEE J. Photovoltaics, vol. 5, no. 1, pp. 152-158, Jan. 2015.
[5] https://pvlib-python.readthedocs.io/en/stable/generated/pvlib.pvsystem.calcparams_pvsyst.html
[6] https://pvlib-python.readthedocs.io/en/stable/_modules/pvlib/pvsystem.html#calcparams_pvsyst/
-
Hi, I don't have data to upload now (I can provide as needed), however, the new IAM models available in PVsyst based on Fresnel Equations and Snell's Law are much more accurate for real-world PV modules than the ASHRAE model. I suggest leaving the ASHRAE IAM model in PVsyst for posterity (& important comparisons) & labeling it as "deprecated" (so it's available but users are no longer inclined to use it). On a related note, I also suggest changing the default IAM profile in PVsyst to the custom IAM profile for "normal" glass (again, based on Fresnels Equations & Snell's Law). (NB: I'm on v6.8.8.) If a module manufacturer opts to apply an anti-reflective coating ARC to a given module type & they wish to represent it in the PVsyst .PAN file, they can update it to the "AR coating" setting to "reflect" that (pun intended) and achieve the associated gains over whatever timescale is expected for the given O&M processes (e.g., module cleaning), specific weather events, soiling compositions (e.g., organics build-up), and general weathering (wear-and-tear of all the elements--full spectra of light incl. UV, humidity, mechanical loads, temperatures, &c.). Thanks.
-
Hi:
PVsyst v6. Please add MPPT Efficiency to the list of "Contractual specifications, without real physical meaning" in the .OND file.
This value is commonly reported on datasheets, etc. It relates to unavoidable losses from oscillations about the knee of the power vs. voltage curve (e.g., due to granularity limitations from both component/hardware choices and software algorithms--these losses are unavoidable even with an ideal curve). It would be good to keep track of the nameplate value in an inverter's .OND file.
Thanks.
-
It is unclear to me why there needs to be multiple redundant buttons and input fields for the same parameters across different screens in PVsyst, e.g., pitch, collector width, backtracking Boolean, etc., namely, in both the Bifacial System Definition screen and also the Orientation screen, e.g., when would you want these parameters to differ from one another across screens? Thanks.
-
If you have set up a bifacial system in the tab "Unlimited Trackers 2D model" and then you unclick the "Uses backtracking" toggle button, the GUI recognizes no change. In fact, the behavior of this backtracking button is altogether quite strange, namely, it is often unclear if the button is doing what you think it is doing or how it relates to the one on the "Orientation" screen.
-
There are many variants of version names in use by PVsyst: v6.8.8, V6.8.8, v6.88, V6.88, v688, or V688. These can all have different interpretations and meanings. Is it possible to consolidate to use one, consistent convention, or is there a reason for each one? Is there one that is most correct for PVsyst? Would you please explain it in the PVsyst Help Menu? Thanks for your consideration.
-
Everyone in the PV industry spells PVsyst differently. PVsyst, PVsyst, PVsyst, etc. Even your website has multiple spellings. And, when you Google it, it's spelled different from the website. Is it possible to consolidate on one, consistent name? (My vote is "PVsyst"). Would you please explain it in the PVsyst Help Menu? Thanks for your consideration.
P.S. Update on 2020-12-29: I noticed both Google and the website are since updated to "PVsyst". Thanks.
-
Open existing PVsyst v6.88 grid-connected bifacial project on horizontal single-axis tracker with unlimited sheds. Look at "Results overview". Where does this energy value come from? Click "Run simulation" and perform simulation again. Save new results which are different from what was previously presented in the Results overview. Close PVsyst. Re-open PVsyst. And now the values in the "Results overview" are back to the ones you don't understand, and they don't match the results from the simulation you just ran and saved (nor does the PVsyst output PDF report).
Applies to: v6.88 and v6.83. I did not check any other versions.
-
Open PVsyst v6.88. Go to Databases. Grid inverter. SMA. Sunny Tripower 60-US-10 (480 VAC). Open the OND file. Go to Data source, and add the word "Test" at the end. Click OK. Check the checkbox so it is ON for "File compatible with old versions < V6.40". SaveAs (add space here in code a la "Save As"). Add "_Test" at the end of the filename; namely, save as "SMA_Tripower_60_US_10_480_Test.OND". !!! ERROR MESSAGE POPUP !!! It says: "File "SMA_Tripower_60_US_10_480_Test.OND" : (remove space here in code b/w end quotation and colon) Wrong object Type: Read = Undef, waited = GInverter ... Do you want to invalidate it?"
Please advise on why the older inverter .OND file format cannot be saved in PVsyst v6.88!!!
-
PVsyst v6.86, batch mode, tracker optimization parameters: What is the difference between "Pitch E-W between trackers" and "E-W row displacement by respect to first row"? Specifically, what is the latter? Also, where is this documented in the PVsyst help documentation?
-
PVsyst v6.8.0. The date column of the output CSV file varies back and forth several times from this format:
12/11/2018 11:00:00 PM
To this format:
13/11/18 00:00
Steps to see this: 1.) Run simulation, 2.) Save hourly output CSV file, 3.) Open in Excel, 4.) Convert text to columns via semicolon delimiter, 5.) Look at date column
Is this bug fixed in PVsyst v7?
-
Is PVsyst planning to add the ability to import and use sub-monthly albedo data (particularly for modeling bifacial aka Bifi systems), e.g., measured hourly albedo data (including for comparing measured and modeled PV system energy)? Thanks.
-
Please create .RCK files to capture all necessary modeling inputs aka characteristics of racking (aka mounting) systems, similar to .BTR, .OND, and .PAN files for batteries, inverters, and PV modules, respectively. PVsyst .RCK files must cover both fixed-tilt and tracking racking systems. Racking manufacturers and suppliers can conveniently issue PVsyst .RCK files to their customers. There is a host of other advantages including preserving run settings for posterity and improving model transferability across companies and PVsyst users (altogether, improved model reproducibility). Thanks.
-
In addition to my above question, is it the pre- or post-LID bifaciality coefficient?
-
PVsyst v6.8.6: Import measured horizontal single-axis tracker POA irradiance, then go to do "Measured data analysis" under PVsyst\Tools, go to Orientation, and there is a warning: "The meteo data were calculated from a solarimeter positioned in a plane of 0° and azimuth 0°." There should be no such warning -- when the pyranometer data was imported, it was defined as tracking (i.e., mounted coplanar with the PV modules on the horizontal single-axis tracker) and not at a fixed tilt/azimuth. So, the warning should go away.
-
PVsyst v6.8.6: Open an existing bifacial .PAN file, update the bifaciality coefficient, and it does not ask if you wish to "save as" over the existing file.
-
If bifacial toggle is selected first in .PAN, you can't save bypass diodes settings.
-
PVsyst v6.8.6. Horizontal single-axis tracker with unlimited sheds. 1.) The value entered into "Shed total width" does not save, and 2.) the "Uses backtracking" toggle checkbox Boolean does not save.
-
According to IEC 60904-1-2, a PV module's "bifaciality factor" aka bifaciality coefficient is the minimum of the bifaciality coefficients of Isc or Pmax (i.e., whichever is lower). The PVsyst help menu [1] says to use the bifaciality coefficient of Pmax. Please explain why PVsyst is not aligned with IEC 60904-1-2 in this regard. Thank you.
-
The crashing problem that affects PVsyst v6.7.8 was fixed in later versions. Thanks!
-
According to @solarguru in Ref. [1], the following post is outdated and needs to be updated:
https://forum.pvsyst.com/viewtopic.php?t=40/
[1] https://forum.pvsyst.com/viewtopic.php?f=4&t=4587
@solarguru claims that Perez (not Hay) should be used
Please confirm it
-
Nonetheless, I think it is important that users understand the impact of pitch for bifacial
## Mono-facial (v6.84)
Pitch = 10.22 m; Annual Energy = 2803 kWh/yr
Pitch = 100000 m; Annual Energy = 2820 kWh/yr
Impact: 0.6%
## Bifacial (v6.84)
Pitch = 6.6 m; Annual Energy = 4479 kWh/yr
Pitch = 100000 m; Annual Energy = 12694 kWh/yr
Impact: 283%
(NB: The mono-facial system above is not the same as the bifacial system apart from bifaciality; so, please do not compare 4479 to 2803 kWh/yr, etc.; "impact" above is the annual energy deviation b/w pitch #1 and pitch #2 for either mono-facial or bifacial; "impact" can be compared across mono- vs. bi-facial)
-
Thanks @solarguru but the deviations I reported are larger (>10%) using Perez vs. Hay
I am interested to hear PVsyst's opinion on this
There are no issues reported for the imported measurement data however the PVsyst POA does not match the imported values
-
PVsyst v6.84: I am importing measured irradiance data from a tilted global POA pyranometer (GlobInc aka GPI). I would expect Mod GlobInc to exactly align with the Mes GlobInc that I am importing; however, this is not the case.
The first measured GlobInc value is 446.7 W/m^2. Upon importing, I look at the modeled GlobInc value at the same timestamp. GlobInc (Hay model) for the same tilt and azimuth is 416.0 W/m^2. So, there is a 7% deviation b/w Mes and Mod GlobInc at this timestamp (at times the deviations are larger than 7%).
The deviations are notably larger at the edges of the day (morning/afternoon) compared to around solar noon.
I have set PVsyst to use the Hay transposition model per the following post:
https://forum.pvsyst.com/viewtopic.php?t=40/
Another note: For both Hay and Perez, it reports albedo = 0.2 for GlobInc; however, there is no option to define albedo when importing custom measured irradiance. Should albedo be a user input to the custom data import tool?
Allow Upvoting of Topics and Label Topics as Resolved or Closed on PVsyst Forum
in Suggestions
Posted
Hi,
I'm looking at the 24 pages of unanswered PVsyst Forum topics submitted by PVsyst's paying ($$) customers & users as of 2021-04-15.
It'd be neat if:
1. We (PVsyst users--perhaps specifically those w/ user accounts on the forum) could somehow upvote topics on the PVsyst Forum*, &
2. PVsyst clearly designates ticket status as Open, Resolved, or ultimately Closed (e.g., w/ labels aka tags).
*e.g., To show importance & help w/ prioritization (somehow need to limit repeat voting; perhaps tied to PVsyst Forum account? e.g., one vote per account per topic, so we can cast our votes while logged in...dunno)
Another option is to add work status tags: Approved, In Progress, Rejected, To-do, Under Review, etc.
I did a quick Google Search &, e.g., this list of status terms came up for Jira:
https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-statuses-priorities-and-resolutions/
Thanks.
P.S. Updated "Issues" -> "Topics" as it looks like the PVsyst Forum uses the term "topics".