@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 !



 

@Ahmed111 

Hi, 

I guess the first question is: iS my interpretatoin correct (2 coupled PDEs in two unknowns psi__1(x,t) and psi__2(x,t)) ?
If it is so you need to provide initial and boundary conditions.
A priori, bur this need a closer look to the PDE system, I would say that for each n in {1, 2} :

1. psi__n(x,0) = some function of x, possibly a constant
2. psi__n(0,t) = some function of t, possibly a constant
    

More of this dsolve doesn't return a single couple of solutions.
The solution structure is {psi__1, psi__2}, { [psi__1, psi__2], [psi__1, psi__2] } : this should be avoided with correc ICs and BCs.

numelems([sol]);
                               2

whattype([sol][1]);
                              set

whattype([sol][2]);
                              list
whattype~([sol][2]);
                          [set, list]

Look now to the indeterminates of the solution(s); here I just extract the those of type "name".
The underscored quantities are "integration constants": here again they should disappear once ICs and BCs are set
indets([sol][1], name);
        {_C1, _C2, _C3, alpha, lambda, rho, t, x, _c[1]}

indets([sol][2], name);
                {_C1, alpha, lambda, rho, t, x}

Carl Love provided a solution based on his own interpretation of your question and I gave another one based on my own understanding.
I think it is up to you to determine which is the one that better fits your problem.
Once done, if you think that my interpretation suits you, you will have to choice ICs and BCs and use pdsolve (not dsolve)  to find the solution.
This is another question, the ball is in your court.

 

@Rouben Rostamian  @acer  @Mariusz Iwaniuk

The ball hits the ground for the kth time at time T(k) := k -> sqrt(2) + 2 * sqrt(2) * add(1/(2^n), n=1..k-1).

The comparison the hit times for my solution and Rouben's one (g=0 below the ground) is slightly at my advantage :-)

But the fact my solutions captures only a finite number of rebounds remains an unsolved issue  :-(

(and this whatever the values of Digits and epsilon in the test (Twall__||k - Twall__||(k-1)) > epsilon)

Here are 2 detailed plots around the 16th hit (Rouben's solution in red, min in brown))
Rouben's solution goes wrong after the 19th or 20th hit (WHY ???)

approximated value of T(16) is  4.2425543703735348354
My solution provides the value  4.2425543703735348354
Rouben's one is correct up to the 4th decimal position