Question about entry-wise product of general plant and weighting function matrix using Hinfstruct for multi-objective design

Question

Xin jin 2025-7-19

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2178586-question-about-entry-wise-product-of-general-plant-and-weighting-function-matrix-using-hinfstruct-fo

编辑： Paul 2025-7-23

When I obtained the transfer matrix T from exogenous input w to real (unweighted) output z, entrywise product of matrix T and weighted transfer function matrix W is expected to be calculated and optimized. I use connect command to obtain T, which is a 4*2 transfer function matrix with adjustable parameters, reflecting the tranfer relation from input w=[Pref, wg]' to output z=[Pref-p, p, wu, q+V/Dq]'. W is a constant transfer function matrix. Direct entrywise product of T and W cannot be implemented with MATLAB. As mentioned in P. Apkarian's paper "Structured Hinfinity Synthesis in MATLAB", it should be formulated as Standard Form like H=blkdiag(Tij*Wij), then "Hinfstruct" can be used on H to find the tuned controllers. So I use the command like this:

        H=blkdiag(T(1,1)*W11, T(1,2)*W12, T(2,1)*W21, T(2,2)*W22, T(3,1)*W31, T(3,2)*W32, T(4,1)*W41, T(4,2)*W42);
         T = hinfstruct(H,opt);

However, above code cannot get the correct results. The reason I think should be the increased system order. For example, original system T has only 12 states. But system H has 103 states, where 7 states are from weighting fucntions, and the remaining 96 states are the 8 repeated states of system T, that is, 12*8=96.

Take a more realistic case with official Matlab's "hinfstruct" example as follows. The goal is to minimize the H-infinity norm from [r, nw]' to [y, ew]'. An important difference is that there is no entrywise product of Tij and Wij. It means the goal is to minimize 4 transfer functions: T(y,r), T(y,nw), T(ew,r), T(ew,nw).

The official command is given as follows, which works well:

         T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});
         T = hinfstruct(T0);

If I want to formulate the above 4 optimization goals T(y,r), T(y,nw), T(ew,r), T(ew,nw) into Standard From (diagnol form), I revise the above code as follows:

         T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});
         T0_revised = blkdiag(T0(1,1),T0(1,2),T0(2,1),T0(2,2));
         T = hinfstruct(T0_revised);

It also cannot operate correctly. Only revise it as follows can work:

         T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});
         T0_revised=blkdiag(1,LS)*T0*blkdiag(1,1/LS);
         T = hinfstruct(T0_revised,opt);

But it is still not the entry-wise product case, just the traditonal single transfer function connection as shown in the above figure.

Therefore, could you share your idea about this solution then I can learn based on it, and further do more improvement. I am looking forward to your reply. Thanks a lot for your help!

7 个评论
显示 5更早的评论隐藏 5更早的评论

Paul 2025-7-19

在 MATLAB Online 中打开

hinfstruct_demo.mat

Hi Xin jin,

"It also cannot operate correctly."

Please add more detail as to what is incorrect. Do you just mean that the closed-loop response is unsatisfactory?

The following uses the example from the documentation. All plots are at the end.

load hinfstruct_demo G
C0 = tunablePID('C','pi');
a = realp('a',1); 
F0 = tf(a,[1 a]);
wc = 1000;  % target crossover
s = tf('s');
LS = (1+0.001*s/wc)/(0.001+s/wc);
% Label the block I/Os
Wn = 1/LS;  Wn.u = 'nw';  Wn.y = 'n';
We = LS;    We.u = 'e';   We.y = 'ew';
C0.u = 'e';   C0.y = 'u';
F0.u = 'yn';  F0.y = 'yf';
% Specify summing junctions
Sum1 = sumblk('e = r - yf');
Sum2 = sumblk('yn = y + n');
% Connect the blocks together
T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});

Case 1: The same as in the documentation

opt = hinfstructOptions('Display','final','RandomStart',5);
rng('default')
syscl{1} = helper(T0,opt,G,F0);
Final: Peak gain = 3.88, Iterations = 67
Final: Peak gain = 597, Iterations = 181
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 597, Iterations = 170
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 1.56, Iterations = 97
Final: Peak gain = 1.56, Iterations = 102
Final: Peak gain = 1.56, Iterations = 95

Case 2: Consider just the off-diagonal terms. I thought that this approach would more directly achieve the design goals on the loop transfer function, but the results are unsatisfactory. I confess that I don't understand these results, but I will be thinking about it.

