@SUN ZHUOYU I'm not going to look at your followup (or any other Question of yours) if you don't upload and attach your actual worksheets.

It is poor etiquette to expect people to manually enter equivalent code based on mere images and screenshots.

More importantly, your image appears to be an incomplete picture of what was going on. It's not clear what is your actual problem or goal.

At the top of your image, what are x[j] and y1[j] supposed to reference? Is it top secret? If you're trying to programmatically construct points1 then show us the complete original worksheets.

@Andiguys Regarding your followup G1.mw worksheet, your constraint C1 requires that Q2 be at least 9.2e7 for sigma=0..3.

There is no possible feasible sigma,Q2 pair satisfying C1, given your ranges sigma=0..3 and Q2=4.0e5..2e7.

ps. The minimum of TRC(sigma,Q2) for sigma=0..3 would occur at sigma=3 and Q2=9.27e7.

pps. You should construct TRC by,
    TRC := unapply(eval(TC1c, DATA),sigma,Q2);
instead of just unapply(...,sigma), so that you can properly call TRC at a pair of values, to check.

You might find using implicitplot useful. (...which I also did here -- extruded to 3D barrier surfaces -- in earlier answers for an earlier model variant you'd posed. You could also do that here.) This followup is not complicated, but if you have trouble understanding it then plots could only help.

G1_ac.mw

Now, could you explain your difficulty in understanding, when constraint C1 is removed? You have sigma=0..3, and if sigma is not negative then the smallest sigma possible in that range (ie. sigma=0) will attain at the minimum of TRC(sigma,Q2) which is given by,
   1.22675e9 + 2.5*Q2 + 3.8e7*sigma
   +700000000*sigma*(0.02 + 2.285714286e-2*sigma)
and Q3 doesn't preclude sigma=0 for your Q2>=4e5.  Notice that sigma only appears in terms of the sum TRC(sigma,Q2) which each consist of positive coefficients multiplied by mere positive-integer powers of sigma. Without hampering by constraints that sum is clearly minimized over sigma=0..3 at sigma=0.

@JAMET Your code has,

   180 - 180*arctan(alpha)/Pi

instead of,

    180 - 180*alpha/Pi

But the arctan step was already done earlier in your code.

@sand15 I though it might be fun to see how large n could be while obtaining an exact result.

@sand15 How tight are cons_1, at different n? Are they always equality?

Please do not spam other old threads on this forum with duplicates of your request.

There are more edits you could do, but here is a start. I've deliberately left the bulk of your procedure as it is, since that's your (evolving) style.

I used an appliable module, with the helper procs, shortened some calls utilizing the uses stuff, adjusted the textplot alignments a bit, and adjusted some rounding evalf stuff, and allowed extra arguments to triangle be passed to the final plots:-display via _rest.

Download SEC_ac1.mw

nb. Never do evalf[4](...) or evalf(...,4) of a complicated formula., even if it exactly/symbolically represents some constant value. However It's OK to use such a call on an already-computed float value, to get final rounding effects. But you don't want to accidentally make the whole float computation be done at low working precision. If you accidentally do it on a formula then it only uses 4 digits of working precision and that will often lead to a rubbish result due to numeric roundoff, loss-of-precision, catastrophic cancellation, etc. Here are two ways to go wrong, and two ways to get it better:

Download dig_ex.mw

@mmcdara You wrote, "the Statistics:-NonlinearFit solver uses Optimization:-NLPSolve" but that is not true.

The Statistics:-NonlinearFit command calls Optimization:-LSSolve.

I've changed the Product field for this posting from "MapleSim" to "MaplePrimes".

One difference between a Reply and an Answer is that all Replies appear above all Answers, regardless of when they are posted. (You didn't query about it; I mention it because I think that it's an important consideration.)

@C_R You wrote, "Does numcpus=1 remove all logical cores from the computation?"

It should use just one logical core. You can't "remove" them "all", since then there'd be no thread to do any computation.

@SUN ZHUOYU Your original had an attempt with insequence.

But that option makes an animation of the sequnce. You can also use your original, but without using that option.

   display(seq(subs(aa = i, eval(f))(p), i = 1 .. 25))

@Andiguys Please do not post a wholly separate new Question thread for this. It would be flagged as a duplicate then deleted. There is no need for additional separate Question threads for this. (If you want to add a proper description/explanation then do so as a Reply in this very Question.)

You can do,

   R3 := sigma*C*Q1 + nu*C*Q2 + 0.6*C*mu*(Q1 + Q2) + piecewise(mu = 0, 0, Vr*k)

Here that is, with cleanup and removal of clutter and unnecessary steps or operators.

N5_ac.mw

When I get a chance I'll look at putting it into a reusable procedure (with parameters x,y instead of having those fixed in DATA) so that generating the table data is terse and tidy. That may or may not happen some evening in the next week.

@Andiguys Earlier you wrote that,

    Q3 = x*d - delta*(Q1 + Q2)

and now in your N5.mw worksheet you no longer have that strict equality, and you're letting Q3 be an independent parameter (with an allowed range supplied earlier by me; admittedly using related formulae at the lower end).

So is that strict equality for Q3 no longer forced alone (ie. except as possible consequence of the other constraints)?

ps. Why are you including your C5 constraint? What do you think that it's enforcing? (I ask because you don't describe the objective, constraints, and formulas for each model you've shown in all these worksheets. That can make it tricky to distinguish between programming mistakes and conceptual mistakes.)

Since I've been working (on and off) on my own expression compactifier for over a year perhaps I might respectfully offer some suggestions:

a) store the actions foremost (and their results secondarily)
b) have it act recursively (and store results as it goes, using a suitable data structure)
c) use an appliable module, and have the best-result-found-so-far be accessible from some module export after you interrupt the search in mid-computation
d) don't try and make it support assumptions in separate internal method choices. Instead, just allow assuming to be used when you call your tool.
e) allow the length-metric to be passed in optionally (LeafCount is not a bad default, but other choices are `simplify/size/size`, or even `length`, or a weighted value using codegen:-cost
f) allow the action-chain to be optionally the return value, or at least part of it
g) have a default time-limit for it (at least for total operation, and preferably for sub-steps). Allow a user-specified time-limit to be an optional argument.
h) allow custom operations (operators/procedures with single input/output) to be passed as an option and so added to the set of possible actions.
i) allow things like evalc to be toggled on/off as an option. (assumes names are real)
j) don't forget acttions like rationalize, expand, normal, etc.
k) don't forget to try collect, which is often very effective (but brings with it even more choices and combinatorial growth.
l) there can be a benefit to splitting temporarily by numer and denom.
m) allow the same action to appear more than once in the action-chain.
n) don't forget that when using convert you can get quite different effects fro
m each of:
      exp, ln, expln, trig, sincos, arctan, arcsin, abs, signum, radical, etc
o) don't forget simplify(...,radical) and combine(radical), but don't waste time with the symbolic option which can make the result wrong
p) even if you're just trying a blanket approach, the growth in cost due to combinatorial coverage of attempts means that even rudimentary checks to tell when a method ought have no effect can be beneficial.  
q) additional stopping criteria (target form of intermediate result, recursion depth limit, time limit) can make it much more practical to use.

That's probably more than enough for a beginning.

@Andiguys Hopefully I'll be able to look later at your latest model in N4.mw.

Fwiw, the earlier revision (N1) with 3D plot is not at a local minimum of its unconstrained surface. That's why I added the constraints in that plot, to visually show that the optimum found was tight up against some constraints.