Tariff Calculation

asked 2019-12-15 13:05:31 -0600

mldichter
2565 ●2 ●11

updated 2019-12-17 14:01:37 -0600

I'm implementing some utility tariffs in EnergyPlus and then checking them in Excel to see if I'm using the EnergyPlus objects correctly. Unfortunately, I'm getting 2%-5% off on the $ amount in my Excel sheet than what EnergyPlus is coming up with. The tariffs are a little complicated, so that could be an error in my Excel sheet instead of EnergyPlus.

Another strange detail is using MJ units versus Therm units for the tariff seems to be much much more accurate for a flat rate tariff. I'm having to go through, translate, and then test my more realistic tariffs to see if that carries through though.

But before I do all that work, I wanted to ask if other people have experienced it. Is this a known issue? There's a couple other posts on this, but I'm waiting on posting of their calculations. If not, I'll document my IDF objects, EnergyPlus outputs, and Execl calculations and update the post.

POST SCRIPT
Silly me. I made a season schedule for my tariff, but I didn't add the schedule to the UtilityCost:Tariff object. To help others, I could have easily noticed this by looking at the Charges subtable in the HTML output file with the TariffReport in the Output:Table:SummaryReports object. image description

There was also a warning in my ERR file, which I didn't even look at.

   ** Warning ** GetInputEconomicsChargeBlock: UtilityCost:Charge:Block="GASWINTERBLOCK" invalid data
   **   ~~~   ** Season="WINTER".
   **   ~~~   **  a Season other than Annual is used but no Season Schedule Name is specified in the UtilityCost:Tariff.
   ** Warning ** GetInputEconomicsChargeBlock: UtilityCost:Charge:Block="GASSPRINGBLOCK" invalid data
   **   ~~~   ** Season="SPRING".
   **   ~~~   **  a Season other than Annual is used but no Season Schedule Name is specified in the UtilityCost:Tariff.
   ** Warning ** GetInputEconomicsChargeBlock: UtilityCost:Charge:Block="GASSUMMERBLOCK" invalid data
   **   ~~~   ** Season="SUMMER".
   **   ~~~   **  a Season other than Annual is used but no Season Schedule Name is specified in the UtilityCost:Tariff.
   ** Warning ** GetInputEconomicsChargeBlock: UtilityCost:Charge:Block="GASFALLBLOCK" invalid data
   **   ~~~   ** Season="FALL".
   **   ~~~   **  a Season other than Annual is used but no Season Schedule Name is specified in the UtilityCost:Tariff.

Looks like there's a $14 difference between my Excel calculation and the EnergyPlus output, but they cancel out. I'm guessing DST has something to do with it, but the sum is what really matters.

Excel                           EnergyPlus  
Month Charge    Annual Charge   Month Charge    Annual Charge
1036.908471     7198.925131     1036.91         7198.93
1275.551854                     1275.55 
960.0292933                     974.05  
758.3005312                     758.3   
62.12539822                     62.13   
0                               0   
0                               0   
0                               0   
13.24609827                     13.25   
590.7892087                     576.77  
883.6610168                     883.66  
1618.31326                      1618.31

edit retag flag offensive close merge delete

Comments

@mldichter please post your IDF file, outputs and excel spreadsheet so that I can try to figure out why you are getting different results.

JasonGlazer ( 2019-12-16 07:20:48 -0600 )edit

@JasonGlazer Sorry for the delay. Here is a google drive link to one of the tariffs. This one has four seasons with a different baseline gas therms in each. The total USD amount isn't too far off, I think ~1%, but the months vary quite a bit. The total error also seems to get worse if you add in a Minimum Monthly Charge in the UtilityCost:Tariff object. My minimum was $71.01 per month, which gave 2%-5% monthly errors. I wasn't sure about my hand calculation though, so I took it out of the linked IDF.

mldichter ( 2019-12-16 15:55:14 -0600 )edit

add a comment

answered 2019-12-17 07:44:53 -0600

JasonGlazer

6835 ●26 ●12 http://www.gard.com/

updated 2019-12-17 07:50:03 -0600

@mldichter your UtilityCost:Tariff object needs to have a Season Schedule Name with four different seasons defined so that the different costs for each season are applied. To diagnose this issue, take a look Tariff Report and look at the Charges subtable, only the GasWinterBlock has any costs and those are shown for the entire year. In addition, the err file did provide some warnings on this same issue.

edit flag offensive delete link

Comments

@JasonGlazer Thanks! Now that the IDF is correct, the charges subtable is making sense. I didn't even think of checking the ERR file either. Now I know.

One more thing though, there is a difference in March and October which cancel out. The monthly average of the Season Schedule is a little bit off for these months, which I assumed was for DST.

mldichter ( 2019-12-17 09:48:00 -0600 )edit

It might be DST, what if you use the numbers shown in the TotalEnergy row of the Native Variables table. Those will account for DST. If you are using numbers from the normal CSV file for each month, I don't think they break the months on the right hour because of DST.

JasonGlazer ( 2019-12-17 09:54:35 -0600 )edit

Nope. The Native Variables of the TotalEnergy row were different in the 1/1000's place of the month's total therms from what I used. A few cents may have changed, but the $14 is still shifted between March and October. Not a problem really considering how imprecise the USD/Therm in my tariff is. I'll continue to check my tariffs by hand to make sure I implement them correctly, but I'm fine with this.

mldichter ( 2019-12-17 10:37:54 -0600 )edit

@JasonGlazer I was doing some more tests and have a case where the March value is off by $1.53 but is not canceled out in October. Here is a google drive link to the IDF and my Excel calculations. According to my spreadsheet, the minimum charge of USD 72.00 should apply for that month, but EnergyPlus calculates USD 73.53 instead. I tried with the TotalEnergy Native Variable as well with the same result. The next month has a much lower baseline allowance, so a shifted hour from DST could explain it.

mldichter ( 2019-12-18 10:41:57 -0600 )edit

add a comment