Imbalanced discharge and charge for electric storage

[LipingWang]

Issue overview

The discharged electricity from the batteries (ElectricLoadCenter:Storage:Battery) is larger than the charged electricity for batteries over a certain period (annually as well as monthly). This could be because that the available stored electricity and available storage capacity of batteries were not properly considered in "charging" and "discharging" for each timestep.

Details

Some additional details for this issue (if relevant):

• v9.5
  • helpdesk ticket 15736

Checklist

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

• [x] Defect file added EnergyPlusDevSupport/DefectFiles
• [ ] Ticket added to Pivotal for defect (development team task)
• [ ] Pull request created (the pull request will have additional tasks related to reviewing changes that fix this defect)

[RKStrand]

@LipingWang In looking at this, I think the problem arises from the fact that the charging and discharging variables are based on current and voltage and do not translate directly to amount stored. I see evidence in the output that there are hours where there is both charging and discharging--not a problem except there are times when the discharging exceeds the charging but the batteries are showing an increase in storage. That shouldn't be possible, but the equations for charging and discharging have a complex relationship with the current. One potential solution would be to report a new variable that shows the change in storage. The problem with this is two-fold. First, we are at the IO Freeze so we can't add anything to the output until after the release. Second, I'm concerned that adding this variable will produce even more confusion. I've gone through the code in simulateKineticBatteryModel pretty carefully and have not found a source of error. The method agrees with the equations in the Engineering Reference and the model is from the literature. However, it seems to me that there is a possibility for a disconnect between charged/discharged/stored in the mathematical model from the literature. Of course, I could be wrong. If someone wants to pick this up in the meantime, they are welcome to reassign it to themselves. Otherwise, I'll have to wait until after the release and even then I'm not sure I'll have a way to "fix" this.

[RKStrand]

@LipingWang I am looking at this again so that this can be resolved. I switched to looking at output at the "detailed" level. What I am finding is that you simply can't sum up the energy values in Joules and get the charging and discharging to line up. The voltage is calculated based on curves that are not equivalent in the input. As a result, the voltages will not be the same during charging and discharging even if the current in amps is the same. As a result, the energy values simply won't agree. What the model does is keep track of the storage in amp-hours. I anticipated that keeping track of things properly. However, I am seeing a problem there--the storage terms seem to be updating twice each time step, meaning the amount that it thinks it has is actually twice what it should be. I should be able to take the storage from the last time step and add the product of the new current times the time step to get a new storage amount. Regardless of the time step, it appears that the amount added ends up being two times the new current times the time step. I suspect that an extra call is being made and the previous values of the storage amount is being updated each time, resulting in essentially twice the storage. It does this regardless of the system time step and even maintains this when the system time step gets reduced. It's always a factor of two. That needs to be fixed. As for the charging and discharging in Joules, the disconnect that you are seeing seems to be "by design". I have reverified the equations between the Engineering Reference and the code and everything seems to be in order. Also, I am now of the opinion that a new variable really won't solve anything though I may still elect to add it in if I can get the double counting issue resolved.

[RKStrand]

I have resolved what I was seeing before. There isn't actually a problem with the calculation of the storage. However, a new output variable and some improved documentation will go a long way to resolve this issue. The biggest thing that has to be made clear is that in the kinetic battery model that what is being maintained is the amp-hours in the battery. Due to the changing nature of how it is charged and discharged and different curves for determining the voltage, one simply cannot sum up all of the changing and discharging energy in Joules and get them to balance. That is simply inherent to the way that the kinetic battery model equations work out. However, since the battery storage in that model is in amp-hours, that is what has to be preserved. The new output variable will show the net change in amp-hours so that a user can see that amp-hours are being preserved. The documentation will explain that the change in storage is equal to the current through the battery times the number of batteries time the time step. The user will then be able to see that amp-hours are being preserved. I will also add equations along with that explanation to the Engineering Reference as well as the description of the new output variable in the Input-Output Reference. So, while I do not see any specific bug here as I thoroughly checked the model equations, these additions are important to the understanding of this model and will hopefully avoid confusion in the future.

[mjwitte]

@RKStrand I want to believe you, but energy in must be <= energy out. If that's not the case, then maybe the conversion to/from energy and amp-hrs*voltage is incorrect? I'll wait and see what the new docs say, but commenting now while this is fresh.

[RKStrand]

@mjwitte I get what you are saying and I agree with you should not be able to get more energy out of the battery than was put in. What I see as the problem is that the voltage for charging at any given charge level could be different than the voltage for discharging. So, let's say I want to look at putting 2 Ah of charge in the battery for a one hour time step. If the charging curve says that is happening with a voltage of 1 V (based on the user input curve for charging), then the energy for charging is 2 Wh. Now, let's say that I take that same 2 Ah out but the discharging voltage is 1.5 V (based on the use input curve for discharging) over an hour. The energy for that is 3 Wh. So, because of the curves input, the power coming out exceeds the power going in. The input for the charging and discharging curves is solely the responsibility of the user so there is definitely a possibility that the power discharged could exceed the power charged. Now, the user's input file was essentially the PVwithBattery.idf file that is in the test suite, so perhaps I also need to modify the input file? Does this help explain things at all? If the voltage is always the same, then I would expect energy to balance (if there are no losses).

[mjwitte]

Does this help explain things at all? If the voltage is always the same, then I would expect energy to balance (if there are no losses).

Not really. If the model doesn't protect against inputs that create energy out of nothing, then it needs guardrails.

[RKStrand]

@mjwitte Well, I can't disagree with that. It sounds a bit odd and counter to immutable laws of thermodynamics. Based on testing, it appears that this is only an issue for the kinetic battery model. I tried the Li-Ion battery model and it seems to be reasonable (starts full charged, ends completely empty, slightly more used than stored because of the battery starting fully charged). I'll double-check the simple model too since to be sure.

Here's what I plan to do with the kinetic battery model:

Add a new input for the kinetic battery model (hmmm, now this is starting to sound like a mini-development project 🤦‍♂️) that either keeps the current model results (standard) or adds new variables (energy limited) to keep track of the battery energy. The new option will keep track both of the battery Ah and J and, when either gets to zero, both are zeroed out. I will create new report variables to show these new energy totals. I will still also do all the same documentation changes that I already planned to explain what is potentially happening when the user does not "energy limit" this model.

So, if the user wants to just stick with the current model as is and not conserve energy, the user is perfectly able to do that (might generate a warning message in that case just to let them know they are violating that--will only do it once though as to not be super annoying). Otherwise, it will prevent a lack of conservation of energy.

Ok, what are your thoughts on this potential solution?

[RKStrand]

Update: In the simple battery (bucket model), the charging energy is higher than the discharge energy. So, no magic creation of energy there.

[rraustad]

It seems to me that the problem is that while the battery charges the voltage gradually increases (kinda like the 1 second thermal tank model). The energy bucket should ride the voltage curve.

[RKStrand]

What I have been working on implements a strategy that has two accounting systems, one that looks at amp-hours and one that tracks Joules. When either goes to zero, the other gets zeroed out. So, this should avoid any free creation of energy and hopefully ride whatever curve the user enters.