@salim-barzani Many commands, such as simplify, work with equations, but some do not (like coeffs here). For this reason, I usually do not have the =0 at the end of everything; then I don't get stuck like this.  Almost all Maple commands, such as solve, dsolve etc interpret an expression without =0 as though the =0 was present. Learn from this.

N-soliton1.mw

@salim-barzani Well, that is what the solve(identity,...) would have given for that set of equations and unknowns if it had worked, so it is the direct answer to your question. It also has nothing to do with the fact that there are two parameters x and t. If it doesn't work for you then you should reformulate the problem into the correct form first.

@janhardo Yikes! DEtools seems to be an old-style table-based package; I thought they had all been upgraded. The workaround would be to use DEtools[DEplot] on the two occasions you need DEtools.

@Hamza Rafiq I think your approach is correct, but I don't know how to complete it.

Download Find_Solution.mw

I see this behaviour on Maple 2024.2 on Windows 11. In fact, after ctrl-alt-delete would get me to the task manager, clicking on java to select it to kill just sent me back to the frozen Maple screen - I had to do a hardware stop of my computer. 

Since I usually start Maple by double-clicking on a preexisting workheet or using recent documents, it's hard for me so say when this started, by 2-3 weeks ago seems about right.

Great detective work on the left panel!

intersectcurves from the algcurves package can do this. In this simple case one doesn't learn much more than directly using solve, but for more complicated cases it may be useful.

Download intersectcurves.mw

I don't have MapleFlow, but frequently have the same problem in Maple. The only solution I know of is to attempt to exit the program via the window's X button. Then you are given the option to save (yes/no/cancel). Sometimes cancel will get you back to a working state, but saving and then restarting from the OS will work.

This actually finds the solution.

Download solution.mw

@vv I was careful to say "that the elimination process does not lead to any valid solutions", not that there are no solutions. Is there another way to get such a solution or did I (or Maple) make a mistake in the step-by-step elimination? 

Edit: I see it is among the solutions to 

SolveTools:-PolynomialSystem(expr2)

@selaf @Preben Alsholm's answer works also for this case:

f ≔ x -> local j; seq(x, j=1..5);

As Preben said, this only works for 1-D input. If you try this with 2D input, you get an "invalid arrow procedure" error.

@JAMET 

EllipseAnimation.mw

@Saalehorizontale So in terms of your concerns, I guess the conclusion is RegularChains (and Groebner) are reliable in terms of finding all solutions. RegularChains is the modern way to do it, but is hard to understand. Notice that engine = triade in PolynomialSysyems uses RegularChains but then does the work of outputting the solutions in nice form. @John May suggested earlier SolveTools:-SemiAlgebraic but it was too slow. It also uses RegularChains, but returns an easier-to-understand format. The secret may be to find a good variable ordering.

So using RegularChains to find the variable order, and then SolveTools:-SemiAlgebraic to express the solution in a nice form is a possibilty. Trying this worked and gave one solution. (I reversed the variable order in case an elimination order was required.) So I'm worried that it missed some solutions. I would suggest trying some much smaller systems where you know the exact number of solutions to make sure it is working the way you expect.

RegularChains.mw

@philroe Yes, sort should work on anything; try it on your examples or upload your worksheet if it doesn't seem to be working.

@C_R Nice.

The large y values that don't give reality seem to correspond to the same values of m and m2, but these are supposed to be in different ranges, so something not quite right there. I'm not sure about how those ranges were chosen; I do not fully understand the physics.

I agree with your approach with x as a parameter (or we could try z). The exponents are no longer integers, which makes it a much harder problem than before. It think we are close to a phase transition (at d=3?), in which by definition (in an infinite system) the solution is non-analytic/has a singularity. So we expect it to be numerically very difficult. Perhap your sequence of x values found the phase transition, Perhaps it can be approached from the other side and goes crazy at the same point.

@C_R @Gabriel Barcellos @one man I made some progress in analyzing the expressions and squeezed another 50% efficiency out of the some of the earlier parts of the worksheet. I still intend to tackle the more difficult case of solving the three equations for T. Some observations that are speculative at the moment:

1. I think my efficiencies largely arise from efficient evaluation of multivariate polynomials in Maple, and once you go to another form you lose efficiency.

2. Perhaps related to the previous point, making a function with unapply or makeproc leads to much, much slower evaluations.

3. The efficiency of fsolve depends significantly on how the equations are presented - expression or functions. This is more than just efficiency of evaluations, because in all 3 cases I tried, fsolve uses the same method and the same internal initial guess, but the estimated errors and the number of iterations changes a lot. 

@C_R asked about the physics. There are 8 spins on the vertices of a cube, each of which can take on 8 spin states (those in S0). Z0 is the partition function, the sum of the exp() expressions, one for each of the 8^8 states (possible arrangements). m is the resulting magnetization. I'm not clear on the meaning of the requirements at the end, where T is solved for for close values of d.

Campo_Médio_spin_7_2_new5MP.mw