I am updating prices inside meter modules of gridlab-d through Helics. This price is updated on every iteration. The meter module is supposed to calculate the monthly_bill taking into account the correct price variation and then calculating in somewhat I would call a 'running sum'.
The meter module however, calculates a spot sum. It multiplies all the value of energy flowing by the current price.
I can see your confusion on UNIFORM bill mode. The description on that mode is misleading. While the price can fluctuate via a schedule or player it supposed to represent the the mean price in a uniform distribution over the month and not a spot calculation. To get the desired behavior you want you can use the TIERED_TOU mode. Your HELICS configuration should send your prices to the first_tier_price property. An example meter should look like
Hello Gridlab-D Team,
Hope your day is going great today.
I am updating prices inside meter modules of gridlab-d through Helics. This price is updated on every iteration. The meter module is supposed to calculate the
monthly_bill
taking into account the correct price variation and then calculating in somewhat I would call a 'running sum'.The meter module however, calculates a spot sum. It multiplies all the value of energy flowing by the current price.
See attached image for how it looks like.
Here is my meter module code:
I am referencing this definition of the UNIFORM billing mode:
Last edit: Ali Khan 2023-02-14
Good Morning Gridlab-D Team,
Any hope with this?
Thanks,
Ali
Hello Ali,
I can see your confusion on UNIFORM bill mode. The description on that mode is misleading. While the price can fluctuate via a schedule or player it supposed to represent the the mean price in a uniform distribution over the month and not a spot calculation. To get the desired behavior you want you can use the TIERED_TOU mode. Your HELICS configuration should send your prices to the first_tier_price property. An example meter should look like
Please also note that for a given timestep the bill is calculated using the previous timestep's price properties.