The problem of the model loading too slowly

[llL o0O]

I am running my optimization program using the latest version of Matlab, YALMIP, and Gurobi on a laptop equipped with AMD Ryzen 7 7735H with Radeon Graphics at 3.20 GHz and 16GB RAM. The model has been running for two hours now and still hasn't entered Gurobi's solution phase. Do you have any good solutions to this problem? 

Below are my code and some screenshots.

The information displayed in the Matlab command line in the screenshot is from the previous data processing part, and you can see that it has not yet entered Gurobi's solution phase.

[Johan Löfberg]

Error using xlsread (line 136)
XLSREAD unable to open file 'æ—¥å‰ ç®—ä¾‹æŠ¥é‡ æŠ¥ä»·æ•°æ ®.xlsx'.
File
'C:\Users\johlo46\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\A1D01TP3\æ—¥å‰ ç®—ä¾‹æŠ¥é‡ æŠ¥ä»·æ•°æ ®.xlsx'
not found.

Error in dev_da (line 12)
[temp, ~] = xlsread(filename, sheetnames{1});

[llL o0O]

I'm sorry, I forgot to upload all the files.

[llL o0O]

[llL o0O]

All these files are needed for running the first code file

[Johan Löfberg]

I think there are still files missing (or filenames are maybe broken as it is in chinese)

Error using xlsread (line 136)
XLSREAD unable to open file '日�算例报�报价数�.xlsx'.
File 'C:\Users\johlo46\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\A1D01TP3\日�算例报�报价数�.xlsx'
not found.
 

[llL o0O]

To avoid the garbled filename issue you mentioned due to Chinese characters, I have converted all the filenames to English and tried running them on my computer for a short while. Well, at least there were no errors. So I guess this time will be ok, maybe.

[llL o0O]

Now I've running this code for over 6 hours, but I'm still stuck in this stage. Matlab status instructs it's busy.

[Johan Löfberg]

high-dimensional slicing is very slow and inefficient, and you are doing that in several layers deep for-loops. If you profile it you'll see this for instance

          for t = 1:96
                Constraints = [Constraints,-mu_ctb(c,b,t) + mu_nt(1,1,t,w) - xi_ctb_D_lower(c,b,t,w) + xi_ctb_D_upper(c,b,t,w) - xi_ct_Dsum_lower(c,1,t,w) + xi_ct_Dsum_upper(c,1,t,w) == 0];
                Constraints = [Constraints, 0 <= P_ctb_D(c,b,t,w) - P_ctb_D_min <= M*b_D1(c,b,t,w), 0 <= xi_ctb_D_lower(c,b,t,w) <= M*(1-b_D1(c,b,t,w))];
                Constraints = [Constraints, 0 <= P_ctb_D_max(c,b,t) - P_ctb_D(c,b,t,w) <= M*b_D2(c,b,t,w), 0 <= xi_ctb_D_upper(c,b,t,w) <= M*(1-b_D2(c,b,t,w))];
            end

is completely bogging down the process. Simply vectorizing the loop in t drops that part by a factor of close to 100.

You just have to go through the code and get rid of unnecessary loops. There are loads of them. 

Where you cannot, you should make sure the small loops are in the outer layers so the the vectorization is done on large slices

for i = 1:5
 for j=1:5
   for k = 1:96
      x(i,j,k)

replaced with 

for i = 1:5
 for j=1:5
      x(i,j,:)

is going to have a much larger impact than rewrtting

for i = 1:96
 for j=1:5
   for k = 1:5
      x(i,j,k)

to

for i = 1:96
 for j=1:5
      x(i,j,:)

[llL o0O]

Your advice is very helpful, thank you. However, restructuring code indeed takes time, and I plan to establish a four-dimensional decision variable through sdpvar, and to solve this problem through vectorization. But I'm concerned that high-dimensional array operations in YALMIP may be slow, and I'm wondering if vectorization can compensate for this issue?

[Johan Löfberg]

Why don't you simply profile and see

Based on what I saw and told you yes,  when I profiled, at the time I cancelled it the code above had consumed 800 seconds, I then made the trivial removal of the inner loop to vectorize that as stated and ran it and it dropped to a few seconds.