Rouben Rostamian

MaplePrimes Activity


These are replies submitted by Rouben Rostamian

@Mohamed Mohsin If you don't know how to solve a problem, try to find an easier problem that you can solve.  If you don't know how to solve that easier problem, find even an easier one, and so on, until you arrive at a point where you are able to do something.

For instance, in your case, do you know how to solve

D^γ S(t) = S(t)

and if not, do you know how to solve

D S(t) = S(t)

and so on.

You should also ask yourself:

  • Do I know anything about fractional differential equations?
  • Do I know anything about the homotopy perturbation method?  

Answers to these questions have nothing to do with Maple. Begin with investigating these mathematical prerequisites of your master's thesis.  Coding and calculating with Maple will come only after you have positively answered those questions.

 

I assume that you have done more for your master's thesis than what you have shown here.  Explain what you have so far, and where it is that you need help with Maple.

Otherwise it looks like you are asking for someone else to do your master's thesis for you.

@ijuptilk I am puzzled by your statement that you have an analytic solution for the problem since your initial condition v(z,0)=0 is inconsistent with the rest of the system.  Examine what you think is an analytical solution.  It's either wrong or it violates v(z,0)=0.

The reason that v(z,0)=0 is inconsistent is that there is no t derivative of v(z,t) in your system of PDEs, so you cannot specify an initial condition on v at t=0.

If you remove the v(z,0)=0 condition, you can obtain a symbolic solution to the problem without much difficulty.

@ijuptilk As it has been pointed out to you, sin(pi/2) is 1, so saying theta(z,0) = thetab*sin(pi/2)*z is the same as saying theta(z,0) = thetab*z.  Do you see that?

I suspect that what you really want to say is theta(z,0) = thetab*sin(pi/2*z).  Look closely at what you write. Mathematics is a very precise language.

Furthermore, are you sure you want sin(pi/2*z)?  Changing it to sin(pi/d*z) makes it compatible with the boundary conditions.

Finally, since you know the symbolic solution, why are you bothering with a numeric one?  Can you give the reason?

@ecterrab Thank you for your customary lightningly quick reaction to issues brought up here in this forum.  I will either install the Physics Update or just do `-`(1, p.q) for now.  Both methods will enable me to move forward.

Thank you again!

Rouben

@ecterrab Your explanation regarding type versus Identiry makes good sense.  With that hint I have been able to move over a good deal of my (rather extensive) old code from the LinearAlgebra vectors to Physics vectors.

I have run into a puzzle which I would appreciate if you could illuminate for me.  Consider the following code:

restart;

with(Physics[Vectors]):

 

my_module := module()
        uses Physics:-Vectors;
        export my_proc;
        
        my_proc := proc(p::PhysicsVectors, q::PhysicsVectors)
                1 - p.q;
        end proc:

end module:

 

my_module:-my_proc(u_,v_);

Error, (in my_proc) invalid input: Physics:-Vectors:-- uses a 2nd argument, b, which is missing

 

 

I don't see why Maple complains.  I can get around that by replacing the line 1 - p.q with `-`(1, p.q) but that shouldn't be necessary, or should it?

 

Download mw4.mw

Here is a reply to my own reply.  In the code above, under the PS, I noted that f(b_) returns [b_, 0] while it should have returned [0,b_].  Tracking down the source of the error, it turns out that it is due to the following.

restart;

with(Physics[Vectors]):

type(b_, PhysicsVectors);

true

type(b_, scalar);

true

So Maple considers b_ to be both a scalar and a vector!  One way to get around this is by testing b_ for Vector before testing it for scalar.  Then the outputs (1), (2), and (3) in the worksheet below are correct, but the final calculation is still problematic due to the blurring of scalar and vector zeros.

restart;

with(Physics[Vectors]):

This proc accepts a scalar, a vector, or a list of [scalar,vector]

for its argument.  In all cases, it returns a list of [scalar,vector].

f := proc(p::{scalar,PhysicsVectors,[scalar,PhysicsVectors]})
    if type(p, PhysicsVectors) then return [0,p];
    elif type(p, scalar) then return [p, 0];
    else return p;
    end if;
end proc:

f(a);

[a, 0]

(1)

f(b_);

[0, b_]

(2)

f([a,b_]);

[a, b_]

(3)

f([a,0*b_]);

Error, invalid input: f expects its 1st argument, p, to be of type {scalar, PhysicsVectors, [scalar, PhysicsVectors]}, but received [a, 0]

 
 

 

Download mw3.mw

Hello again, Edgardo,

Your response arrived as I was preparing to post an extended explanation for why I am asking the question, and why I need to distinguish between a scalar zero and zero vector.  Have a look at this:

restart;

with(Physics[Vectors]):

This proc accepts a scalar, a vector, or a list of [scalar,vector]

for its argument.  In all cases, it should return a list of [scalar,vector].

f := proc(p::{scalar,PhysicsVectors,[scalar,PhysicsVectors]})
    if type(p, scalar) then return [p, 0];
    elif type(p, PhysicsVectors) then return [0,p];
    else return p;
    end if;