rng('default')
syscl{2} = helper(blkdiag(T0(2,1),T0(1,2)),opt,G,F0);
Final: Peak gain = 28.9, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 30.1, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 29.3, Iterations = 34
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.3, Iterations = 41
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.3, Iterations = 31
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.7, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)

Case 3: Consider all four transfer functions T individually. This is not the same as Case 1, but seems to be in line with what you're thinking about.

rng('default')
syscl{3} = helper(blkdiag(T0(1,1),T0(1,2),T0(2,1),T0(2,2)),opt,G,F0);
Final: Peak gain = 3.55, Iterations = 62
Final: Peak gain = 92.9, Iterations = 53
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 594, Iterations = 169
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 3.55, Iterations = 61
Final: Peak gain = 1.01, Iterations = 96
Final: Peak gain = 1.01, Iterations = 89
Warning: Some input or output names are repeated.
Warning: Some input or output names are repeated.

Case 4: Your alternative approach. I don't understand what this approach is attempting to achieve, because LS is already wrapped up in Wn and We.

rng('default')

syscl{4} = helper(blkdiag(1,LS)*connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'})*blkdiag(1,1/LS),opt,G,F0);

Final: Peak gain = 12.2, Iterations = 155 Final: Peak gain = 726, Iterations = 111 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 726, Iterations = 109 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 12.2, Iterations = 113 Final: Peak gain = 551, Iterations = 62 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 551, Iterations = 64

cellfun(@(sys) stepplot(axes(figure),sys),syscl)

function syscl = helper(T0,opt,G,F0)

T = hinfstruct(T0,opt);

C = getBlockValue(T,'C');

F = getValue(F0,T.Blocks); % Propagate tuned parameters from T to F

syscl = feedback(G*C,F);

end

Xin jin 2025-7-19

Dear Paul,

Thanks for your response.

With the traditional hinfinity design, the transfer functions from all the inputs to a particular output share the same weighting function, which is not a suitable setting for the multi-objective design. My goal is to conduct a entry-wise product of general model T (from input w to unweighted output z) and weighting function matrix W, where T and W have the same dimension 4*2, and then operate hinfstruct on the resulting system H=T∘W. For example, this algorithm is used in these two papers.

H∞-Control of Grid-Connected Converters: Design, Objectives and Decentralized Stability Certificates.

2. Generalized Multivariable Grid-Forming Control Design for Power Converters.

I found that this goal should be formulated in Standard Form shown in P. Apkarian's paper "Structured Hinfinity Synthesis in MATLAB". Standard Form is a diagonal form like H=blkdiag(Tij*Wij). The following is a simple case from this paper. The goal is to minimize three transfer function T1*W1, T2*W2, T3*W3.

T1(s) is the closed-loop transfer function from Nzc to e;

T2(s) is the closed-loop transfer from the noise inputs nNz , nq to the control signal δm;

T3(s) is the closed-loop transfer from w to δm.

Clearly, you can see that the output of T2(s) and T3(s) are both δm, but the penalized weighting function W2 is not equal to W3, which means the entry-wise product is needed. This cannot be realized using traditional Hinfnity design like hinfsyn. So the author uses hinfstruct and gives the code like this:

H0=blkdiag(W1*lft(P1,C),W2*lft(P2,C),W3*lft(P3,C));[H,gam] = hinfstruct(H0);

where P1, P2 and P3 are obtained using linlft by exclude tunable elements.

Based on this, I want to use the Matlab example presented before to validate this algorithm, and then do my own design. Because there is no need to conduct entry-wise product in this case, that is, the minimization goal is 2*2 transfer function matrix, including 4 elements: T(y,r), T(y,nw), T(ew,r), T(ew,nw). The official code is using connect to directly compute the transfer function matrix from (r, nw) to (y, ew). It is definitely reasonable. However, if I want to use the diagonal form to do the optimization, it should be also reasonable, since no entry-wise product case is only a special case of entry-wise product case. However, just as you have shown, the results with diagonal form is not the same as the official results by Matlab.

So what I am concerned is that how to do the entry-wise product between general transfer function and weighting function matrix, and further operate hinfstruct design. Hope above clearly demonstrate my question, and thanks again for your time and support.

Paul 2025-7-19

在 MATLAB Online 中打开

hinfstruct_demo.mat

Continuing with the assessment of hinfstruct ...

load hinfstruct_demo G
C0 = tunablePID('C','pi');
a = realp('a',1); 
F0 = tf(a,[1 a]);
wc = 1000;  % target crossover
s = tf('s');
LS = (1+0.001*s/wc)/(0.001+s/wc);
% Label the block I/Os
Wn = 1/LS;  Wn.u = 'nw';  Wn.y = 'n';
We = LS;    We.u = 'e';   We.y = 'ew';
C0.u = 'e';   C0.y = 'u';
F0.u = 'yn';  F0.y = 'yf';
% Specify summing junctions
Sum1 = sumblk('e = r - yf');
Sum2 = sumblk('yn = y + n');
% Connect the blocks together
T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});

