kjs55
-
Posts
126 -
Joined
-
Last visited
Posts posted by kjs55
-
-
The Triple-C ("CCC") white paper is now available at the following URL:
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 -
PVsyst v7.4.2: I'm generally curious why the units of energy are listed as kW in the PVsyst 8760 CSV output file rather than kWh. The below link [1] lists it as kWh. It seems the units of apparent and reactive power are listed as kVAh. However, a client wrote to me and asked if the units of EReGrid ought to be kVARh rather than kVAh. Please advise. Thanks.
-
A couple more observations in addition to what I listed above:
- Change E_GridApp to EApGrid [1]
- Change E_Regrid to E_ReGrid [2]
[In general, I'm surprised these modeled data variable names, which appear in the PVsyst 8760 CSV output file, don't follow the existing, preceding "E_Grid" naming convention (e.g., "E_GridApp", "E_GridRct", "E_GridLim"), but O-K.]
Thanks.
[1] https://www.pvsyst.com/help/index.html?power_factor.htm
[2] https://www.pvsyst.com/help/simulation_variables_grid.htm
-
PVsyst v7.4.2: I suggest adding a power factor PF column to the PVsyst 8760 CSV output file. It would save us a bit of time from having to manually calculate it from the existing columns (aka modeled data variables) provided. Thanks.
-
PVsyst v7.4.2: Today I also noticed the mismatch between the summed E_Grid column in the 8760 CSV output file and the E_Grid values listed in the PDF report output file. They don't round to the same value. Sure, it's not significant. But I also don't understand why there's any mismatch. (And it's one more detail to have to retain in one's memory and explain to people.) I think pointing out such mismatches is useful in general, because it can sometimes (potentially) indicate other issues in the codebase. Thanks.
-
Running PVsyst v7.4.2
Generate 8760 CSV output file using default settings.
Open 8760 CSV output file in Microsoft MS Excel.
Highlight first column (Column A).
Data tab > Text to columns > Delimited > Next > Semicolon > Finish
Warning: There's already data here. Do you want to replace it?
Because there's some data in columns B and C.
I don't think there should be data in any column except for Column A.
Thanks.
-
No problem! Thank you!
I just happened to notice "Syst ON" at the same link above -> "Syst_ON"
Thanks again!
-
P.S. I forgot to include the title of the poster (PVPMC link above) which I'm adding now partly for my own future copy/paste benefit:
The Triple-C Method for Correctly Simulating PV Clipping Loss by Townsend & Sauer et al.
-
Slight editorial suggestion to add the underscore "_" to the IL variable names listed in the PVsyst Help Menu, e.g., here:
https://www.pvsyst.com/help/simulation_variables_grid.htm
In all cases where PVsyst variable names are listed in the Help Menu, I hope the variable names are listed in the exact same syntax (spelling, capitalization) as what's used in PVsyst (e.g., what's visible to the PVsyst user in the software program, in the output files, etc.). Thanks.
-
I watched your recent YouTube tutorial on fitting the PVsyst one-diode model to measurement data (measured I-V curve data as a function of irradiance and temperature) [1] which said something to the effect of optimizing all five (5) PVsyst one-diode model parameters simultaneously won't give good results and so PVsyst doesn't advise this. I'm wondering if you have a citation for that (?). Ref. [3] of my previous post above, which is available to download for free [2] and which builds off the foundational Ref. [2] of the above post, suggests the opposite conclusion in the event, of course, of having well-calibrated data from a reputable laboratory and following the procedures of handling that data as described/prescribed in the paper (self-reference method, deviation in efficiency relative to STC, etc.). At the same time, of course, I'd appreciate a reply to my above post, thanks.
[1] PVsyst 7 _ Series resistance determination, https://www.youtube.com/watch?v=5MJo_9dqbBk/
-
I spoke to Tim Townsend who historically provided PVsyst with the recommended Uc and Uv values of 25 and 1.2 (which PVsyst attributes to PVUSA) derived during his time working at that same location in Davis, CA where PVUSA-related testing activities also took place. He confirmed to me that the height of the wind speed data used to derive those values via regression was 10 meters. (He said: “The pole was next to my office and plainly visible out the west windows of our building.”) I think this (the 10 meter height) is a critical piece of information to specify in the relevant section of the PVsyst Help Menu [1], so this is fundamentally my suggestion (to add this single bit of information to the help menu) and the reason for this PVsyst Forum post.
Note that since NSRDB PSM v3, that particular weather data set suddenly changed the wind speed height to 2 meters (PSM v2 and prior NSRDB data sets used the 10-meter height which is more standard aka traditional for TMY aka TGY files given that the particular ground surface coverage doesn't significantly impact the wind speed at that higher up height). Unfortunately, I can’t find any formal documentation of this change from 10 m to 2 m apart from this NSRDB webinar's Q&A [2] and a YouTube video (also in the Q&A of a NSRDB webinar) [3].
In such use cases (of 2-meter wind speed data), I don’t think the thermal parameters that were derived using 10-meter wind speed height would apply. I’m pointing this out because many PVsyst users are using {Uc=25, Uv=1.2} regardless of the weather data set in use (i.e., incl. NSRDB PSM v3), and my feeling is that's not correct. I suppose if the 2-m wind speed data was scaled to a 10-m height, that's one way to continue to apply those same thermal parameters historically provided to PVsyst by T. Townsend. I'm not aware of anyone who's doing this, though, and my understanding is this wind speed height translation is not happening internal to PVsyst (in the PVsyst algorithm) in such use cases of 2-m wind speed height data in the TMY aka TGY weather (meteorological) data set. Either way, the situation (state of affairs) needs to be clear to the PVsyst user which is why I'd like to see it stated in the PVsyst Help Menu that the values provided by T. Townsend are specific to a 10-m wind speed height (and then a description of any such wind speed height translations, e.g., to a standardized height of 10 meters if that's to occur within PVsyst OR the lack thereof of any such translations thus leaving it up to the user what to do with the wind speed height external to PVsyst, prior to importing the TMY aka TGY data, for the purpose of applying/pairing with a specific set of {Uc, Uv} within PVsyst).
-
Hello, I'd like to see VDE Americas' & Tim Townsend's Triple-C model incorporated into PVsyst. Upwards of 20% of the USA solar PV market is financed using CCC as the solution for accurate modeling of subhourly clipping. It's simple and straightforward to implement in PVsyst with several key advantages over the method PVsyst published at WCPEC-8 in Sept. 2022. Here's a recent, related LinkedIn post, and a new white paper is available upon request and will soon be posted (likely also on LinkedIn) after which I'll follow up and post it on this thread:
https://www.linkedin.com/feed/update/urn:li:activity:7087861833511960576/
The v1 model was initially published at PVPMC 2022:
https://pvpmc.sandia.gov/download/4415/
The model's now at a stable v5 with many more, high quality, ground-measured 1-min. datasets added to the mix.
-
P.S. (because the time that's granted for editing posts in this new PVsyst Forum is unfortunately still very limited, i.e., it very quickly expires following submission - roughly 1-min. only vs. the previous PVsyst Forum which nicely allowed edits to posts indefinitely):
I was just going add a quick note onto question #7 to say that trackers often follow a different tracker stow algorithm depending on whether the event relates to wind or hail.
-
PVsyst v7.4.0
Most of the below questions and feedback are compliments of T. Townsend (paraphrasing is mine):
1.) What's the assumed height of the wind speed? This is as important to know as the wind stow wind speed threshold.
2.) It it accounting for wind speed gusting? Or is it simply basing it on an hourly average wind speed? Namely, what duration of wind speed is used in the algorithm, and what duration is expected for the user input of wind stow wind speed (e.g., 3-sec gust or 1-hr avg)?
3.) Is it changing tilt to the user-inputted tracker stow position value (thus affecting, e.g., IAM losses) or is it assuming power is zero? Initial testing indicated the former, however, it's likely that such high wind events will be complemented (e.g., in the 8-24 hours following the event) by a utility outage. Certain gust events may cause spot power outages while higher gust events cause widespread outages.
4.) Initial testing indicated that a custom user input of wind stow wind speed (e.g., 6 m/s) changes by itself back to the original PVsyst-default value (12 m/s). If so, we assume this is a bug.
5.) In the hours with hourly (TMY aka TGY) wind speed exceeding 12 m/s, no impact of wind stow was observed. Maybe this relates to some of the questions above. Or it could be a bug. We're not sure.
6.) The help menu description of this new feature is quite limited hence several of our questions.
7.) Trackers commonly stow for both wind and hail. Do you have any plans to address tracker hail stow in PVsyst (so we don't have to include it in applicable cases via a post-processing algorithm external to PVsyst)?
-
Some PVsyst users want the option to specify an exact unavailability (aka availability loss) in Detailed Losses such that the same value is displayed in the PVsyst Loss Diagram. Thanks.
I'm running PVsyst v7.3.
Keywords: Availability, PVsyst Loss Diagram, PVsyst Loss Tree, PVsyst Sankey Diagram, Unavailability
-
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).
Sub Hourly Clipping Losses
in Simulations
Posted
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