Problems with Solar and/or Climate object

2013-02-28
2013-03-16
  • Mark Chatters

    Mark Chatters - 2013-02-28

    Hi,

    First time post - I am working in Australia and I am trying to get the configuration of the Solar panel correct.

    I am having a few problems - and I am wondering if they are code bugs (for example Gridlab-d not correctly handling lat/longs south of the equator), or just the way I've set things up.

    A bit of background - to make sure I've set everything up correctly, I have built a test glm file with a series of solar panels with different tilt angles and orientation_azimuths. I have also created a climate csv file with constant direct solar radiation - the location is set for Melbourne Australia. I have included the relevant bits and pieces at the end of this post

    Problem 1 - Tilt Angle not working as expected

    When I compare the output of 2 panels:

    1st Panel - Azimuth 0 degrees tilt angle 0 degrees (i.e. flat)
    2nd Panel - Azimuth 0 degrees tilt angle 10 degrees

    The 1st Panel generates more energy - that's not what I am expecting for a panel south of the equator. By tilting the panel, I am tilting the panel north, toward the sun (unless I have got this wrong) and so it should produce more energy (as we are south of equator). Is this a bug - or have I made a mistake ?

    Problem 2 - Peak Solar Output 1 hour out - Daylight Saving ?

    I use my constant solar climate csv file to check the panels produce maximum output at Solar noon in Melbourne. For Daylight savings, the results appear to be an hour out.

    Example - here is an extract of the recorder output on my Azimuth 0 tilt angle 0 panel for 1st Jan 2010 (a summer's day down here - with daylight saving)

    # file...... output\METER_A0_T0_recorder.csv
    # date...... Thu Feb 28 02:51:48 2013
    # user...... t53987
    # host...... (null)
    # target.... meter 13
    # trigger... (none)
    # interval.. 600
    # limit..... 1000000
    # timestamp,measured_real_power
    ...
    2010-01-01 10:10:00 AEDT,-606.658
    2010-01-01 10:20:00 AEDT,-618.601
    2010-01-01 10:30:00 AEDT,-629.696
    2010-01-01 10:40:00 AEDT,-639.922
    2010-01-01 10:50:00 AEDT,-649.261
    2010-01-01 11:00:00 AEDT,-657.696
    2010-01-01 11:10:00 AEDT,-665.21
    2010-01-01 11:20:00 AEDT,-671.791
    2010-01-01 11:30:00 AEDT,-677.426
    2010-01-01 11:40:00 AEDT,-682.104
    2010-01-01 11:50:00 AEDT,-685.818
    2010-01-01 12:00:00 AEDT,-688.561
    2010-01-01 12:10:00 AEDT,-690.327
    2010-01-01 12:20:00 AEDT,-691.113
    2010-01-01 12:30:00 AEDT,-690.918
    2010-01-01 12:40:00 AEDT,-689.743
    2010-01-01 12:50:00 AEDT,-687.588
    2010-01-01 13:00:00 AEDT,-684.459
    2010-01-01 13:10:00 AEDT,-680.361
    2010-01-01 13:20:00 AEDT,-675.301
    2010-01-01 13:30:00 AEDT,-669.289
    2010-01-01 13:40:00 AEDT,-662.336
    2010-01-01 13:50:00 AEDT,-654.454
    ...
    

    The recorder shows peak solar output at around 12:20:00 AEDT (Australian Eastern Daylight saving Time).
    The expected result (I go to http://www.timeanddate.com/worldclock and look at Sunrise and sunset in Melbourne) is 13:23 AEDT (so 13:20 should produce the highest value).

    When I repeat the test for a day in late April (when daylight saving has finished), the peak solar output is at the correct time.

    Is this a bug - or have I got my configuration wrong ?

    Thanks in advance

    glm and configuration files

    main glm file (extract - it's quite large)

    clock
    {
        timezone AEST-10AEDT;           //Local timezone for the simulation
        starttime '2010-01-01 00:00:00';    //Start time in the local timezone 
        stoptime '2010-04-30 00:00:00';     //Stop time in the local timezone
    }
    module powerflow
    {
        nominal_frequency 50;
    }
    module tape;
    module Generators;
    //Include the climate data
    #include "MelbClimate.glm"
    //Include market data
    #include "MarketCustomerSched.glm"
    ...
    //Azimuth Zero, Tilt Angle Zero
    object meter {
        name METER_A0_T0;
        phases ABCN;
        nominal_voltage 240 V;
        bustype PQ;
        bill_day 1;
        bill_mode HOURLY;
        power_market MARKET_EA025;
    };
    object recorder {
        name METER_A0_T0_recorder;
        parent METER_A0_T0;
        property measured_real_power;
        interval 600;
        limit 1000000;
        file output\METER_A0_T0_recorder.csv;
    }
    object inverter {
            // Inverter/Solar -
            name INVERTER_A0_T0;
            parent METER_A0_T0;
            phases CN;
            generator_mode CONSTANT_PF;
            generator_status ONLINE;
            inverter_type FOUR_QUADRANT;
            four_quadrant_control_mode CONSTANT_PF;
            power_factor 0.9;
            rated_power 1000000;
            inverter_efficiency 0.9;
            };
    object solar {
            name SOLAR_PANEL_A0_T0;
            parent INVERTER_A0_T0;
            phases CN;
            generator_status ONLINE;
            weather SolarClimate;
            panel_type SINGLE_CRYSTAL_SILICON;
            generator_mode CONSTANT_PF;
            area 6.1 m^2; //about 1kW
            tilt_angle 0;
            efficiency 0.15;
            orientation_azimuth 0; 
            orientation  FIXED_AXIS;
            };
    ...
    //Azimuth Zero, Tilt Angle 10
    object meter {
        name METER_A0_T10;
        phases ABCN;
        nominal_voltage 240 V;
        bustype PQ;
        bill_day 1;
        bill_mode HOURLY;
        power_market MARKET_EA025;
    };
    object recorder {
        name METER_A0_T10_recorder;
        parent METER_A0_T10;
        property measured_real_power;
        interval 600;
        limit 1000000;
        file output\METER_A0_T10_recorder.csv;
    }
    object inverter {
            // Inverter/Solar -
            name INVERTER_A0_T10;
            parent METER_A0_T10;
            phases CN;
            generator_mode CONSTANT_PF;
            generator_status ONLINE;
            inverter_type FOUR_QUADRANT;
            four_quadrant_control_mode CONSTANT_PF;
            power_factor 0.9;
            rated_power 1000000;
            inverter_efficiency 0.9;
            };
    object solar {
            name SOLAR_PANEL_A0_T10;
            parent INVERTER_A0_T10;
            phases CN;
            generator_status ONLINE;
            weather SolarClimate;
            panel_type SINGLE_CRYSTAL_SILICON;
            generator_mode CONSTANT_PF;
            area 6.1 m^2; //about 1kW
            tilt_angle 10;
            efficiency 0.15;
            orientation_azimuth 0; 
            orientation  FIXED_AXIS;
            };
    

    climate gml file

    module climate;
    class climate {
        double elevation[m];
        double tzoffset[h];
    }
    object csv_reader{
        name CsvReader;
        filename "TestSolar.csv";
    }
    object climate {
        name "SolarClimate";
        tmyfile "TestSolar.csv";
        reader CsvReader;
        tzoffset 10;
        elevation 9;
    }
    

    tzinfo.txt

    ; $Id: tzinfo.txt 683 2008-06-18 20:16:29Z d3g637 $
    ; Copyright (C) Battelle Memorial Institute, 2007
    ; This file is distributed under the same terms as GridLAB-D
    ; 
    ; Entries in this file follow the Posix standard for TZ
    ; The years specify which TZ rules go into effect that year
    ;
    ; IMPORTANT NOTE: year sections must be in chronological order
    ;
    UTC0 ; Coordinated Universal Time ~ never uss DST
    GMT0 ; Grenich Mean Time, no DST
    EST5 ; Eastern no DST
    CST6 ; Central no DST
    MST7 ; Mountain no DST
    PST8 ; Pacific no DST
    HST10 ; Hawaii no DST
    AEST-10 ; Australian Eastern Standard Time, no DST
    [1970] ; Rules as of 1967
    GMT0GMT,M3.5.0/02:00,M10.5.0/2:00 ; GMT, DST last Sun/Mar to last Sun/Oct
    EST+5EDT,M4.5.0/02:00,M10.5.0/02:00 ; Eastern, DST last Sun/Apr to last Sun/Oct
    CST+6CDT,M4.5.0/02:00,M10.5.0/02:00 ; Central, DST last Sun/Apr to last Sun/Oct
    MST+7MDT,M4.5.0/02:00,M10.5.0/02:00 ; Mountain, DST last Sun/Apr to last Sun/Oct
    PST+8PDT,M4.5.0/02:00,M10.5.0/02:00 ; Pacific, DST last Sun/Apr to last Sun/Oct
    [1986] ; Rules as of 1986
    EST+5EDT,M4.1.0/02:00,M10.5.0/02:00 ; Eastern, DST first Sun/Apr to last Sun/Oct
    CST+6CDT,M4.1.0/02:00,M10.5.0/02:00 ; Central, DST first Sun/Apr to last Sun/Oct
    MST+7MDT,M4.1.0/02:00,M10.5.0/02:00 ; Mountain, DST first Sun/Apr to last Sun/Oct
    PST+8PDT,M4.1.0/02:00,M10.5.0/02:00 ; Pacific, DST first Sun/Apr to last Sun/Oct
    [2007] ; Rules as of 2007
    EST+5EDT,M3.2.0/02:00,M11.1.0/02:00 ; Eastern, DST second Sun/Mar to first Sun/Nov
    CST+6CDT,M3.2.0/02:00,M11.1.0/02:00 ; Central, DST second Sun/Mar to first Sun/Nov
    MST+7MDT,M3.2.0/02:00,M11.1.0/02:00 ; Mountain, DST second Sun/Mar to first Sun/Nov
    PST+8PDT,M3.2.0/02:00,M11.1.0/02:00 ; Pacific, DST second Sun/Mar to first Sun/Nov
    [2008]
    AEST-10AEDT,M10.1.0/03:00,M4.1.0/02:00:00 ; Aus Easter, DST first Sun/Oct to first Sun/Apr start @ 2AM end @ 3AM
    

    Example of TestSolar.csv

    #Test Melbourne solar (NB Long and timezone is west of meridian),,,,,
    $state_name=VIC,,,,,
    $city_name=Melbourne,,,,,
    $lat_deg=-37,,,,,
    $lat_min=47.38068,,,,,
    $long_deg=215,,,,,
    $long_min=0.0,,,,,
    $timezone_offset=14,,,,,
    temperature,humidity,wind_speed,solar_dir,solar_diff,
    2010-01-01 00:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 00:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 00:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 00:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 00:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 00:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 01:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 02:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 03:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 04:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:40:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 05:50:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 06:00:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 06:10:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 06:20:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 06:30:00 AEDT,67.1,0.92,16.156,100,0
    2010-01-01 06:40:00 AEDT,67.1,0.92,16.156,100,0
    
     
  • Frank Tuffner

    Frank Tuffner - 2013-03-01

    Hello mchatters,
      To my knowledge, the solar code should work fine for southern latitudes, but it is certainly possible there's a code bug.  It was thoroughly tested against northern latitude (US-specific) areas, but only marginally for southern latitudes.  I'm going to look into this right now, but wanted to give you a quick response.  A quick glance at the GLM excerpts you posted looks correct, so I don't think it is anything on your end.
     
    For problem 1, your assumption sounds correct.  An azimuth of 0-degrees should be north facing, so if you tilt it a little bit, you should get a higher solar output (unless you were right on the equator, but I don't think you're running it that way).

    For problem 2, it's possible we have an issue with how the hours shift for daylight savings.  I'll look into it while I'm checking the above.

    -Frank

     
  • Mark Chatters

    Mark Chatters - 2013-03-03

    Hi Frank

    Thank you - I've got a couple of related questions on the climate object

    In the Gridlab climate guide

    http://sourceforge.net/apps/mediawiki/gridlab-d/index.php?title=Climate_Guide

    It says:
    Humidity is a percentage - default 0.75 - so if we want 75% humidity, we enter 0.75 in the climate file ?
    and
    Windspeed - the description is a bit confusing - assuming it is windspeed - what are the units ? (metres/sec?)

    Thanks

    -Mark

     
  • Kelvin Proctor

    Kelvin Proctor - 2013-03-03

    Hi Frank,

    It seems there might be a little inconsistency in the units for humidity, as in is the value in the range 0.0-1.0 or 0.0-100.0.

    In climate::climate the humidity variable is initialized to 0.75.

    In \residential\init.cpp the value of default_humidity is initialized to 75.0.

    I'm not sure which is 'correct' but it seems a little inconsistent.

    As part of Mark's original question he has shown how we are using the timezone in the simulations.  I'd be very interested to see if you think we are using this correctly, particularly with regard to the timestamps that are included in the climate CSV file.  At the moment we have both normal and daylight savings time specified in that file (with the appropriate suffix) to cover a full year.  I'm not sure if that works correctly or how it interacts with other calculations of solar angles etc…..

    Regards,

    Kelvin
    Ausgrid

     
  • David P. Chassin

    The units are fine in both (%) and 75 is appropriate as the default in residential. The default in climate is not good but should never be used anyway because it would only come up if the climate data didn't load. Should be fixed though.

     
  • Frank Tuffner

    Frank Tuffner - 2013-03-04

    Hello Mark and Kelvin,
      As Dave pointed out, the 0.75 inside climate is a typo (it basically defaults to 0.75% then, not 75%).  As Dave indicated though, this should only come up when no humidity value is specified.
     
    In terms of the climate and timezone utilization, as far as I can tell, what you have is correct.  That being said, we've encountered some inconsistencies inside GridLAB-D we are trying to resolve.  Most of the solar routines were written assuming a TMY2 input, while you are using the CSV reader.  Theoretically, they should be the same, but there are some sign inconsistencies that need to be resolved (in terms of DST formats, W/E sign conventions, and things like that).  We're hoping to have those resolved later today or tomorrow, so I'll post back here once that is complete.

    -Frank

     
  • Frank Tuffner

    Frank Tuffner - 2013-03-06

    Hello again Mark,
      We've finished making some bug fixes to the 2.3 RC1 (or maybe it is RC2 now) source code to fix some of the issues you pointed out (committed as part of r3872 and r3873).  We had some disparity between how things were being handled between the TMY reader and CSV reader.  Those should be fixed now.  In the harmonized implementation, southern latitudes are negative and western longitudes are negative.  As such, I believe the header of your CSV file needs to be modified slightly to be:

    #Test Melbourne solar (NB Long and timezone is west of meridian),,,,,
    $state_name=VIC,,,,,
    $city_name=Melbourne,,,,,
    $lat_deg=-37,,,,,
    $lat_min=47.38068,,,,,
    $long_deg=144,,,,,
    $long_min=57.0,,,,,
    $timezone_offset=10,,,,,
    

    The main change is the timezone_offset and longitude (the actual values are slightly different too, I put minute values from Wikipedia for Melbourne, Victoria in to test it).  It looked like you were using a "wrap around westward" approach with both values before.  They should now be properly encoded for eastern hemisphere progression (despite being backwards to what the tz_info.txt has in it, but that is something that is beyond the scope of this problem - what you have is correct there, it just is opposite of this convention).

    I also don't believe you need the elevation and tzoffset parameters declared explicitly anymore, unless you are using them for informational purposes.  The time zone offset is properly handled internally now and I'm not sure the elevation is ever used anywhere.  With the CSV changes above, the "MelbClimate.glm" should work with just:

    module climate;
    object csv_reader{
        name CsvReader;
        filename "TestSolar.csv";
    }
    object climate {
        name "SolarClimate";
        tmyfile "TestSolar.csv";
        reader CsvReader;
    }
    

    As an aside, I've also included solar variables to align better with the climate objects (solar_diffuse and solar_direct) for CSV files.  The solar_dir and solar_diff values still work, but now you can use consistent variables from the climate objects (this was a pet-peeve of mine, so I fixed it while I was in there).

    In regards to the changes, there is also a quick caveat I'd like to post here for both the AusGrid folks and anyone else utilizing these code pieces in the southern hemispheres.  The default solar position model in GridLAB-D isn't the best suited for southern hemisphere operations, mainly due to some assumptions in the base algorithms.  Houses utilize this model and the photovoltaic arrays utilize it as the default.  This causes the 0-degree and 10-degree tilt solar model differences mentioned above.  This solar model is also utilized in the solar insolation values influencing the house models, so they will have similar discrepancies.  This is oversight is something we're discussing addressing in the next version.  The values are fairly close, but could show some differences with any specific measured data you have accessible.

    However, in regards to the solar arrays, there is an alternative solar position model available.  If the parameter SOLAR_TILT_MODEL SOLPOS; is used in the solar array, southern hemisphere operations are supported properly.  This solar position model is more robust and an overall more accurate model, especially for photovoltaic usage (it incorporates better position calculations and the Perez tilt model for diffuse solar contributions).  I'd recommend adjusting your solar objects to be similar to

    object solar {
            name SOLAR_PANEL_A0_T0;
            parent INVERTER_A0_T0;
            phases CN;
            generator_status ONLINE;
            weather SolarClimate;
            panel_type SINGLE_CRYSTAL_SILICON;
            generator_mode CONSTANT_PF;
            area 6.1 m^2; //about 1kW
            tilt_angle 0;
            efficiency 0.15;
            orientation_azimuth 0; 
            orientation  FIXED_AXIS;
            SOLAR_TILT_MODEL SOLPOS;        //Updated solar position model
            SOLAR_POWER_MODEL FLATPLATE;    //Not necessary, but improves accuracy of the model
            };
    

    I hope these changes and suggestions resolve the issues you were seeing in the code.  If you have any further questions or concerns, please feel free to post them here.

    -Frank

     
  • Mark Chatters

    Mark Chatters - 2013-03-06

    Hi Frank,

    Thank you for looking at this - we will get these changes included in our build - I'll let you know how we go

    Regards Mark

     
  • Mark Chatters

    Mark Chatters - 2013-03-08

    Hi Frank,

    I've done some tests on our new build - and, as they say, there is good news and bad news.

    The good news is that, after taking your suggestions, the tilt angle and azimuth now work as expected.

    The bad news is that I still have a problem with my peak solar output being 1 hour out in daylight saving. I've had a quick look at the code (and entirely possible that I am reading it wrong) - but I think the calls to solar_time routine in climate.cpp must be passing a local time in the std_time variable - not the standard time that the logic needs.

    Could that explain it ?

    Thanks for your help

    Mark

     
  • Frank Tuffner

    Frank Tuffner - 2013-03-08

    Hello Mark,
      Once again, you've pointed out where our code has some short falls.  Back when everything was written, people outside the south and west hemispheres were not really considered.  We had an issue with our daylight savings code that prevented it from ever entering DST mode in the southern hemisphere (or in any situation where the DST time crossed year boundaries).  This should be fixed as part of r3876 inside branch 2.3.
     
    If you get a chance, please merge that into your files and see if it works.  If it is still causing problems, please let us know.

    -Frank

     
  • Neil Stephens

    Neil Stephens - 2013-03-11

    Gday Frank,

    I've had a look at changeset 3876 that you mention in your reply to Mark. The results posted are actually from a build that has the DST bugfix already (albeit less thoroughly implemented than the changes in r3876).

    Actually, the problem wouldn't be present if DST wasn't working. Mark has identified that when SolarAngles::solar_time() is called in climate.cpp, that gl_localtime() is used to supply the hour of the day.

    SolarAngles::solar_time() expects standard time, not DST, but gl_localtime() will return DST.

    I've applied a fix to branch ticket/697 if you would like to pull it across. See http://sourceforge.net/apps/trac/gridlab-d/changeset/3881.

    I will also apply it to ticket/690 (our branch of misc bugfixes intended to be merged into 2.3), but I haven't updated that branch with the other changes from 2.3 lately, so I need to do that first.

    Cheers,
    Neil.

     
  • Neil Stephens

    Neil Stephens - 2013-03-14

    We found one more instance where DST could be used for solar calculations. One line fix in climate.cpp:

    sa.solpos_vals.hour = dt.hour+(dt.is_dst?-1:0);

    Cheers,
    Neil.

     
  • Frank Tuffner

    Frank Tuffner - 2013-03-14

    Mark, Neil, and Kelvin,
      Thanks for the code updates.  I believe we have them all implemented at this time, but if you encounter any discrepancies, please let us know.  Theoretically, version 3.0 is our more "internationally-oriented" version of GridLAB-D, but all of these items were things that needed to be fixed there as well, so thank you for pointing them out.  If you find anything else that we've obviously overlooked, especially for southern or eastern hemispheres, please let us know.
     
    -Frank

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks