The easiest way to extract the plot is

p := MathematicalFunctions:-Get(plot, Zeta)

Then plottools:-getdata(p[2][1]) extracts data from the plot, or use lprint(p[2][1]) to see the plot structure. As usual right-clicking on this plot can let you see various options, but I'm not aware of anything that can reconstruct the plot command. (Perhaps you were thinking about a plot component for that.)

In this case the plot can be generated by 

plots:-complexplot3d(Zeta(z), z = -4 - 10*I .. 4 + 40*I,
      view = [default, default, 0 .. 3], orientation = [-32, 68]);

though I didn't try to get all options exactly right.

(When I right-clicked on the plot from FunctionAdvisor, Maple disappeared completely, though not reproducibly!)

I found that with one of that OPs worksheets (one I loaded in that thread) with a few second delays each keystroke (not 20 s, and not always), but it did have one large plot and multiple large expressions. In the past I have attributed those delays to working from a remote disk, but that wasn't the case today.

The bottleneck seems to be the evaluation of the large number of exponentials. If I reformulate this as an (almost) polynomial in three variables, then many of the calculations run much faster. For example one of the fsolve's that took 84 minutes now takes 14 s. For the plots I made a procedure but only tested it at low resulution and didn't compare the timing. Unfortunately, in the fsolve calls where T is an output, this method does not work, and I think this is the case you are most interested in.

Campo_Médio_spin_7_2_-_Forum_new.mw

Rouben's answer is fine if you are looking only for real roots, but you seem to think there are complex roots.  Are you sure there are? You have a numerically very difficult function to solve, with your constants varying over many orders of magnitude. Working in symbolic form allowed significant simplification of your expression. I could get Analytic to finish, but it did not find any solutions despite knowing there is a root in the region.

question128.mw

See the comments on the worksheet.

Download solve.mw

Internally 1.23/n^1.65 is represented as 1.23*n^(-1.65), from which the results follow. On the other hand 1.23/n^2 is similarly represented, but numer and denom seem to "try harder" and give the results you expect. That is probably because normal, numer, denom are usually used for ratios of polynomials. On the last hand, 1.23/n^(1/2) works as you expect, so I guess Maple just doesn't want to deal with the floating point exponent. 

This sort of unexpected behaviour is what discourages new Maple users (and me too), so in that sense I would describe it as a bug. I submitted an SCR.

I don't know about a limit, but it's certainly more than two lines. But it can be frustrating copying parts of 2d output in terms of what gets selected. In those cases I just use lprint (that's lowercase L), which provides 1-D output, which can then be pasted into 1-D input (e.g., ctrl-m before you paste.)

For the equations, PolynomialSystem with engine = triade returns quickly. Then you can use allvalues to find numerically all real solutions in the cases with RootOf. I would then check when the inequalities are satisfied using the numerical solutions. I didn't work up all the cases, just one of them.

Download solve_system_of_polynomials_with_inequalities.mw

Download quartic_equation_in_n_2.mw

Unfortunately solve{identity(...),..) doesn't work with two identity variables. dcoeffs isn't useful here since you don't have derivatives. You can use coeffs. I'm assuming you want separate equations for each t^i*x^j combination.

params.mw

Just put the cursor before "b" and hit "backspace". Or just type "a:=10;b:=20;" then move the cursor to just after the first ";" and then hit "shift-enter".

Unfortunately solve{identity(...),..) doesn't work with two identity variables. dcoeffs isn't useful here since you don't have derivatives. You can use coeffs. I'm assuming you want separate equations for each t^i*x^j combination.

params.mw

@C_R has pointed out many of the things I might have mentioned. Here a few more comments along the same lines.

Q1. To me, your formulation uses matrices, but is not very matrixy. That's hard to define and probably largely intuitive on my part. Your matrices are almost all involved in dot products or quadratic forms (a^T.M.x), which produce scalars that you then involve in non-matrix equations. The power of matrices is in setting up matrix equations (I suppose a few vectors are allowed) and solving the matrix equations - often just a linear equation solving of Ax = b, but perhaps AX + XB = C, AXB = C or some nonlinear ones.

Specifically (but vaguely), the entries of r don't look like they have a simple matrix origin - we have square roots of entries, and while the denominators themselves might be matrixy, division is not a matrix thing so the denominators might better be in scalars outside the matrix. For the numerators, there are only diagonal elements of S, so where did the off-diagonals go?

The key point was given by @C_R: "but for that we have to see the structure of the equations in the first place".

Q2. I would say no here. Try to set things up without components, even if later you need to be explicit about them. For example to take a small part of your equations. q[1] = w^T.S.e[1], q[2] = w^T.S.e[2], q[3] = w^T.S.e[3] . So q[1], q[2], q[3] are the first, second and third components of w^T.S, so this is just q^T = w^T.S or q = S^T.w. The w[i]^2 seem to make this type of analysis harder (not matrixy?).

According to the help page, rsolve requires A(n), not A[n]. (But see @acer's answer.)

Download ask_recrusive_sequence_of_A[n].mw

It seems to me that case (I) covers all sign combinations of lambda and mu. Case (II) looks incorrect to me - just putting the negative in doesn't work unless lambda and mu are redefined.

Download dsolve.mw