@vv 

This is why I titled my reply "a few funny things": I had no claim to give a definitive solution :-)

You write " sqrt(b)/b = 1/sqrt(b)  is valid  for any complex (nonzero) b."  ... sure, what was I thinking? :-(

A few funny things ...

six=b.mw

@Rouben Rostamian   @vv

Dear Rouben, 
This question has already been asked, and partially adressed two days ago.

vv did a lot of work on the subject and pointed that the solution returned by pdsolve (of course an infinite serie) didn't seem to verify all the BCs; a point I confirmed.
I suggested to modify the original problem by writtin u = v + phi where phi was a function that verifies the BCs: then v is the solution of a Poisson problem with homogenous Dirichlet BCs.
vv answered that pdsolve, applied on this "v-problem" then seemed to return the correct answer.

Your approach is interesting and is related to some method to build the Green function of the laplacian over the unit square.

I was too lazzy to do the full developments and I used directly the series representation of this Green function.
I have thought to send this modest contribution to the thread of the initial question.
Maybe you will be more interested by it? So you can give a look to the attached file.

GreenFunction.mw

PS: you wrote "I will solve the PDE in the domain .  Solving in a general rectangular domain is no more difficult" ... in the reference given in the attached file you will find how to solve the PDE in a rectangular domain of arbitrary length and width.

 

@vv 

Happy to hear that; thank you for your time.

BTW: Do you think I should submit a question to ask why pdsolve doesn't work with the versions I use ?


 

@vv 

Hi again, 

I have tried to solve the PDE system with Maple 2015.2 and 2016.1 (OS X El Capitan or Sierra): pdsolve([PDE,BCs]) never returns a solution and the output remains dumb.
I think I will submit a question about that, but my request is a different one.

It's about the BCs that are not verified in the original problem.
Maybe this trick could circumvent this problem (but I can't verify this):

1. Let phi(x,y) a function that verifies the 4 BCs: a trivial example is phi(x,y)=x*y*(1-y)
   The laplacian L(phi) of phi is L(phi) = -2*x
2. Write u(x,y) = v(x,y) + phi(y)
   Then v(x,y) is a function equal to 0 on the boundary of the unit square.
   Moreover L(v) = L(u) - L(phi) = 6*x*y*(1-y) + 2*x^3 + 2*x

Does MAPLE solve correctly the following problem ?
PDE := diff(v(x, y), x, x)+diff(v(x, y), y, y)-6*x*y*(1-y)-2*x^3-2*x;
BCs := u(0, y) = 0, u(1, y) = 0, u(x, 0) = 0, u(x, 1) = 0;

If

@vv 

Hi vv, 

I tried to check the BCs by hand.
I think you're right when saying "that [not all] the BCs are [not] verified" :

• u(0,y)=u(x,0) are both satisfied
• u(1,y)=y*(1-y) is not (MAPLE can do a little bit more than what you did (s8:=eval(sol, infinity=8);) in your first reply
• u(x,1)=0 is not satisfied (and here I used your "infinity=8" trick)

Hope it will help.


By the way : I use Maple 2015.2 (OS X El Capitan) and pdsolve dosn(t work properly ... but it is not the point here


info.mw

@Kitonum 

You're right, I should have paid more attention to the help pages

thanks, have a good day

@Kitonum 

I had never thought that the syntax "seq(..., k=L)" could work correctly when L is a list or a set....
... (I always use "seq(..., k in L)")

Same thing for {$1..N} which I always write {$(1..N)}

Are seq(..., k=L) and {$1..N} some kind of "undocumented features" or are they really correct expressions ?


 

@daljit97 
subs(n1=xi*n2, R) means "I replace each occurrence of n1 by the product xi*n2"
This is a simple way to parameterize R in terms of the ratio xi=n1/n2.

simplify(...) is a "comfort" command to see the result of subs(... ) in a smarter way: you can type subs(n1=xi*n2, R); to see the difference.

plot(%, ...) means "plot the previous result": this is meaning of "%" (you have also %% to refer to the penultimate result, and even %%%). Search for "%" in the help pages for more informations

Probably something like 
Z := subs(n1=xi*n2 R);
plot(Z, xi=-1..2, labels=[n1/n2, 'R']);

would have been less weird, apologies

@Muhammad Usman 

Find attached the correct answer

Sorry.mw

@fff97 
So how did you write a:=a+1 (as you said) if you don't have Maple ?
More of this, if if you had written exactly a:=a+1 instead of (a=a+1) as I told you, you wouldn't have got any error.
Just before saying it doesn't work, be sure you write the things correctly.

About the file: forget it, because you don't have Maple

@fff97 
Have tou read the file in my answer ?

@m_magooda 

You write " is it that hard with only couple of power 4 terms?" 
You have 4 root for a 4th order equation (and then potentially 16 roots for a pair of 4th order llinked equations).
Look to the file above to get an idea of what the solution looks like
4th_order.mw

Now open this next file.
The command CodeTools:-Usage(...) returns the times and memory used by the operation between the parentheses
Replace A[1]: by A[1]; and obseve the solution in the elementary case of a 9x9 linear system. (m=1)

Just after there is an ettempt to solve the same problem with m=2.
Advheat-ex54.mw
I'm a patient man but I stopped the execution after waiting more than 15 minutes to get a solution ...

So just try to imagine what it is if m=4 (your radiative condition).

I don't understand what you are looking for ?
Do you want to solve a heat equation ? Numerically or symbolically ?
Do you want to build your own finite differences scheme ?
Is it of pedagological purposes: maybe you want to show the role of DeltaX and DeltaY ?

Depending on your very purpose MAPLE can (or cannot) propose you some procedures to reach it.
 

@Preben Alsholm 

You gave the answer while I was responding to Carl.
I totally agree when you write "I prefer keeping things separate"

Thanks for the clarification

@Carl Love 
I cannot see either !
The fact is that I began using pdsolve but it returned a partially explicit solution (soem intergrals where present).
The solution returned by dsolve had the form {psi__1, psi__2}, [ { psi__1, psi__2} , {psi__1, psi__2} ] (which seems odd).

Now, where does "dsolve" come from ???
In the worksheet I tried some other stuff and, at some time, I did a copy-paste of the pdsolve(...) command into a new line ... and I ommited to take the letter "p". It is as silly as that.

I realized my mistake only after having posted my answer.
I thought this strange result (why dsolve seems to work [ the first part of the solution are the same with dsolve and pdsolve ] ?) was related to the lack of initial and/or boundary conditions ?
Maybe some kind of undocummented feature ...

But very honnestly this puzzled me a lot !