end proc:

f(a);

[a, 0]

f(b_);

[b_, 0]

f([a,b_]);

[a, b_]

f([a,0*b_]);

Error, invalid input: f expects its 1st argument, p, to be of type {scalar, PhysicsVectors, [scalar, PhysicsVectors]}, but received [a, 0]

I have been doing the equivalent of this with the LinearAlgebra package but I would rather transition to Physics[Vectors] for the reasons that you have explained .  My attempt, however, to convert everything from LinearAlgebra to Physics[Vectors] failed right near the beginning for the reason shown above.

I may be able to work around the issue by blurring the semantical differences between scalar and vector zeros, but I am afraid the resulting code will be ugly.  Your suggestion of OR(0,PhyicsVectors) seem promising.  I will try it out tomorrow and report what I find out.

Download mw2.mw

PS:  Opps, in the code above we see that f(b_) return [b_, 0].  It should have returned [0,b_].  I will have to find out why tomorrow.  It's past midnight here.

Hi Edgardo, that's excellent.  It would be good to have the documentations of that and the other Physics types available in an easy-to-find place in the help pages, although I understand that documenting 114 types would be a monumental task.

Now that I know how to check for PhysicsVectors in the arguments of a proc, I have run into a new problem.  It appears that multiplying a Physics Vector with zero results in the scalar zero rather than the zero vector.  Shouldn't there be a zero vector in the Physics package?  In contrast, in LinearAlgebra, multiplying a Vector by zero results in a zero vector, not the number zero.

The lack of the zero vector in the Physics package has the following adverse consequence:

restart;

with(Physics[Vectors]):

 

f := (v_::PhysicsVectors) -> v_ . v_;

proc (v_::PhysicsVectors) options operator, arrow; Physics:-Vectors:-`.`(v_, v_) end proc

f(a_);

Physics:-Vectors:-Norm(a_)^2

f(k*a_);

k^2*Physics:-Vectors:-Norm(a_)^2

f(0*a_);

Error, invalid input: f expects its 1st argument, v_, to be of type PhysicsVectors, but received 0

 

I can't tell whether there may or may not be an easy fix for this. In any case, want to bring this to your attention.

Download mw.mw

@tomleslie Thanks for the details.  It shows that I am not just imagining things.  Sometimes the graph is colored black, even in Maple 2022 on my machines.  I need to do some more work to get to the bottom of this.

@Christopher2222 Thanks for your demo.  It shows that I am not just imagining things.  Sometimes the graph is colored black, even in Maple 2022 on my machines.  I need to do some more work to get to the bottom of this.

@acer Thanks for checking this.  My problem may be due to a bug in my Linux distribution (I am using Ubuntu MATE).  I am thinking of booting another distribution of Ubuntu from a flash drive, installing Maple, and seeing how that works.

@Scot Gould Thanks again for checking my test file.  It's become a puzzle for me.

As to your dual-monitor setup, I have no experience with such things.  Perhaps if you ask support@maplesoft.com, they may offer an explanation.

Thank you Christian WolinskiScot Gould, and tomleslie for looking into this. I have examined the details of the troublesome plot structures and reduced them to a minimal form that still exhibits the issue.  As before, specifying two distinct colors produces the expected result but specifying two identical colors results in one of the two graph being rendered in black.  Here is the minimal file:

plot-color.mw

I have tried this on three computers with three different graphics cards, and different versions of Ubuntu Linux.  Perhaps this issue is specific to Linux?  I am stymied.

@delvin You are writing D^alpha * u(x,t) for the derivative of order alpha of u(x,t).  That's far from correct.  Here are a few observations.

  1. Your notation does't say whether that's derivative with respect to x or t. How is Maple to know which do you mean?
  2. The asterisk in your notation indicates multiplication.  But you don't mean to multiply D^alpha and u(x,t).  What is needed there is a differentiation operator acting on u(x,t), not a multiplication.
  3. The notation D^alpha means D raised to the power alpha.  But you don't mean to exponentiate D here, do you?  You mean to compose D by itself alpha times.  The Maple notation for that is D@@alpha.
  4. But knowing that won't help you since the D@@alpha notation does not say whether it is a derivative with respect to x or with respect to t.
  5. Furthermore, the notation D@@alpha is valid only for integer values of alpha.  But your alpha is a fraction, so you should forget about the D operators altogether.
  6. Fractional order derivatives are calculated through the fracdiff command in Maple as I illustrated in my original reply.

The problem that you are attempting to solve is far too advanced for a beginner user of Maple.  You should start with much simpler problems to learn about Maple's syntax.  Since you are interested in differential equations, you should get a firm grasp of the differential operator D.  Try analyzing some basic ordinary differential equations.  Then try some classical partial differential equation, such as the heat and wave equations and compare your results to what you have learned from textbooks.

Take up fractional differential equation only after you have gained mastery of the classical ones.  But don't expect that to happen quickly.  These things take time to learn. 

1 2 3 4 5 6 7 Last Page 1 of 80