Jump to content

dtarin

Members
  • Posts

    873
  • Joined

  • Last visited

Posts posted by dtarin

  1. Hi Amy,

    From the help section, it recommends shading objects should be considered as "far" if they are a distance away from the array which is equal to 10x the size of the array. How this is determined is not known to me. Personally, for urban areas, I have modeled the buildings in the shade scene as near shading objects. It would be interesting to see the comparison between Suneye data converted to a far horizon profile versus the near shading method.

    1183702801_farshading.thumb.jpg.6a228b5e9033e030d83ab591dd927d7c.jpg

  2. It's not clear to me what time shift is appropriate. I downloaded NSRDB data and did not select "convert UTC to local time". I then used the .MEF file which was posted by solarguru on 10/17/16 which included a shift of 5 hours. My site is located in UTC-5. I'm getting errors that "GlobHor" data is undefined, and also that my time seems mismatched. Does anyone know what the most appropriate way is to treat NSRDB data, specifically PSM v3?

     

    The result of the time shift is revealed after the conversion has happened. After complete, a box will come up asking for you to inspect the data, click yes, and select "check data quality" tab to see how far off you are, and if adjustment is needed.

    If your glob Hor is undefined, it might mean that depending on the variables you imported from NREL, it may not be matching up with the MEF file I provided. You will need to update the MEF to point to the correct columns. When I download PSMv3, I only download the variables I need for PVsyst (GlobHor, DiffHor, Tamb, Wspd) + DNI. When I download a UTC-5 site, and I check "convert to local time" when download NREL PSM, a time shift of 5 hours generally works. If you did not check convert UTC to local time, you may need to do something different. Since I haven't done it with that unchecked, I cant provide any help there.

    https://imgur.com/a/1mOXdl6

  3. Hello,

    It would be help if trees or other solid objects had a parameter which defined their opacity. Often we have trees which are not very dense but whose branches span a wide area in a complex way. Defining a tree object which covers the area, but has <100% opacity could help capture the fact that some light passes through the branches. If this were implemented, you could also feature seasonal opacity factors, where in winter time the opacity is lower, and in summer it is higher.

  4. Mismatch loss factor (default value is 10%)

    1) What does mismatch at back side of modules means and why this value is taken 10 % as default ?

    Thanks

     

    This value has been updated to a default if 5% (as of v 6.7.4 I think), as it was believed to have been overestimated @ 10%.

    I dont have any info on the shading loss factor, so can't help you there.

  5. It is stated in the patch notes for 6.7.5 that this was corrected.

     

    In version 6.7.5 (06.08.18) :

    !!! A license synchronization is required before the update of PVsyst !!!

    Improvements:

    String inverters: add. info, and warning when choosing "Use Multi-MPPT"

    Help about bi-facial: add a page explaining the results in detail

    Fixed errors:

    Projects involving Mixed orientation: errors in simulation

    (namely on IAM and near shading losses)

    CSV hourly files: error in the version 6.74: many values were null !

    Ageing tool: always reverts to 10 years when entering the dialog.

    Solar parameters tool (plots): some insignificant errors.

    Maxim optimizers: little error in simulation => Ohmic loss = 0.

  6. With the anticipation of increased use of bifacial modules in the future, it would be useful to be able to include hourly albedo data which is used in the calculations, perhaps imported with the meteo data when creating the MET file.
  7. You may need to reach out to the manufacturer for the derated value, whether it be a curve or tool they provide. I dont see anywhere in the software (OND file) which allows for elevation derate. You might then clip post-process anything higher than the derate value @ your elevation.
  8. Hello,

    I am interested in understanding two of the bifacial modeling inputs better: rear side shading, and rear-side mismatch. Have there been any updates as far as research or studies go which shed light on providing realistic values for these inputs? It seems the PVsyst default numbers are 5% for rear-side shading, and 10% for rear-side mismatch. How were these values arrived at?

    Thanks.

×
×
  • Create New...