It looks like this would be a good place for some optimization of the code. I
believe it’s true that the min up and down time constraints are essentially
unnecessary when the min up and down time values are 1. It seems to me that the
only difference is that it becomes feasible to have a startup and shutdown
event (v = w = 1) for a given unit at a given period, resulting in no change in
state. However, this should have no impact unless the startup and shutdown
costs are non-zero, in which case that solution would not be optimal. So, I
believe, simply eliminating these constraints when the min up/down times are 1
should result in an equivalent optimization problem.
As to the question of why a different solution is found, that is to be expected
for problems with multiple optimal solutions and depends on the path the solver
takes to find the solution. I find that often very slight changes in the
problem definition can result in the solver taking a completely different path
to the solution.
So, I see no reason that commenting those lines of code should be a problem if
all of your min up and down times are 1. However, to optimize this code to
handle the general case more efficiently for large systems, it seems like maybe
we should be indexing these constraints by (t, tau) instead of (t, i). If any
of you are interested in helping to implement this improvement, I’m happy to
take this discussion to the MATPOWER-DEV-L list to hash out the details.
Thanks for pointing out this bottleneck.
Ray
> On May 8, 2019, at 11:30 AM, Antonio L'Abbate
> <[email protected]> wrote:
>
> Hi Dominic,
> I am working on a similar problem and I’ve tested your workaround, I can
> confirm that results are essentially the same. I cannot explain why, but I
> get a difference that is perfectly negligible (order of 1e-11).
> In addition I would like to seize the opportunity and ask you for
> information, given the similarity of our problems: in your case do the wind
> generators follow the profiles set as input? I mean in the dispatch is the
> output “res” power comparable to the profiles one?
> Thanks in advance,
> Regards,
> Antonio L’Abbate
> Inviato da Posta <https://go.microsoft.com/fwlink/?LinkId=550986> per Windows
> 10
>
> Da: Hewes, Dominic <mailto:[email protected]>
> Inviato: martedì 7 maggio 2019 12:21
> A: [email protected] <mailto:[email protected]>
> Oggetto: Question regarding min up/down constraints in MOST
>
> Dear Matpower community,
>
>
>
> I am working with a relatively large model ( approximately 1000 conventional
> generators and 4000 wind generators) and am solving a multi-period
> deterministic unit commitment problem (with DC model) in MOST.
>
>
>
> The problem requires a significant amount of time during the setup phase in
> MOST (i.e. mdo.results.SetupTime). The vast majority of this setup time seems
> to be related to the addition of the minimum up and down time constraints
> within the om struct (lines 1538 to 1591 in most.m) and the processing of
> these constraints in the om.params_lin_constraint() call (line 1974 in
> most.m). It seems like these constraints are applied for all wind generators,
> even though the minup/mindown values are set to 1 for all wind gens, and this
> costs a large amount of setup time. Since the xgd.MinUp and xgd.MinDown
> values are set to 1, I would assume that the constraints are not required.
>
>
>
> My question is: If a generator has a minup/mindown limit set to 1 (i.e. no
> limit), does it meaningfully change the problem in MOST if I simply skip the
> minup/mindown constraints for this generator (i.e. do not add the constraints
> defined in lines 1538 to 1591 in most.m)?
>
>
>
> I have tried this out using a simple test, where the minup/mindown limits for
> all gens are set to 1 (i.e. xgd.MinUp(:)=1). I run the most.m script in
> original form and then with lines 1538 to 1591 commented out. Ultimately, I
> get either the exact same solution or something very very close in the
> simulations with and without the minup/mindown constraints. In some cases,
> the result has almost the exact same price, but the dispatch seems to be
> allocated slightly differently between similarly priced generators located at
> the same nodes (i.e. the result is effectively the same).
>
>
>
> Could someone explain why these small differences occur between the results?
> Does this indicate that the skipping of minup/mindown constraints has caused
> problems elsewhere in most.m and I should therefore avoid this approach?
>
>
>
> Any help with these questions would be greatly appreciated.
>
>
>
> Regards,
>
>
>
> Dominic
>
