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.

@nm I'd agree with you that odetest ought to use limit here.

(...and, better to have a duplicate report than none)

@KIRAN SAJJAN I asked how you wanted it laid out, with Gr taking multiple values. You have not answered that.

For example, you could have all the Cf columns together, and all the Nux columns together. Or you could have Cf,Nux in pairs, for each Gr.

@Andiguys 

You don't need the DirectSearch package to get the result I obtained in my previous Reply above. (I already gave you two separate URLs for obtaining it, btw). My use of that package merely confirmed -- even without substituting nu=sigma, etc -- the result I had already obtained without it, in the same worksheet: numerically using Minimize which my worksheet showed, and also symbolically which I didn't show.

Your previous attachment N1.mw contained plot3d call of something that doesn't contain I1 and I2, and the ranges you passed it were for I1 and I2. That doesn't make sense here.

If you have some formula for Q3 -- based on some other fixed parameter values and formulas for Q1,Q2 then why did you attempt to minimize TRC(sigma,nu,Q3) without using any such substitution for Q3?

If I take your formulas present elsewhere in the worksheet for Q1(sigma) and Q2(sigma), and the fixed parameter values present somewhere else in your worksheet, and then use those for a value for Q3, then Minimize succeeds with Digits:=30. In fact the results agree with what I had obtained in my previous worksheet, with Q3 allowed to vary (in a range I deduced from the constraints, with the lower bound the value I actually suspected).

The following attachment makes the various corrections (substituting appropriately for Q3, correcting variables in the plot3d call, use higher Digits): N1_11_acc.mw

Here is the 3D plot, including the TRC surface as well as transparent vertical surfaces for the 2D constraints.

ps. I believe that this would have been simpler if you had provided description of your methodology earlier.

@KIRAN SAJJAN You description is missing necessary important details.

You write that you want eta to go from 0 to 20 (in 1000 steps). You write that you want the results in table, and tried to use a Matrix.

Are you trying to create a Matrix that includes all four Gr values? What's the xi value(s)? How would that be laid out as columns in a Matrix, if either xi or Gr are to have multiple values?

@mmcdara The last time I checked, with utilizes an undocumented internal utility named bind, to rebind the export names. That makes the binding/unbinding of with/unwith work like a stack (FILO, First In Last Out).

@mmcdara 

If a name is an export of more than one loaded package then the effective binding for that name is that of the last one loaded.

Thanks for the color adjustment. I originally had it as you suggest, but later got lazy trying to save a little space... I've corrected the file. The key thing is that such colorings are quite easy.

@Axel Vogt Yes, it produces that form from Maple 16 to Maple 2022.2, but not in Maple 2023.2.1 and Maple 2024.0.

@Ronan You asked about improving the quality, and to my eye it's visually clear that the transformed 3D instance of your 2D plot collection has much better quality than the intersectplot 3D results. That was my main point, about transform.

I added an after-note, as a minor secondary consideration, is all. If you do it right then you can beat implicitplot (which is what I referred to as a hammer, not intersectplot) in terms of both computational time and memory to store the final result. If you end up animating, or manually rotating many larger objects in a GUI plot, then these things can make a difference in performance. That might not make any significant difference to your small example here; I mention it only as a potential going concern. If efficiency is not a concern in this then you can just ignore the whole commentary.

I wrote "line, or even plot with..." before. That does not mean that plot would be my first choice. With line you can construct a small structure quickly. Here's another:

with(plots):
# you might re-use either of these
L := rhs(isolate(-(13*x)/12 - (5*y)/8 + 71/96,y));
xrng := [-3,2];

# I personally don't find this next one too complicated.
# If you have many such L formulas then this could be
# done some with some simple added `seq` action.

pointplot([[xrng[1],eval(L,x=xrng[1])],
           [xrng[2],eval(L,x=xrng[2])]],
           style=line,color=red);

Of course you may well prefer shorter code at the expense of some time and memory. There's nothing wrong with that in your given example.

@Andiguys

I made corrections to your worksheet (and added a couple of plots you requested).

But the optimization approach was what you set up, not me.

Your overall goal is unclear. See my Reply above (May 30) to your original Question, which you still have not answered properly.

To me it seems that you use some names in contradictory ways.

Please put your followup and closely related queries on this here, or Branch from here (there's a button for that right below your Question), instead of spawning a wholly separate new Question thread for it.

A few notes:

Download eval_zero_power.mw

@vv I have reported it. Your last sentence seems to sum it up.

Another case to deal with,

evalc(0^n);
Error, (in type/complex) too many levels of recursion

@Ronan Thanks.

I added a couple of shorter ways to do your given example to the start of my Answer.