Jump to content

kjs55

Members
  • Posts

    126
  • Joined

  • Last visited

Posts posted by kjs55

  1. As of PVsyst v6.84:

    Summary: When you open an existing project, save as new, and try to copy all variants, the variants are not copied into the new project

    Steps: 1.) Launch PVsyst v6.84, 2.) Project Design\Grid-Connected, 3.) Load _DEMO_Geneva.PRJ, 4.) Replace file name, 5.) Save, 6.) Click "Yes" when PVsyst prompts user: Copy all Variants?

    Result: The variants are not copied.

  2. As of PVsyst v6.84:

    1. My project uses imported measured weather data via: PVsyst\Tools\Measured data analysis. When I export the project ZIP file, I get several sequential error popup messages:

    """

    Conversion error of string

    "1005.076,6.012,8.885,9.95...6.5, 74, cont'd," => Real

    """

    2. It appears that the following important project files are not packaged in the ZIP bundle as expected:

    --SIT file

    --MEF file

    --DAF file

  3. PVsyst v6.83: I see a Hidden Parameter for "Maximum PnomRatio for inverter sizing" but not for "Minimum PnomRatio for inverter sizing". Is there a technical reason why the latter is missing? Is there some other way to set the latter using some other parameter(s) in PVsyst (hidden or not)?
  4. PVsyst v6.81

    1. Glass refractive index (n) appears to be 1.526, not 1.53 as shown in Hidden Parameters.

    2. It does not appear that n=1.37 for EVA (in Hidden Parameters) is used for "Normal glass" or "AR coating" scenarios.

    3. With the following assumptions, I get the same (tab-separated) results as PVsyst:

    --No ARC

    --Glass n=1.526

    --No refractive index applied for EVA

    AOI IAM_PVsyst IAM_kjs55

    0 1.000 1.000

    30 0.998 0.998

    50 0.981 0.981

    60 0.948 0.948

    70 0.862 0.862

    75 0.776 0.776

    80 0.636 0.636

    85 0.403 0.402

    90 0.000 0.000

    4. With the following assumptions, I get slightly different (tab-separated) results than PVsyst:

    --ARC n=1.29

    --Glass n=1.526

    --No refractive index applied for EVA

    AOI IAM_PVsyst IAM_kjs55

    0 1.000 1.000

    30 0.999 0.999

    50 0.987 0.987

    60 0.962 0.961

    70 0.892 0.889

    75 0.816 0.811

    80 0.681 0.674

    85 0.440 0.433

    90 0.000 0.000

  5. Measured data analysis in PVsyst v6.8.1: 1.) I am wondering why we need to make a set of MEF and MET files if we have already made a set of DAF and DAM files which contain the necessary weather data; the need for both sets seems redundant -- unless I am doing something wrong? 2.) It would be nice if you could open and explore the chosen measured data file using a file open button next to the "Measured data" dropdown menu within the "Measured data analysis" tool, similar to the ability to open and explore the MET file that has been chosen using the file open button to the right of the "Meteo File" dropdown menu on the same screen in the same tool. Part of the motivation for being able to open the "Measured data" file that has been selected from the dropdown menu is that the dropdown menu truncates the filename; if the filename is long, it is useful to have the ability to confirm that the right file is selected. Another option is to avoid the truncation of the filenames, perhaps by prioritizing the display of the filenames over other fields. Thanks.
  6. PVsyst v6.8.0: PVsyst does not ask the user whether measured POA irradiance is from a reference cell or silicon photodiode or thermopile pyranometer. So how does PVsyst take into account the different incidence angle response of flat- vs. dome-shaped glass (e.g., in reverse/forward transposition calculations)?
  7. There is a >0.25% difference in GHI when importing the same GPI data set between PVsyst versions 6.7.8 and 6.7.9. The release notes do not mention any changes to the (Hay) reverse transposition algorithm. The impact on annual energy can be >0.5%. Any ideas of what is behind this change? (NB: PVsyst refers to reverse transposition as "retro-transposition" or "inverse transposition".)
  8. As of PVsyst 6.7.8: This applies to both fixed tilt and tracking (grid-connected projects). I set nb. sheds = 1. I would not think collector pitch and width matter in this case but perhaps they do b/c of built-in unlimited sheds modeling assumptions? When I vary pitch from 6.6 m to a large value like 100000 m, the energy of the system goes from roughly 4700 to 14000 kWh/year. For a given pitch (nb. sheds = 1), varying width changes energy. Also, you need to close and reopen the project in order for changes to nb. sheds, pitch, or width to take effect. I will update this post later w/ more information and examples when I have time.
  9. The problem started with V6.31.

    Here is what I did:

    Opened existing PAN file in PVsyst. The PAN file has a custom IAM profile.

    Copy values to table.

    Paste values into Excel and delimit based on semicolon.

    Copy spreadsheet row without changing anything.

    Open new PAN file.

    Paste values from table.

    Error occurs in PVsyst and PVsyst crashes.

    Some observations:

    Custom IAM table is completely blank and all the angle and IAM values are "0.00".

    Therefore, I believe the problem occurs with the custom IAM profile.

    I ran it without defining an IAM profile and it seems to work without crashing.

  10. When importing a row from the PVsyst Excel PAN file database to generate a PAN file, if the field for the quadratic factor BRev is left empty, the value of BRev in the PAN file will result in 3.2 mA/V^2 regardless of the module's Isc.

    I do not know what this value of 3.2 represents, but I believe it should be using the default BRev parameter that is specified in the Hidden Parameters for PV Modules, as follows:

    Quadratic factor BRev [mA/V^2] = 1.2 * Isc,

    where 1.2 is the default BRev parameter listed in units of [mA/V^2]/Isc in the Hidden Parameters for PV Modules.

    Thus, if BRev is left empty in the Excel spreadsheet for a module that has an Isc of 8.986 A, I believe the value of BRev in the PAN file should be 1.2 * 8.986 = 10.7832 mA/V^2 after importing, not 3.2 mA/V^2.

  11. I am reporting a Pmpp temperature coefficient problem with PVsyst.

    In V6.26 and later, PVsyst changed the way that the temperature dependence of PV modules is being modeled.

    The brief release notes state that the derivative at 45 C is now taken into account in addition to the derivative at 25 C.

    PAN files in the V6 database will lead to different results depending on which version of PVsyst V6 is being run. Namely, the same PAN file used in V6.25 and earlier versions will lead to different results compared to if it is used in V6.26 and later versions of PVsyst.

    Also, any PAN file in the database with optimized parameters for fitting the temperature dependence in V6.25 and earlier versions may no longer be optimized for V6.26 and later versions. Likewise, any PAN file that is optimized for V6.26 and later versions may not be optimized for V6.25 and earlier versions. As an example, in PVsyst V6.25 or earlier versions, a temperature coefficient of -0.42 %/C may have been chosen as the input for µPmpp to yield an effective temperature coefficient of -0.43 %/C over the full range of temperature values (e.g., 25-65 C). As of PVsyst V6.26 and later, the inputted temperature coefficient of -0.42 %/C may yield an effective temperature coefficient of -0.42 %/C over this same temperature range.

    To demonstrate all of this, I simulated the exact same project in Versions 6.25 and 6.26 (500 kW in Phoenix, Arizona with a 310 W multi-Si module type). The results are as follows:

    PVsyst V6.25

    961.64 MWh/yr

    PV loss due to temperature: -10.0%

    PVsyst V6.26

    963.74 MWh/yr

    PV loss due to temperature: -9.8%

    Is it acceptable for module manufacturers to manage this bug by providing two sets of optimized .PAN files for V6; namely, PAN files that are optimized for V6.25 and earlier versions and PAN files for V6.26 and later versions?

  12. I am currently running PVsyst Version 6.26.

    In order to generate a custom PVsyst .PAN file, electrical performance (I-V curve) measurement data are collected at various temperature and irradiance conditions and used to optimize the PVsyst one-diode model parameters Rs, Rsh, Rsh0, RshExp, and mugamma. I would like to have the option to directly enter the value of mugamma that is solved for instead of having to determine the temperature coefficient of Pmax (truncated to two decimal places) that yields closest modeled temperature dependence to the fitted value of mugamma.

    A less desirable option is to extend the allowable number of decimals places of the temperature coefficient of Pmax (gPmp) to beyond two. However, again this requires the user to have to find the correct value of gPmp to input (now up to three or more decimal places) that results in the best match to the fitted value of mugamma. This is already a tedious process for two decimal places and it would be much easier if the user could directly input the fitted value of mugamma per the above paragraph.

  13. I noticed some problems with the truncation of critical diode model parameters (this list may be non-exhaustive):

    - Vmp and Voc are truncated to 1 decimal in .xls file (limit is 2 decimals in .PAN file)

    - Imp and Isc are truncated to 2 decimals in .xls file (limit is 3 decimals in .PAN file)

    - Rs is truncated to 2 decimals in .xls file (limit is 3 decimals in .PAN file)

  14. Issues with user defined IAM profile in PVsyst V6.22

    Trial #1

    Run a .PAN file that has a custom IAM profile

    Go to detailed system losses

    Deselect "uses definition of the PV module"

    Select "user defined profile"

    The user defined profile edit text box fields are not accessible for modification (they are "grayed out")

    Trial #2

    Run a .PAN file that does not have a custom IAM profile

    Go to detailed system losses

    Select "user defined profile"

    The user defined profile edit text box fields are not accessible for modification (they are "grayed out")

  15. During system downtime due to "unavailability in the system" (new loss in PVsyst V6), the external transformer losses remain proportional to the square of the current even though the system is not operating and no current is flowing (open-circuit). I think the external transformer losses should be constant (not irradiance-dependent) when the system is not operating.

    I think this indicates that there is a bug (e.g. the transformer loss is calculated and applied before taking into account the system is down).

  16. Operating PVsyst V6.12

    It is uncertain whether the negative energy values correlate with the randomized dates / times when the systems is not operational.

    It appears that summing the 8760 hourly energy values (both positive and negative) in Excel yields the same annual value as what is reflected in the PVsyst output report.

    I would have expected energy production to be zero during the times when the system is not operating (not negative).

    Please advise as to whether this is a bug or not.

×
×
  • Create New...