Problems with energy storage in MOST

[Xiwe]

I was trying to build a 30-bus system with wind energy and storage system base on the seven tutorials provided in MOST. However, it's not working. The storage system started to discharge at the very beginning and kept doing so even though the initial energy level was zero. Or it kept charging regardless of the storage cap. And these problems persisted no matter what values I set to 'InitialStorage' and 'ExpectedTerminalStorageMax/Min'.

Then I tried it in both most_ex6 and most_ex7. The system worked just fine in ex6. All conditions, initial and terminal values, could be changed and met. But when it came to ex7, as long as I left the terminal storage min/max level alone, it worked just fine. The whole charging and discharging process were normal when only the initial energy level was modified. And when I added the terminal level in the system, the same issue happened again.

I'm not sure if it's a bug or I missed something.

[rdzman]

Could you please provide a minimal example to reproduce your results (a script file and any data files not included in MATPOWER/MOST) along with the exact details of the result your are seeing (specific value of which result field) vs. what you expected to see? We need this kind of detail in order to determine the nature of the issue.

Thanks.

[Xiwe]

Thanks for the reply. Sorry for the delay. I was confused about something when I tried to recreate the problems I encountered. I attached files I used and problems I have. Please have a look.

Edit. Somehow I cannot upload my files, I tried zip, 7 zip and rar, none of them is working. Is there another way I can send my files to you?

Thank you.

[rdzman]

Hmmm. I haven't tried attaching files before, but according to the GitHub Help page about attachments it should be possible to attach .zip files. Was it larger than 25 MB? It would certainly be nice to keep the files here with the issue if possible.

[Xiwe]

I'm quite confused too. I tried jpg, word and pdf, all of them works just fine. I did summarized problems I have in word. But I can't upload m.files. issues.docx 30 bus issues.docx

[rdzman]

According to the GitHub Help page I referenced, you can also upload .zip files. I tried putting several .m files in a .zip file and was able to upload them to a test issue with no trouble. Is that what you tried?

[Xiwe]

Yes, that's exactly what I did. I even tried different software, win zip, 7 zip, win rar. I have absolutely no ideal why it's not working :(.

[Xiwe]

I think I'll just convert all the m.files to txt format then upload them. These are the 30-bus sytem m.files Most_30_test.txt t_case30_most.txt case30_plot_contingency.txt ex_contab30.txt ex_load_profile30.txt ex_storage30.txt ex_transmat30.txt ex_wind_30.txt ex_wind_profile30.txt

[Xiwe]

And these two are the files I changed to run tutorial 6 and 7. Please have a look. Thank you. most_ex7_suc.txt ex_storage.txt

[rdzman]

I haven't looked at the code yet, but in looking over your Word attachments, it appears that you do have some misinformed expectations about how MOST handles the secure and stochastic problems, especially with regards to storage.

First, if you are approximating your stochastic problem with 3 states in each period, this is not equivalent to three 24-hour trajectories. The transitions from one period to another are controlled by a transition probability matrix. This formulation means that the storage feasibility cannot be handled by tracking individual storage levels associated with each path through the tree of possible transitions (which explodes with the number of periods in the planning horizon), but rather by tracking only upper and lower bounds on storage. And even that only for the base states in each period. See Section 3.6 and the storage related parts of Section 4.2 in the MOST User's Manual for details.

Because of this formulation, even for a stochastic case with identity matrices for transition probabilities, the storage model does not track actual storage levels, but rather upper and lower bounds. Also, contingency states are considered to be off the high-probability central path where inter temporal constraints (such as storage) are considered. Dispatches in contingency states should be feasible with respect to the base state it branched off from, but the formulation does not include any consideration of future states following a contingency.

So, I suspect that your issues stem, not from a bug, but from a misunderstanding of how MOST handles stochastic problems, especially with storage. Let me know whether or not this helps clear things up.

[Xiwe]

Dear Ray,

Thanks for the reply and explanation. I'm afraid I'm still confused. I uploaded another word document so I could attach some pictures in it. Please have a look. Thanks so much for your time and help, much appreciated! still confused.docx

[rdzman]

Let me respond to several issues.

1. Regarding the storage bounds, some of them are fixed parameters specifying the capacity of the storage unit (S^ti_max, S^timin). Others are optimization variables that track the max and min charge levels corresponding to the solution (s^ti+, s^ti_-). These are used manage the relationship between the dispatches and the capacity bounds.

   To simplify the storage constraints in equations (4.33)-(4.36), let's assume that contingencies happen at the beginning of the period (alpha = 0), the storage is 100% efficient and lossless (eta^ti_in = 0, eta^ti_out = 0, eta^ti_loss = 0), and the storage dispatch bounds are based solely on the previous period bounds (rho^ti = 1). These assumptions mean that beta^ti_1 = 1, beta^ti_2 = 1, beta^ti_3 = 1, beta^ti_4 = 0 and beta^ti_5 = 1.

   So (4.33)-(4.34) simply state that the upper bound on stored energy in period t (s^ti_+) is equal to the upper bound in period t-1 plus the maximum charge, and the lower bound in period t (s^ti_-) is equal to the lower bound in period t-1 minus the maximum discharge. Equations (4.35)-(4.36) restrict the dispatches in contingency states to ensure that the capacity bounds are not violated.

2. The "full trajectory" case, where the transition probability matrix is an identity matrix, only affects the probability of the scenarios and the corresponding weighting of costs, it does not affect the rest of the formulation. That is, the formulation still does not have variables that track the storage levels along probability 1 transition paths through time, only the upper and lower bounds on the storage across all scenarios in each period.

   So, for example, suppose I have two scenarios, a high wind and a low wind scenario, in each hour. Suppose I have two hours, where the high and low scenarios are equally likely in the first hour and we have some transition probability matrix determining the probabilities in the second hour. Finally, suppose I have a 10 MWh battery that is half full to start with and it charges at 1 MW in the high wind scenarios and discharges at 1 MW in the low wind scenarios.

   In this case, the endogenous upper bound (s^1i+) on the energy stored in the unit in period 1 is 6 MWh, determined by the dispatch in the high wind state, and the lower bound (s^1i-) is 4 MWh determined by the dispatch in the low wind state. In hour 2, those bounds move to 7 MWh and 3 MWh. Even if the transition probability matrix indicates that high in hour 1 goes to low in hour 2 and vice versa with probability 1, that does not change how these bounds are computed. It simply affects the weights of the various dispatch costs in the objective function.

   Ideally there would be an option to handle the "full trajectory" case, with all identity matrix transition probabilities, as a special case with a different problem formulation in which actual storage states are tracked rather than just bounds, since in this case it does not result in an explosion of storage states.

3. The wind levels simply set the PMAX of the given wind generator, not the actual dispatch. It is still possible for the generator to be dispatched below it's PMAX value if that is economical.

[Xiwe]

Dear Ray,

Thanks for your patience and very detailed explanation.

I was thinking about what you said: Regarding the 'individual trajectory' case, wind power is considered of high, base and low situations. And each of them is tracked and calculated independently. But when it comes to the 'full trajectory' case, the high wind and low wind can be considered as the upper and lower boundary. The middle one is the one we really want to study. And it bounces between the boundaries due to the introduction of the 'full transition matrix'. But if the middle one is the one I'm looking for why there are three curves. And this is the moment I realized that I made a huge mistake, I was checking data under 'ms.xxx' all the time instead of 'mdo.results.xxx'. I didn't know why I keep doing that. And when I using data from 'mdo.results.expecteddispatch', the results start to make sense.

Thank again for taking the time to explain everything. You've been a great help！

[rdzman]

You are welcome.