Jump to content

Fredy

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by Fredy

  1. Good afternoon

    I’ve updated PVsyst to v6.70 but this error is still there.

    I've noticed why PVsysts always assumes Pitch (Sheds spacing in 6.7) 5m in the report when you import a layout from Helios3d.

    When you go to construction perspective and open a single table that you imported from helios3d the default values for pitch is 5m.

    But this is wrong in the full layout we have different pitch so is there any way to remove this option from the report or fix it?

     

    Pitch2.jpg.6b367fd1f4fafc688fc6c6b3fdfab84b.jpg

     

    Thank you for your support

  2. Good Morning

    I’m using the New Version of PVsyst 6.68 and when I do "Construction / Perspective" I usually import from Helios3D

    i have an Pitch on the Layout but in report it always show 5m (I’ve tested in different layouts with different distances its always 5m on report)

    Is there any way to remove this option from the report like in the previews versions?

     

    975720686_PitchNearshading.png.25c4d126ecebc2139cee8da7443c7134.png

     

    1806818440_Pitchrepport.png.8e69f22009dfd5c049ad9e0c98660936.png

  3. Good afternoon

    Im revewing an old simulation and with the exact same IAM profile i get diferent losses in the end

    (this profile is imported from .PAN file, in the V6.67 i had to copy the values)

    is there any explanation for this or is it an error??

    1251544709_IAMprofile.jpg.e294c82c654c2ba7a8579fd7480cacce.jpg

    IAM profile

    1068082192_IAMLossPVsyst6_65.jpg.bb0dc60323f62f4c141505ec8121f0e6.jpg

    6.65

    1992939808_IAMLossPVsyst6_67.jpg.6f352cee617471ed4090de55613e5207.jpg

    6.67

     

    thank you for your support

    Best reggards

  4. Hello

    I need to set smaller time intervals to measure the angle of a tracker

    In this simulation our tracker is a tilted axis tracker with:

    Axis tilt: 0

    Axis Azimuth: 0

    Phi min.: -45

    Phi min.: +45

    I see in near Shading the "Shadow animation" gives us sun azimuth and sun height each 15min

    Tracker.jpg.e18f6c6616d7f865e8cf73bec2e8ffbc.jpg

     

    Can we Export a table with the following data:

    Time: 00:00 ; 00:15 ; 00:30 etc... 23:45

    Sun azimuth

    Sun height

    Phi angle (-45 : +45)

    Thank you for your support

  5. Good afternoon

    I'm comparing 3 different Meteo databases and in this 3 simulations i used all parameters losses modules inverters are the same just changed the Meteo,

    I get the following results:

     

    1775645496_Meteocompare.thumb.png.09dc1e25ce99c2d72c83dd9bc3fb5bd5.png

     

    I don’t understand why Meteonorm VS PVgis have almost the same Global Radiation and the PR changes so much (81.6 - 82.2)?

    and Meteonorm VS Meteosat have the same difference on PR (81.6 - 82.2), with lower radiation and higher GlobINC i have more gain in (Hor / Inc) that i understand

    Is there some other parameter that affects this when using different Meteo files?

    Thank you for your support

  6. Hello

    I had to come back at this Post because,

    We are trying to find out how the azimute was calculated when we have multiple orientations and we had to use higher "Discriminating orient. difference between shading planes", we did several tests

    the azimuth it show's on the image bellow:

    Azimute.png.35dde87fe2ea83af7bc786675a8dc69f.png

     

    Is the azimut of the "Main Table" the one that we creat first or in cause of Helios 3D it alwas show the same azimuth in "constraction prespective" im assuming it is average? or is it the azimute of the "main table"?

    Construction.thumb.png.939dd61e70e8a68bee96e805209a4fac.png

     

    We are now doing a project with very hight slopes

    what's the best since PVsyst "during the simulation, the incident irradiance will be calculated once for the average orientation, and applied to all tables in the same way, resulting in a (little) orientation loss."

    We wanted to know how should we treat this case?

    Should we add some losses to consider this "orientation loss."?

  7. Hello

    I'm trying to do a few simulations with the Design on Helios3D with multiple tilts (Multiple helios3D files) then i combine the CSV files in order to see the production / PRs for the PV plant with the tilts corresponding to the days i find better.

    When using daily values we get some PR's that doesn’t make sense and when i do the average PR I get lower PR with this multiple tilts but better production

    On the CSV with the multiple tilts I’m excluding Values under 10% of the maximum value for each month and it gives me something near the average PR of the 3 Tilts configuration

    But I don’t know if it makes sense either the PR should be +/- constant because if we have low irradiation the production should fall down as well making the PR +/- the same as a high Irradiation day?

    At least when we measure with our pyrometers the PR goes +/- constant with low deviations between max and min and without that low values that shows on the image bellow

    Do you have any idea how to make this seem right?

    This image is just an example of the PRs from 1 month

     

    1866080862_PRjan.png.723f062811ff2e4dd94f554535564b39.png

     

    Thank you for your support

  8. Thank you for your help,

    Ok so PVsyst considers some days covered cloudy?

    Normally I see monthly values when importing from external Meteo data

    This hourly tables are interpolated by PVsyst when we do the synthetic hourly data generation?

    It is a probability calculation?

    Sometimes 0 for beam irradiance and sometimes x% for Beam irradiance?

    Where can I find this?

    Thank you for your support in advance

  9. Hello I’m sorry for the spam

    I found that for Horizontal Beam there are some values missing or low values a lot actually,

    Maybe this could be the reason why I’m getting this

    For this test I’m using another Meteo file from PVGIS On the first Post I was getting BeamHor = 0 in every cell for 21-December, but now even with this one from PVGIS there are some missing values.

    In the images bellow the red/green cells corresponds to the acceptable / unacceptable values for BeamHor

    Blue Cells were calculated: (ShdLoss / GlobInc.) to have a perception of the loss %

    In this table we can see that there are some missing values and low values that doesn't make sense more losses at the mid of the day then at morning

    183340386_BeamHor-2.png.f318c8c8f9959b5df1422cd5f4f24077.png

    I found this one acceptable at least make more sense than the other two

    700246461_BeamHor.png.a1dc7bc8545b42be43c3be3efc6a45bc.png

    This one seems good too more losses at morning/afternoon and less on mid-day

    88554733_BeamHor2.png.b34325cfc8e3f3cd54b083c3cb5513a5.png

     

    It was harder to find correct values then wrong / missing values.

    1- Could you see if this is a bug from the program it fails to generate some values or something?

    2- The program calculates the shadows for every hour with the corresponding shading factor but it needs the beam Irradiation right?

    Thank you in advance for your support

  10. I was analysing the output file tables and for what i understand PVsyst is taking the shading loss constant for all the hours

     

    441960310_SHDLoss.thumb.png.fa0cdf65dfd99f6bec3b47f3d2be4cab.png

     

    So PVsyst just uses the Near shading Table and shading factors to calculate 1 final Shading loss that is used constant in every hour?

    Shouldn't it use the shading factores that it calculates in the near shading table to get the values for GlobEff / EARRay etc... correctly for every hour?

  11. Hello

    We are having a problem with the production in a plant that is already working, we are having half the production that PVsyst gave us

    I found this values referent to shadings in the output file:

    21-dez.thumb.png.44313aac942dffb638e1859e83ee706d.png

     

    the Near shading Animation corresponding to this table is the image bellow (it’s just an part of the plant + shading factors and graph):

    parque.png.4b06d90f7de66c546313bf7647ba3700.png

     

    So could you clarify the meaning of this values on the output file?

    -Global correction for shading: Irradiation reaching the modules counting with the shadings?? If it is correct shouldn't it be lower for example at 9:00h globInc=19.277 GlobShd=18.504 it is just 0.77w/m2 difference and on the near shading animation I see almost all the plant shaded at 21-12 _ 9:15h

    -Near Shading loss (w/m2): I don’t understand this one. Is it the quantity of irradiance loss due to shading? Why I have more losses at 12:00h than at 9:00h?

    -Near shading factor on global: Globshd / GlobInc OK. This should be the % of irradiance loss due to shading but because of the previews parameters we are having more losses at 12:00 than at 9:00...

    Is PVsyst taking this shading losses correctly it seems

    Is there any other parameter i can use to see the shading loss % ?

    Thanks in advance for your help

  12. Hello

    In a PV simulation should we consider using the Light Soaking effect of the CIS modules?

    It increases the PR a lot and I don’t know if this effect takes place for a long period of time or just for 1 year or a shorter time?

    The module im using is Solibro 125Wp witch has +2.5% Light Soaking effect

    With this increase of performance this modules takes advantage by all the other modules,

    I'm a bit afraid of giving this hight values to our clients (86%PR in France lat:44.4°N), should I simulate with or without light soaking effect?

    Thank you for your support.

  13. Dear André

    I'm using all that options:

    Near Shading Calculation mode -> Fast (table)

    Not using "Module Layout"

    On 3d editor i have that option checked "Tools" / "Optimized calculation"

    My system is about 896 objects tables (on 3d model), and 8 central inverters.

    it takes almost the same time as the Near shading table.

    This is stressfull when you have to do several simulations where you change one loss or one other parameter you have to wait all that time again.

    do you know what can be causing this?

    Best regards

  14. Any news regarding this problem?

    I've updated to 6.30 and on this part like "Denizurla" referred:

    1610517064_Hourlysimulationprogress.jpg.608f5257db4debda92faa5316773dbf7.jpg

    The simulation it’s too slow it takes like the same time as the Near shading table calculation, or more..

    Is it normal to take all that time?

    Previously it was like “instant” in PVsyst5 let’s say 1 minute in the worst cases.

    Why does it takes hours now?

  15. yes i forgot to mention that i use 100% fraction for electrical effect.

    and as you told me:

    If you use 100% for this factor, then your comment is right, it would not be necessary to calculate the linear shadings, since you loose all the string production.

     

    so this would be an additional loss that is already included in "Shading: Electrical loss acc. to strings"

    Is there any away to remove the linear for simulations with 100% electrical effect?

    because if we have 2 shading losses its like we have 2 shades on the top of each other.

  16. Hello

    I’m sorry for the question:

    But is it normal to have both losses on the simulations?

    -Near Shading Irradiance loss (= Linear shading) +

    -Shading: Electrical loss acc. to strings

    Shouldn't we have just 1 loss "Shading: Electrical loss acc. to strings", as it englobes the linear + the string that belongs to the shaded module?

     

    497711176_Shadingelectricaleffect.png.ea655b3eea40c644094721501e562e38.png

     

    Is it normal to have less production/PR with simulation according to module strings?

    Of course the yellow area on the image above is bigger than the gray area.

    - What I don’t understand is the linear shading is like a proportion of the shading area VS active area.

    This should be like just the geometrical part of the shading?

    - And the electrical effect should be when 1 module is shaded the whole string is inactive. But shouldn't that electrical effect be the only shading loss on the report?

    It’s like we are adding 1 loss instead of changing the calculation method to the “according to the module string”.

    It calculates geometrical + electrical?

    Tell me if im wrong! Maybe I’m misunderstanding something?

    How is this calculated?

    Thanks in advance

    Best regards

  17. Hello

    I have to make an simulation with PVsyst 6 near Dubai latitude 24°

    and when i import the plant from Helios to the near shading Construction / Prespective the tables are facing North when they should be facing south 243860425_H2PimportPVsyst6.thumb.png.2a59a02b3d379a36bb9195855748f960.png

     

    and it asks me for an tilt angle of 160º 390954070_TiltPVsyst6.png.93d2f33895ca9c02dc631edbf25433d5.png

     

    If i use the same file on PVsyst 5 it gives me the correct tilt angle 20º south1849639339_H2PimportPVsyst5.thumb.png.68e90e82ddef103c94113d11dbae3090.png

     

    I checked everything on helios is correct and it is ok in PVsyst 5

    Is anything i have to take in to account in PVsyst 6?

    Can this be fixed?

    Thank you for your support

  18. Hello

    In PVsyst 5 we could control the "Shading max. orientation difference between shading plans" on the hidden parameters so you could simulate even if the difference was too big (bad terrain)

    Now in PVsyst 6 I can’t find an parameter where I can define the nº of orientations (see image attached)

     

    204711711_morethan8orientations.jpg.1be84772c8f00fe9916ffbd1d9f4c6d3.jpg

     

    Is there any parameter to define this limitation?

    So PVsyst could make an “average” of the orientations?

    Thank you for your support.

×
×
  • Create New...