Case 1: The same as in the documentation

opt = hinfstructOptions('Display','final','RandomStart',5);
rng('default')
[syscl{1},T1,sysol] = helper(T0,opt,G,F0);
Final: Peak gain = 3.88, Iterations = 67
Final: Peak gain = 597, Iterations = 181
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 597, Iterations = 170
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 1.56, Iterations = 97
Final: Peak gain = 1.56, Iterations = 102
Final: Peak gain = 1.56, Iterations = 95

Plotting the closed-loop transfer functions from r to e and n to y with the (inverse) weights clearly shows how the optimizer yields a controller that shapes these two closed-loop transfer functions in the low and high frequency ranges respectively.

figure

bodemag(feedback(1,sysol),inv(We),feedback(sysol,1),inv(Wn),{1e-2,1e7})

Case 2: Use only the off-diagonal terms.

rng('default')
[syscl{2},~,sysol] = helper(blkdiag(T0(2,1),T0(1,2)),opt,G,F0);
Final: Peak gain = 28.9, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 30.1, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 29.3, Iterations = 34
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.3, Iterations = 41
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.3, Iterations = 31
       Some closed-loop poles are marginally stable (decay rate near 1e-07)
Final: Peak gain = 28.7, Iterations = 32
       Some closed-loop poles are marginally stable (decay rate near 1e-07)

However, doing the same in this case indicates a good controller isn't found, even though one would think it could find the controller from Case 1.

figure

bodemag(feedback(1,sysol),inv(We),feedback(sysol,1),inv(Wn),{1e-2,1e7})

Case 3: Let's try Case 2 again, but initialize starting from the controller from Case 1

rng('default')

[syscl{3},~,sysol] = helper(blkdiag(T1(2,1),T1(1,2)),opt,G,F0);

Final: Peak gain = 1.01, Iterations = 28 Final: Peak gain = 1.01, Iterations = 46 Final: Peak gain = 1.01, Iterations = 55 Final: Peak gain = 1.01, Iterations = 47 Final: Peak gain = 1.01, Iterations = 45 Final: Peak gain = 1.01, Iterations = 39

figure

bodemag(feedback(1,sysol),inv(We),feedback(sysol,1),inv(Wn),{1e-2,1e7})

That worked much better! I wonder why hinfstruct did not work well from random initial conditions for Case 2, when it could for Case 1.

Case 4:

A concern I have with the example in the doc is that T(1,1) is the transfer function from r to y, i.e., not weighted. As the optimizer improves the solution, it will drive the low frequency gain of T(1,1) to unity. At some point, the optimizer will reach the point that it's cost is dominated by this effect and therefore will take no other step to improve performance in other frequency bands. I think that's why the Peak Gain for Case 1 is 1.56 but in Case 3 was driven down to 1.01.

As an alternative, I think the loop shaping requirements of this problem can be achieved by not introducing the artificial noise input, N(s), and instead applying Wy(s) (= Wn(s)) to the output of F(s).

Wyf = Wn;

Wyf.InputName = F0.OutputName;

Wyf.OutputName = 'yfw';

T0 = connect(G,Wyf,We,C0,F0,Sum1,Sum2,{'r'},{'yfw','ew'});

Warning: The following block inputs are not used: n.

rng('default')

[syscl{4},~,sysol] = helper(T0,opt,G,F0);

Final: Peak gain = 29.4, Iterations = 30 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 30.7, Iterations = 32 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.9, Iterations = 31 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.1, Iterations = 35 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29, Iterations = 32 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.2, Iterations = 35 Some closed-loop poles are marginally stable (decay rate near 1e-07)

figure

bodemag(feedback(1,sysol),inv(We),feedback(sysol,1),inv(Wyf),{1e-2,1e7})

That's no good. Let's try initialzing from the Case 1 solution

Case 5:

rng('default')

[syscl{5},~,sysol] = helper(setBlockValue(setBlockValue(T0,'C',getBlockValue(T1,'C')),'F0',getValue(F0,T1.Blocks)),opt,G,F0);

