Yes. I also think that my equation can be transformed to the form that CVX accepts. I am still trying to transform to the suitable form. If anyone can figure out suitable transformation, please let me know. Thanks.

Mu solution works when A = B = c = 1. You just need to adapt it by looking at the derivation, to handle other values of A,B,c.

You will also make things easier for everyone if you show formulas as code, not images. Also, it’s easy to check your work by picking random values of the inputs and seeing if the numerical value of the reformulation matches the original.

Expressions R1, R2, R3, and R4 in my code are concave expressions. Hence, the objective function is a product of an affine and concave expression. Thus, when running this code, I am getting an error which is as follows.

Error using .* (line 173)
Disciplined convex programming error:
Cannot perform the operation: {real affine} .* {concave}

How to modify my code to handle this issue in CVX? Help required. Thanks in advance.

I’m confused as to what mathematical problem you are trying to solve.

Do you have the expression involving the product of tau and log(1+…) in terms of sum of -rel_entr() ? If so, why are you attempting to multiply the -rel_entr terms by tau again?

As a check, pick some random numbers for all the inputs and verify the original non-DCP compliant formulation produces the same result, within roundoff error, as the reformulation using -rel_entr.

CVX Warning:
Models involving “rel_entr” or other functions in the log, exp, and entropy
family are solved using an experimental successive approximation method.
This method is slower and less reliable than the method CVX employs for
other models. Please see the section of the user’s guide entitled
The successive approximation method
for more details about the approach, and for instructions on how to
suppress this warning message in the future.

Successive approximation method to be employed.
For improved efficiency, SDPT3 is solving the dual problem.
SDPT3 will be called several times to refine the solution.
Original size: 38 variables, 13 equality constraints
12 exponentials add 96 variables, 60 equality constraints

For my code , CVX failed to solve the problem. And I have noticed a suggestion for such issues. Hence I installed CVXQUAD.
As I noticed, rel_entr_quad(x,y)=x.*log(x./y). I replaced rel_entr(x,y) in the above program as rel_entr_quad(x,y). Then, again problem is not solved. And obtained as follows.

Calling SDPT3 4.0: 242 variables, 97 equality constraints
For improved efficiency, SDPT3 is solving the dual problem.

num. of constraints = 97
dim. of sdp var = 144, num. of sdp blk = 72
dim. of linear var = 26

SDPT3: Infeasible path-following algorithms

version predcorr gam expon scale_data
HKM 1 0.000 1 0
it pstep dstep pinfeas dinfeas gap prim-obj dual-obj cputime

Your program is not reproducible, because it is missing input data. Therefore, i can’t run it.

One thing you can try yourself is to specify sedumi as the solver.

Better yet, if you have access to Mosek 9.x, restore CVX’s version of exponential.m, make sure you are using CVX 2.2, then start a fresh MATLAB session. Sspecify Mosek as solver, and run it. That will utilize Mosek 9.x’s native exponential cone capability, which is the most robust and reliable of the solution options for this problem. It will also print our warnings and other useful diagnostic information which Mosek employees who read this forum can assess.

MOSEK warning 62: The A matrix contains a large value of -1.6e+10 in constraint ‘’ (12) at variable ‘’ (2).
MOSEK warning 62: The A matrix contains a large value of -1.0e+11 in constraint ‘’ (12) at variable ‘’ (5).
MOSEK warning 62: The A matrix contains a large value of 4.3e+10 in constraint ‘’ (12) at variable ‘’ (7).
MOSEK warning 62: The A matrix contains a large value of -1.2e+11 in constraint ‘’ (12) at variable ‘’ (8).
MOSEK warning 62: The A matrix contains a large value of 3.7e+10 in constraint ‘’ (12) at variable ‘’ (10).
MOSEK warning 62: The A matrix contains a large value of -1.6e+10 in constraint ‘’ (12) at variable ‘’ (11).
MOSEK warning 62: The A matrix contains a large value of -1.5e+11 in constraint ‘’ (12) at variable ‘’ (14).
MOSEK warning 62: The A matrix contains a large value of 6.1e+10 in constraint ‘’ (12) at variable ‘’ (16).
MOSEK warning 62: The A matrix contains a large value of -1.7e+11 in constraint ‘’ (12) at variable ‘’ (17).
MOSEK warning 62: The A matrix contains a large value of 5.5e+10 in constraint ‘’ (12) at variable ‘’ (19).
Warning number 62 is disabled.
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 13
Cones : 12
Scalar variables : 38
Matrix variables : 0
Integer variables : 0

Optimizer started.
Presolve started.
Linear dependency checker started.
Linear dependency checker terminated.
Eliminator started.
Freed constraints in eliminator : 0
Eliminator terminated.
Eliminator - tries : 1 time : 0.00
Lin. dep. - tries : 1 time : 0.01
Lin. dep. - number : 0
Presolve terminated. Time: 0.11
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 13
Cones : 12
Scalar variables : 38
Matrix variables : 0
Integer variables : 0

Status: Infeasible
Optimal value (cvx_optval): -Inf

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
And sedumi solver result is as follows.

Successive approximation method to be employed.
For improved efficiency, SeDuMi is solving the dual problem.
SeDuMi will be called several times to refine the solution.
Original size: 38 variables, 13 equality constraints
12 exponentials add 96 variables, 60 equality constraints

I wrote “It <Mosek> will also print our warnings and other useful diagnostic information” Did you look at the warnings from Mosek about large coefficients? Those large numbers arise from dividing by 1e-8.

Mosek reports the problem is infeasible. But it clearly is feasible. Even with the objective removed, Mosek still reports the problem as infeasible.

if the for loop assigning R1, R2, R3 is also removed, then the (feasibility) problem is solved (determined to be feasible). Apparently, even though R1, R2, R3 aren’t used anywhere in the problem if the objective is removed, R1, R2, R3 “stuff” is somehow getting into the problem sent from CVX to Mosek, and then the large numbers in the model are “screwing up” Mosek, resulting in an incorrect infeasibility determination. I have to defer to CVX developer @mcg why that is the case. Apparently CVX is not “smart” enough to see that R1, R2, R3 serve no value when the objective is removed. CVX is apparently including constraints based on them in the problem sent to the solver, even though the constraints are irrrelevant when the objective is omitted.

Finally, i note that R1, R2, R3 are overwritten every time though the for loop. So the objective function is just based on their values the last time through the loop (when i = K). Do you want to delcare R1, R2, R3 as expression holders http://cvxr.com/cvx/doc/basics.html#assignment-and-expression-holders and use R1(i) = …, etc., and then perhaps sum them in the objective?

By decreasing c from 10^{-2} (where it solves nicely) to 10^{-8} you see from the log output that the number of iterations increases, the dual solution norm reported by Mosek grows, violations grow, the entries in the linear constraints grow and the expected value of \tau_0 is closer and closer to 0. So it is not surprising that at some point you hit the numerical accuracy issues.

Note that your problems ultimately contains subexpressions such as 10^{10}\tau_0 in various places. It is hard to expect it to be nicely solvable.