@Abdoulaye I don't see a way of going forward with this method.  What is the actual problem that you wish to solve?  Perhaps if you just state the problem, then someone may suggest a different approach to solving it.

@Abdoulaye That's good, but my question still remains. -- g(U) depends on y, and therefore the solution U1((x) of g( U1(x) ) = x is a function of both x and y.  Shouldn't that be written U1(x,y)?

Similarly all Un(x) should be Un(x,y).

You say:

i) We define g( U ) = U + S1( 2*y*exp(-U) )

ii) We find the function U(x) solution of g( U1(x) ) = x

But g(U) depends on y, therefore the solution of g(U) = x will depend on both x and y.  Then it appears that what you call Un(x) should be Un(x,y).  Just wanted to point this out.

@acer I see your point now.  Thanks for the explanation.

@acer You state "I don't see why it's necessary to call expand here", then in your code you replace expand with collect:

collect((rhs-lhs)(eqn),diff)

So yes, expand isn't necessary as long as you use collect in its stead.  But I don't find that particularly noteworthy.  Perhaps I am missing something subtle here.
 

@Joe Riel This should work:
 

selectremove(has, tmp, diff);
%[1]=-%[2];

Edgardo, I can't say that I fully comprehend the complete functionality of casesplit, but what you have shown is certainly instructive and impressive.  Thanks!

I find the casesplit's help page somewhat difficult to digest.  It begins with a longish paragraph focusing on singular solutions and singular systems, which can divert the reader's attention from all other neat things that casesplit does.  Perhaps it will be better to open with a bulleted list of brief (one-line) sentences describing casesplit's various capabilities, and only later go into the details.

I would also suggest to give, as the first example, something very simple, such as:

de1 := diff(x(t),t) = a*x(t) + b*y(t);
de2 := diff(y(t),t) = c*x(t) + d*y(t);
casesplit({de1,de2});

which the casual reader can readily comprehend without much head-scratching.  The more tricky examples can come later.

One more thing: At the very top of the help page we have "casesplit: split into cases and sequentially decouple a system of equations...".  It will be good to replace "equations" with "ordinary or partial differential equations".

Also just below that, where the "sys" parameter is defined, it says "sys: single DE, or list or set of DEs; any system of differential equations".  This can give the false impression that casesplit deals with ODEs only.  It'd be good the change "set of DEs" to "set of ODEs or PDEs" to make it clear that PDEs are included as well.

@Kitonum A more interesting result is obtained with tbas=10.

@Carl Love Ordinarily I would pick the initial guess as you have, but in this case such a choice makes the iteration arrive at the fixed point in a single step.  I picked my initial guess on purpose so that it takes a few iterations to arrive at the fixed point, and thus to illustrate how the iteration works.

As to a "best choice", I don't have a useful answer other than making the obvious point that the "best choice" is the solution itself.  In this problem it would have been u[0](t,x) = 1 + x + t + x*t, which is better than u[0](t,x) = 1 + x.

You ask "how can I iterate this PDE?" but you haven't shown the PDE.  The iterative formula in your worksheet is misformed and ambiguous, making it difficult/impossible to deduce the PDE from it.

Show the PDE.

@Carl Love Yes, you are right.

    Kbt1 and mubt1 are defined as functions but used as if they were expressions.
    Fht1 is defined as an expression but used as if it were a function.

There may be more such errors.

@Paulo Baumbach:  You can make your programming job significantly easier if you write a single statement per execution group.  Ask for explanation if you don't know what an execution group means.

Tom, you are not alone.  I am not receiving notifications either.  Something has stopped working on this website.

@Rouben Rostamian  Come to think of it, that was pretty dumb. The differential equation is linear, and is therefore solvable symbolically.  Why not just plot the symbolic solution?

Download mw.mw

@vv Certainly the u(x,t)=sin(x)*exp(t) solves the backward heat equation exactly.  However it walks a very fine line.  Nearby functions generally evolve quite differently and that becomes a major issue under numerical noise.  Change t=0..1 to t=0..3 in your example to see that. We can hardly say that the result "fully agrees with the exact solution".

@Carl Love Thanks for pointing to the OP= help page.  I had not noticed this extremely helpful addition in Maple2019.