Storage Device remains at StoredEnergyLevel=0 when Pg<<0, if lossfactor>0

[lordleoo]

The example is attached; The system description is: PV panel on bus 1 storage device on bus 2 another type of storage device on bus 3 fixed load on bus 4 fixed + dispatchable load on bus 5

A storage device takes in a significant amount of power, however, if its state-of-charge (stored-energy-level) was 0 at t-1, then its storedEnergyLevel will remain at 0. This only happens when lossfactor > 0.

To re-produce the problem: 1) Load the MAT file, it contains 3 variables: md0_parts, most_opts and mdo1 2) you can directly look at the solution in mdo1, or run MOST yourself mdo1 = most(mdo0_parts{1},mpoption(most_opts,'most.build_model',0,'most.solve_model',1,'most.resolve_new_cost',1)) or mdo1 = most(mdo0_parts{1},mpoption(most_opts,'most.build_model',1,'most.solve_model',1,'most.resolve_new_cost',1)) (the difference between the 2 lines above is most.build_model = true or false)

once you get the solution, please check the storedEnergyLevel on the first storage device which is located on bus (2), and check it's power output at t= 59 and t=61

if you change the lossfactor to 0, the problem goes away I didn't investigate the cause because it wasn't a big deal for me, i was just playing with lossfactor

• most_summary does NOT print the StoredEnergyLevel (state of chage) of storage devices. you have to check it yourself. I modified most_summary such that it prints the "EXPECTEDstoredenergylevel". I hope i'm printing the right variable here. I also modified most_summary to print the load. The file is attached; modifications I made are labelled as: "added by " or "changed by "

most_summary.zip GitHub_Example.zip

This is the last time i'll annoy you with a bug or an issue-post :smile: I swear.

[rdzman]

So, if I understand the issue, when LossFactor is non-zero you are seeing the value of mdo.Storage.ExpectedStorageState remain at zero even for periods (e.g. t=59, 61) where there is significant charging, correct?

I see this in mdo1 in your attached MAT file. And while I am not able to reproduce the identical result on my machine, when I run the case with mpopt = mpoption('most.dc_model', 0) (your MAT file was missing the most_opts) on my machine, I get a different solution with a near identical objective function. This solution also exhibits the problem (ESS 2 in periods 2 and 3).

This is taking a while for me to debug what's going on, but I'm working on it. Here are a few observations so far, some of which may not be relevant to this issue.

• You have $1 cost in gencost for these storage units. This means that all charging/discharging cutoff price points will be $1 higher than they would otherwise be. Typically the gencost is set to zero for storage units.
• The Psc and Psd variables coming out of the optimization are both non-zero for (at least some of) the cases where this problem manifests. Manually "fixing" them (setting one equal to the sum and the other equal to 0) after the problem is solved, but before the solution is post-processed does not seem to affect anything.
• Setting mdi.Storage.rho to ones instead of zeros results in an infeasible problem. For a deterministic problem the value of rho should have no effect. So I'm looking into this more closely. I suspect this will lead us to the explanation.

[lordleoo]

Thanks for your effort Let me know if there's anything i can do to help The generation cost for the storage devices is 1$, and also for the solar-panel on bus 1 too. Generation cost is 10$ for the dispatchable load on the last bus; i wanted to incentivize/motivate the solver to dispatch this load as long as it is feasible.

I did not define any wind scenarios or contengencies, I'm not sure if "rho ~= 0" makes sense in this situation

Here is the most_opts which i was using:

most_opts=mpoption('opf.ac.solver','MIPS','mips.max_it',1500,'mips.step_control',1,'opf.start',0,...
'opf.init_from_mpc',1,'opf.return_raw_der',1,'opf.violation',1e-2,'out.all',0,'out.suppress_detail',1,'verbose',0,...
'most.solver','GUROBI','most.skip_prices',1,'most.storage.terminal_target',0,'most.dc_model',0,'most.fixed_res',...
0,'most.security_constraints',0,'most.storage.cyclic',0,'most.uc.run',false); 

if strcmpi(most_opts.most.solver,'GUROBI')
most_opts.gurobi = struct('method',1,'timelimit',inf,'threads',4,'opts',struct('FeasibilityTol',1e-6,'IntFeasTol',1e-7),'opt_fname',[],'opt',0);
end

if strcmpi(most_opts.most.solver,'CPLEX')
most_opts.cplex = struct('lpmethod',0,'qpmethod',0,'opt',0);
end`

[lordleoo]

* The Psc and Psd variables coming out of the optimization are both non-zero for (at least some of) the cases where this problem manifests. Manually "fixing" them (setting one equal to the sum and the other equal to 0) after the problem is solved, but before the solution is post-processed does not seem to affect anything.

I uploaded a modified most_summary file on Saturday, and submitted a pull-request. The branch name is BaMo. I am still learning to navigate GitHub; I hope you're not getting a notification every time i do something. :smile:

You can use it to print Psc and Psd

All my codes are written in Matlab/R2019a

[rdzman]

Upon further investigation, regarding the 2nd observation above, it turns out that "fixing" Psc and Psd actually makes the problem infeasible.

[rdzman]

In general rho should be 1 for deterministic cases and for stochastic cases where you want to guarantee feasibility of the storage constraints for all non-contingency scenarios. Decreasing rho relaxes the constraints a bit to reflect the fact that the worst case is not likely to happen every period.

Regarding GitHub, I do get notified when new issues or PR's are created or responded to, so no need to mention one in the comments for another. So, for tracking purposes, it's always best to keep each issue/pull request focused on a single issue.

[rdzman]

The generation cost for the storage devices is 1$ ...

Right. I was saying that this is not typical and probably is not what you really intend. If the cost is $0, it essentially means you want to charge and discharge whenever doing so improves the overall cost of operating the system. With a cost of $1, you are shifting up by $1 the price points at which this charging/discharging kicks in. That is, you are saying you won't sell power (discharge) unless you can get at least $1 more than it's worth and you will start buying power (charging) as long as long as it costs less than $1 above what it's actually worth.

[rdzman]

This has been a tough one to figure out, but I think I finally understand it. There are a number of things going on.

1. It turns out that, as a consequence of modeling the charging and discharging of storage as in (4.28)-(4.30) in the MOST manual, it is possible for a storage unit with less than 100% charging and/or discharging efficiency to simply "burn" energy by both charging and discharging within a given period. That is, Psc and Psd can both be positive.

   This would almost never be optimal, except in certain corner cases where absorbing energy without increasing the state of charge in certain periods makes an otherwise infeasible problem feasible.

   It should be noted that this is not directly related to the value of LossFactor at all.

2. For deterministic problems, there is one difference between rho = 0 and rho = 1 that I had not thought of, and it explains why your particular problem is feasible when rho = 0 and not when rho = 1. For rho = 1, the constraints on the first period state-of-charge bound variables, equations (4.33)-(4.34) in the manual, are relative to mdi.Storage.InitialStorage[Lower/Upper]Bound as opposed to mdi.Storage.InitialStorage for rho = 0.

3. There is currently a bug (see #11) in the implementation of constraints (4.33)-(4.34) for t=1.

With the bug fixed, the problem is still feasible when rho = 0 and not when rho = 1. And I no longer see any periods where we are "burning" energy by charging and discharging within the same period.

Feel free to re-open this issue if you think it's not yet resolved.