Final: Peak gain = 1.15, Iterations = 113 Final: Peak gain = 30.7, Iterations = 32 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.9, Iterations = 31 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.1, Iterations = 35 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29, Iterations = 32 Some closed-loop poles are marginally stable (decay rate near 1e-07) Final: Peak gain = 29.2, Iterations = 35 Some closed-loop poles are marginally stable (decay rate near 1e-07)

figure

bodemag(feedback(1,sysol),inv(We),feedback(sysol,1),inv(Wyf),{1e-2,1e7})

Compare step responses

figure

step(syscl{[1,3,5]});legend('Case 1','Case 3','Case 5')

I think these results make sense considering what's being optimized, and what might constraining the optimization, for these three cases.

Perhaps @Pascal Gahinet can comment on why hinfstruct has trouble with Case 2 and Case 4 starting from random conditions and how one might remediate that problem if a good controller solution is not readily available as an initial condition.

A comment on why the doc example formulated the problem such that T(1,1) = Y(s)/R(s) (unweighted) would also be welcome.

function [syscl,T,sysol] = helper(T0,opt,G,F0)
T = hinfstruct(T0,opt);
C = getBlockValue(T,'C');
F = getValue(F0,T.Blocks);  % Propagate tuned parameters from T to F
syscl = feedback(G*C,F);
sysol = G*C*F;
end

Xin jin 2025-7-20

在 MATLAB Online 中打开

Dear Paul,

Thanks for the rearrangement of my question.

Standard Form is presented in the paper "Structured Hinfinity Synthesis in MATLAB" (this paper is written by Pascal Gahinet) as a general form to foumulate any optimization problem when using hinfstruct, whether this is a need of entry-wise product between general plant and weighting function matrix. In other words, Standard From definitely should be applicable to the Matlab official example. However, when I put these four minimization problems separately with Standard Form using blkdiag as follows:

         T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});
         T0_revised = blkdiag(T0(1,1),T0(1,2),T0(2,1),T0(2,2));
         T = hinfstruct(T0_revised);

The result is as you presented in Case 2, where the peak gain is 1.01 and it is not the same as 1.56 when using traditional way. Only when the following formulation can make the same result:

         T0 = connect(G,Wn,We,C0,F0,Sum1,Sum2,{'r','nw'},{'y','ew'});
         T0_revised=blkdiag(1,LS)*T0*blkdiag(1,1/LS);
         T = hinfstruct(T0_revised,opt);

Obviously, the above two formulation deal with the same four minimization tasks: T(y,r), T(y,nw), T(ew,r), T(ew,nw). But the former using Standard Form cannot get the same results of 1.56. And my own research task should include entry-wise product of general plant and weighting function matrix, which cannot be realized with the latter form. This is why I want to get the correct results with Standard Form for the Matlab example. Only in this way can I then use the correct formulation to solve my own research problem.

Thanks again for your consideration.

Paul 2025-7-20

编辑：Paul 2025-7-23

在 MATLAB Online 中打开

hinfstruct_demo.mat

I'm afraid I can't be of much more help until I see the complete code that you're running that illustrates the results that your getting. To do this you can

a. include the .mat file I've been using by clicking the paperclip icon on the Insert strip and then click "Link from this thread" and then click "Submit".

b. start a code block and make the first line to load that .mat file

c. copy/paste the rest of your code that illustrates all of the cases of interest

d. Click the green triangle in the Run strip to run the code

e. Add comments or text to explain what you're concerns are.

If you don't want to show the full code, then I can't be of any more help.

I can offer a few general comments.

