Disciplined convex programming error:
Cannot perform the operation: {convex} ./ {convex}
出错 ./ (line 19)
z = times( x, y, ‘./’ );
oh，yeah。Helped me solve a very important problem .thanks
However, sometimes when I use cvx, these constraints cause errors in the results. “nan”.Sometimes good, sometimes bad.
{x,s,y} == rotated_lorentz(1); {s,z,x} == rotated_lorentz(1);
z>=0;s>=0;
You should look at the solver and CVX output. Does CVX say the problem is infeasible? Or perhaps the solver failed? If you are not using CVX 2.2 with Mosek 9.x or 10.x, and are not using CVXQUAD with exponential.m replacement, then CVX"s unreliable SUCcessive Approximation method is used, which may fail, even when an optimal solution actually exists.
You should use CVX 2.2 with Mosek 9.x or 10.x, else follow the instructions at CVXQUAD: How to use CVXQUAD's Pade Approximant instead of CVX's unreliable Successive Approximation for GP mode, log, exp, entr, rel_entr, kl_div, log_det, det_rootn, exponential cone. CVXQUAD's Quantum (Matrix) Entropy & Matrix Log related functions to try to prevent solver failure.
Also, make sure the numerical scaling is good.
When using SDPT3, it says “failed”. When using Mosek, it says “Infeasible”. I’ve also used CVXQUAD, maybe I’m scaling it wrong, but I’ve tried n ways. I have attached my code, I hope you can try to run it, I can’t think of any suitable solution, you can change the size of some constants slightly if necessary. I look forward to your help.
%%
clc;
clear all;
close all;
tic
T = 0.08;
N = 20;
Cu = 1000;
Cn = 1000;
Ku = 10^-27;
Kn= 310^-28;
f_umax= 210^9;
f_nmax= 310^9;
Pu_Tmax = 2;
Pn_Tmax = 3;
Bd = 10^6;
Mu =1510^-6;
V=110^01.00016KuCu^3(10^5)^3/T^2;
v=110^1;
Bn=0.0072;
X=-7.8851e-04;
Y=2.4787e-04;
en=7.8142e-04;
er=1.0897e-04;
eL=9.4268e+03;
Au=3.7100e+04;
coef_z=10^12;
coef_s=10^6;
CS=10^-0;
eLb=110^0;
Hun_1_27 =2.8072e-05;
Hun_2_27 =2.1070e-05;
Hua_2_27 =1.6429e-08;
Hua_3_27 =7.9244e-08;
Hna_3_27 =1.0355e-06;
xita=sqrt(1e-9);
cvx_begin
%cvx_solver Mosek
variables l_A27 dn_A27 da_A27
variables Eu1_A27 Eu2_A27 Eu3_A27 En_A27
variables t1_A27 t2_A27 t3_A27
variables z_A27 s_A27
minimize V*(Ku*Cu^3*pow_p(l_A27*CS,3)/T^2+Eu1_A27+Eu2_A27+Eu3_A27)+X*(en+(-Kn*Cn^3)*((eL)^3*pow_p(t1_A27,-2)+z_A27*coef_z)-En_A27)+v*Y*(er-Mu*N*T)
subject to
t1_A27+t2_A27+t3_A27==T; T>=t1_A27; t1_A27>=0; T>=t2_A27; t2_A27>=0; T>=t3_A27; t3_A27>=0;
t1_A27*Pu_Tmax>=Eu1_A27; Eu1_A27>=0; t2_A27*Pu_Tmax>=Eu2_A27; Eu2_A27>=0; t3_A27*Pu_Tmax>=Eu3_A27; Eu3_A27>=0; t3_A27*Pn_Tmax>=En_A27; En_A27>=0;
l_A27*CS+dn_A27*CS+da_A27*CS>=Au; l_A27*CS>=0; dn_A27*CS>=0; da_A27*CS>=0;
{dn_A27*CS,s_A27*coef_s,(T-t1_A27)} == rotated_lorentz(1);
{s_A27*coef_s,z_A27*coef_z,dn_A27*CS} == rotated_lorentz(1);
z_A27*coef_z>=0;s_A27*coef_s>=0;
(Cu*l_A27*CS)/T<=f_umax; Cn*dn_A27*CS<=f_nmax*(T-t1_A27);
dn_A27*CS<=Bd*(-rel_entr_quad(t1_A27,t1_A27+(Hun_1_27/xita^2)*Eu1_A27))/log(2);
da_A27*CS<=Bd*(-rel_entr_quad(t2_A27,t2_A27+(Hun_2_27/xita^2)*Eu2_A27))/log(2);
da_A27*CS<=Bd*(-rel_entr_quad(t2_A27,t2_A27+(Hua_2_27/xita^2)*Eu2_A27))/log(2)+Bd*(-rel_entr_quad(t3_A27,t3_A27+(Hua_3_27/xita^2)*Eu3_A27+(Hna_3_27/xita^2)*En_A27))/log(2);
Cn*eL/f_nmax<=t1_A27;
eL*T*pow_p(t1_A27,-1)-eL-dn_A27*CS<=0;
(Kn*Cn^3)*((eL)^3*pow_p(t1_A27,-2)+z_A27*coef_z)+En_A27<=Bn;
cvx_end
The first thing you need to do is improve the numerical scaling. All input data should be within a small number of orders of magnitude of one. Does Mosek issues any warnings about large or near zero elements?
Do you mean by numerical scaling and entering data to unify n known quantities to an order of magnitude?
If this is the understanding, then known too much will not have new trouble.
I am now using the SDPT 3 solver, although it sometimes appears “nan”, but the Mosek solver has a nearly 100 percent probability of the + inf.
How do you see Mosek giving any warning about large elements or near-zero elements?
Try changing the units used in the program so that all non-zero input data is within s small number of orders of magnitude of one.
Here’s an example with Mosek warning messages showing the beginning of Mosek output.
MOSEK Version 10.0.45 (Build date: 2023-5-16 08:14:59)
Copyright (c) MOSEK ApS, Denmark WWW: mosek.com
Platform: Windows/64-X86
MOSEK warning 62: The A matrix contains a large value of -1.0e+12 in constraint '' (0) at variable '' (0).
MOSEK warning 62: The A matrix contains a large value of -1.0e+12 in constraint '' (1) at variable '' (0).
Problem
Name :
Objective sense : minimize
Type : LO (linear optimization problem)
Constraints : 2
Affine conic cons. : 0
Disjunctive cons. : 0
Cones : 0
Scalar variables : 1
Matrix variables : 0
Integer variables : 0
This is the warning message that mosek provides and I have tried to scale the input data as well as changing the size of some data to make it easier to meet certain constraints.
It did find the optimal solution, but I checked back and found that it did not meet some other constraints, which made me very headache.
So I go back to the sdpt 3 solver. Although it often appears “nan”, as long as it can solve the optimal value, the optimal value of these variables can meet all the constraints, which makes me feel amazing.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col ‘’ (28) of matrix ‘A’.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col ‘’ (57) of matrix ‘A’.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col ‘’ (60) of matrix ‘A’.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col ‘’ (63) of matrix ‘A’.
MOSEK warning 57: A large value of 2.4e+08 has been specified in c for variable ‘’ (22).
What are the largest and smallest magnitude non-zero data as you entered into CVX? Obviously, your scaling was not good. I don’t know whether better scaling is possible.
The order of magnitude of the maximum input data is 10 ^ 5, and the minimum is 3 * 10 ^ -28, but it is a constant.
Maybe I still don’t understand what you mean by zoom the input data. Can you give a simple example, the mosek instruction solution doesn’t seem very intuitive.
I can feel from the above conversation, you think using mosek is definitely better than sdpt 3. I will try it again
3 * 10 ^ -28, is a very small magnitude non-zero number, and triggers a Mosek warning message. Can this number be replaced by zero? If not, can the choice of units be changed to about such a small number? For instance, nanometers instead of kilometers.
For example, an optimization problem: min 3 * 10 ^ -28x1 + x2, x1 and x2 are all joules. If 3 * 10 ^ -28 is changed to 3 * 10 ^ -18, then the unit of x1 needs to be expanded by 10 ^ 10 times, then will there be no problem in the optimization process?
Is the replacement unit or zoom so understood so?
There are two energy drinks. One gives 10^{-18} calories per litre, the other 1 calorie per litre. You want to find some combination of them which maximizes the total number of calories 10^{-18}x+y, subject to some other constraints, where x,y denote how many litres of each drink you want to intake.
There are two possibilities.
Either you expect x,y to be of reasonable magnitude for a human being to drink, say somewhere about 1 litre. In that case x completely doesn’t matter, including it is way below the numerical resolution of any solver and you should just ignore it in the model.
Or you are expecting that both summands, that is 10^{-18}x and y will be of similar, reasonable order of magnitude, say you expect to drink some single petalitres of the first drink, and some single litres of the other (x\approx 10^{15}, y\approx 1). In this case it is better to express the amount of the first drink, for example, in the number of exalitres X and have an objective of the form X+y and expect a solution of magnitude X\approx 10^{-3}, y\approx 1. This way both the coefficients and the expected solution values become simultaneously more even and therefore manageable.
Expecting anything else is numerically flawed from the start.
Thank you very much for your image example, my problem belongs to the second situation, I tried to expand the unit, the problem that troubled me for a period of time was finally solved, and I also understand the operation requirements of mosek.
Thank you very much to Mark_L_Stone for your company these days.
I feel ashamed of my not being smart.