The term "Standard Form" in the linked paper is just a way to describe and formulate any model that includes tunable parameters (actually the paper uses "Standard Form" in two different ways, but that's not relevant to this discussion). T0 and T0_revised (created with blkdiag) are both formulated and stored in Standard Form by the software.

There may also be some confusion with respect to notation. In the Matlab doc, the frequency-weighted transfer function matrix is denoted by T (or T_0), whereas in the paper T refers to the unweighted transfer function matrix and H refers the frequency-weighted matrix (e.g., eqn (18)). In what follows, I'm going to use the terminology in the paper; I hope that's not too confusing.

Let's first build T(s), the unweighted plant model

load hinfstruct_demo G
C0 = tunablePID('C','pi');
a = realp('a',1); 
F0 = tf(a,[1 a]);
wc = 1000;  % target crossover
s = tf('s');
LS = (1+0.001*s/wc)/(0.001+s/wc);
% Label the block I/Os
Wn = 1/LS;  Wn.u = 'nw';  Wn.y = 'n';
We = LS;    We.u = 'e';   We.y = 'ew';
C0.u = 'e';   C0.y = 'u';
F0.u = 'yn';  F0.y = 'yf';
% Specify summing junctions
Sum1 = sumblk('e = r - yf');
Sum2 = sumblk('yn = y + n');
% Connect the blocks together
T = connect(G,C0,F0,Sum1,Sum2,{'r','n'},{'y','e'});

The example in the documentation chooses to formulate the optimization problem by multiplying n and e by the weights, like so

H1 = connect(T,Wn,We,{'r','nw'},{'y','ew'});

H1(s) is mathematically equivalent to

H1eq = blkdiag(1,We)*T*blkdiag(1,Wn);

H1(s) is a 2x2 matrix composed of H1(y,r), H1(y,nw), H1(ew,r), H1(ew,nw). H1(s) is stored by the software in Standard Form.

hinfstruct(H1) will attempt to find the controller parameters that minimize the inf-norm of the 2x2 H1(s).

An alternative approach would be to form H2(s) as a 4x4 diagonal matrix consisting of the elements of H1(s)

H2 = blkdiag(H1(1,1),H1(1,2),H1(2,1),H1(2,2));

H2(s) is a 4x4, diagonal matrix composed of H1(y,r), H1(y,nw), H1(ew,r), H1(ew,nw). H2(s) is stored by the software in Standard Form.

In accordance with eqn(18) in the paper, a mathematically equivalent way to form H2 would be

H2eq = blkdiag(T(1,1),T(1,2)*Wn,We*T(2,1),We*T(2,2)*Wn);

hinfstruct(H2) will attempt to find the controller parameters that minimize the inf-norm of the 4x4 H2(s), and the solution will be different than for H1(s) because H1(s) ~= H2(s).

It sounds like what you want to do would be to define four freqency dependenent weights and apply them to each element of T(s). I don't know what they are, so I'll just define them arbitrarily

[W11,W12,W21,W22] = deal(tf(10,[1 10]));

Then we can define H3(s) in accordance with eqn (18)

H3 = blkdiag(W11*T(1,1),W12*T(1,2),W21*T(2,1),W22*T(2,2));

H3(s) is a 4x4 matrix stored in Standard Form.

hinfstruct(H3) will attempt to find the controller parameters that minimize the inf-norm of the 4x4 H3(s), which will be a different solution than for H2(s) and H1(s).

We've shown three different ways to formulate the optimization that should yield three different controllers. Whether you want to use any of these three formulation or any other formulation depends on how you want to specify the design goals and the cost that should be optimized.

The third formulation is the same as was stated at the outset of the original question:

 H=blkdiag(T(1,1)*W11, T(1,2)*W12, T(2,1)*W21, T(2,2)*W22, T(3,1)*W31, T(3,2)*W32, T(4,1)*W41, T(4,2)*W42);
 T = hinfstruct(H,opt);

"However, above code cannot get the correct results."

So I guess we've come full circle, and can't get much further without knowing more about what's not correct about the results and how T and Wij are formed. Assuming that H(s) is defined such that we'd expect that a well-performing compensator could be obtained, then all we've seen in this thread is that the ability of hinfstruct to find such a compensator may be dependent on the nominal compensator that's built into T(s).

Xin jin 2025-7-21

在 MATLAB Online 中打开

Dear Paul,

Thanks a lot for your detailed response.

Yes my question is just as you declared. I want to conduct entry-wise product of general unweighted plant (like T as you mentioned) and weighting fucntion matrix (like W), and further design the controller with hinfstruct, just like H3 you given:

H3 = blkdiag(W11*T(1,1),W12*T(1,2),W21*T(2,1),W22*T(2,2));
Unrecognized function or variable 'W11'.

Therefore, take the Matlab official example, I use diagonal form H2 as H1's replacement since I thought H2 is totally the same as H1 for hinfstruct optimization (both H1 and H2 include four elements of transfer relation (y,r), (y,nw), (ew,r), (ew,nw).

H1 = connect(T,Wn,We,{'r','nw'},{'y','ew'});
H2 = blkdiag(H1(1,1),H1(1,2),H1(2,1),H1(2,2));

But as you said, H2 is acctually not the same as H1. So the different result obtained with H2 is reasonable.

Now, specifically for the Matlab official case, how should I write the code using hinfstruct if I want to optimize H, which is supposed to be the entry-wise product of T and W, that is: H=[T(1,1)*W11 T(1,2)*W12;T(2,1)*W21 T(2,2)*W22].

What I am concerned is that the order of H would increase and the optimization process would be slow if using the type of H3.

H3 = blkdiag(W11*T(1,1),W12*T(1,2),W21*T(2,1),W22*T(2,2));

For example, suppose T has x states and W has y states, then H would have (4*x+y) states and the optimization will take a long time. Is this reasonable？

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Paul 2025-7-22

在 MATLAB Online 中打开

hinfstruct_demo.mat

Continuing the discussion from this comment ....

To use hinfstruct using the entrywise multiplicaiton of T(s) and W(s), it seems that H(s) would be exactly as you've shown.

load hinfstruct_demo
C0 = tunablePID('C','pi');
a = realp('a',1); 
F0 = tf(a,[1 a]);
C0.u = 'e';   C0.y = 'u';
F0.u = 'yn';  F0.y = 'yf';
% Specify summing junctions
Sum1 = sumblk('e = r - yf');
Sum2 = sumblk('yn = y + n');
% Connect the blocks together
T = connect(G,C0,F0,Sum1,Sum2,{'r','n'},{'y','e'});
size(T)
Generalized state-space model with 2 outputs, 2 inputs, 11 states, and 3 blocks.

Define W(s). I'll just make something up

W = [tf(1,[1 1]),tf(1,[1 2]);tf(1,[1 3]),tf(1,[1 4])];
H2 = [T(1,1)*W(1,1), T(1,2)*W(1,2);T(2,1)*W(2,1),T(2,2)*W(2,2)];

H2(s) is state-space realization with 48 states of our 2x2 transfer function matrix

size(H2)
Generalized state-space model with 2 outputs, 2 inputs, 48 states, and 12 blocks.

Forming H3 in the block diagonal format

H3 = blkdiag(T(1,1)*W(1,1), T(1,2)*W(1,2), T(2,1)*W(2,1), T(2,2)*W(2,2));

H3(s) is state-space realization with 48 states of our 4x4 (diagonal) transfer function matrix

size(H3)
Generalized state-space model with 4 outputs, 4 inputs, 48 states, and 12 blocks.

H2 and H3 have the same number of states, though it does appear that the frequency response of H2(s) can be computed a bit faster.

w = logspace(-2,7,5000);
timeit(@()freqresp(H2,w))
ans = 0.0450
timeit(@()freqresp(H3,w))
ans = 0.0510

I have no idea as to how the runtime of hinfstruct is impacted by the speed of computing H(jw).

More important is if minimizing the H-infinity norm of H2(s) or H3(s) is consistent with your engineering design goals. That decision should be the primary factor in deciding which approach to use.

Depending on the structure of T(s) and W(s), some efficiency might be gained by removing states by using minreal on T(s), or separately on Tij(s) in the construction of H(s), or on H(s) itself. However, minimal realization can be a tricky business and it's important to have good insight into the problem to know whether or not minreal is doing what it should or shouldn't. One can also compare frequency responses before and after minreal to make sure that non-minimal dynamics were not incorrectly removed.

If you're willing to give up some accuracy, then you can always look into Model Order Reduction techniques that may be applicable to T(s) and/or H(s) and then design the controller for the reduced order model. However, I don't really know if any of those techniques can be directly applied to a genss model, as is T(s) and H(s). It may be possible to break out the nominal portion of the genss model, reduce that, and then reform a lower order genss model. You'll have to check all of this yourself if you think you might want to go down that path. Having said that, one of the selling points of hinfstruct is that it removes the need to design controllers based on reduced order models, which is much more of a consideration using the classical H-infinity design approach implemented by hinfsyn. I'm only mentioning model order reduction for completeness; I'd only consider it as a last resort when using hinfstruct, if at all.

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

Question about entry-wise product of general plant and weighting function matrix using Hinfstruct for multi-objective design

7 个评论
显示 5更早的评论隐藏 5更早的评论

回答（1 个）

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

Question about entry-wise product of general plant and weighting function matrix using Hinfstruct for multi-objective design

7 个评论 显示 5更早的评论隐藏 5更早的评论

回答（1 个）

0 个评论 显示 -2更早的评论隐藏 -2更早的评论

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

7 个评论
显示 5更早的评论隐藏 5更早的评论

0 个评论
显示 -2更早的评论隐藏 -2更早的评论