Don't have an argument with anything Mac Dude has suggested

I'm not a big fan of "code translation" in general. Ny experience suggest that translators work somewhere between 95% and 99% of the time - so I would anticipate a code translation failure on anything with more than about 20 lines of code: a pretty depressing thought

My fundamental problem is that your code snippet wouldn't run in Matlab: so I suggest

1. You post a functional matlab (ie *.m) file for what you are trying to achieve. NB this must work in Matlab, and prodeuce plausible ressults, cos I will check.
2. If it doesn't work in Matlab then I guarantee that any translation will not work in Maple, and I will not bother to debug
3. If it runs in my Matlab, then I will (probably) be able to make the translated version run in Maple

Like the headings on my posts made clear, I'm no kind of expert with the physics[] package, but I believe I ended up with same set of three PDEs as you did. OK, maybe I did it a brain-dead, long-winded way

However, from the OP's viewpoint, being able to express his original problem in terms of three PDEs for which pdsolve() cannot provide a solution doesn't seem to be significant progress - or maybe I'm missing the ultimate point?

In order for pdsolve to have any hope, I am guessing the the problem has to be recast in component form, to generate a set of three coupled PDEs. I tried this, and supppled pdsolve() Using the following code

#
# Set up OP's original problem
#
   restart;
   with(Physics[Vectors]):
   Setup(mathematicalnotation=true):
   eqn1:=Gradient(Divergence(f_(x,y,z)))+K*Laplacian(f_(x,y,z))=0;
#
# Convert to component form, to come up with
# something pdsolve() might have a chance of
# dealing with. Produces three PDEs
#
# First rewrite f_ in component form
#
   eqn2:=eval
             ( subs
               ( f_(x,y,z)= f__1(x,y,z)*_i
                                +
                                 f__2(x,y,z)*_j
                                +
                                f__3(x,y,z)*_k,
                 eqn1
              )
           );
#
# Split equation into three components
# because these must be simultaneously
# satisfied
#
   sys:={ seq( Component(eqn2,j),
                     j=1..3
                  )
           };

#
# Only uncomment the following if you feel
# like waiting for a long time - I gave it about
# 10mins, and Maple was still thinking, so I
# interrupted the process
#
# pdsolve(sys);

Like my final comment says - pdsolve did mot produce an error, but after 10mins or so had not produced a solution, so I interrupted it

@Rouben Rostamian  

You are, of course, correct: what makes it worse is that I have been in this particular hole before!

Maybe I shouldn't post anything here when it is past my bedtime

Your grasp of calculus is interestingly mixed.

You have managed to

solve a set of ODEs using rkf45 method and I had plot it's Diagram

and yet you don't appear to know that the area under the curve is the integral of the curve - that's (kinda) the definition of an integral - so just integrate whatever curve you have.

With no example, no code, that's the best I can do

\We've all been there

In the definition of a function, the argument has to be a name - think of it as a dummy variable, or a passed argument.

So for example

k__f:= z-> k__f0*exp(-E__f0/(R__0*z));

just defines a function, it doesn't actually do anything - think of it as writing a procedure or subroutine, which will only do something interesting when called with an appropriate argument, The argument can be pretty much anything for which the body of the function makes sense. So if you now enter

k__f(T(x,t));

This means apply the function k__f()  to the argument T(x,t), and everything works just fine

If you enter the code as

restart:
interface(imaginaryunit, errorbreak=0, errorcursor=true, labelling=false):
with(SolveTools):
a:=1:c:=1:
################################
  for k from 1 to 5 do
      sols:=solve(a*x^2+k*x+c, x):  # assuming x::complex;
      printf("      k=%d  sols[1]=%a  sols[2]=%a\n", k, sols[1], sols[2]);
end do; #for k
#################################
printf("End of for loop\n\n");

The this will display the output of the solve() command followed by the output of the printf() command (Not sure why you want both)

Not that in order for printf() to work, you need %a as the format string in order to handle complex numbers. As the help page suggests, if the format is %a then printf() performs

The object, which can be any Maple object, is output in correct Maple syntax

If  you have a sufficient number of differential equations/boundary conditions then it ought to be possible. However bear in mind

1. Many/most pdes cannot be solved analytically and solutions have to be done numerically: however Maple'ss numerical solvers are pretty good
2. Most common problem with a numerical solution is encountering a singularity - somewhere a function value or its derivative(s) becomes infinite/indeterminate. If your system is modelling a "real-world" physical situation, then this oughtn't to happen - becasue very little in the "real world" becomes infinite
3. The only other issue I see with your system (and we haven't got to this point yet) is that several of your boundary conditions are equations containing function values and their derivatives at specific values. This is not incorrect, just slightly unusual. It must be possible to solve these equations to get the numerical values. In other words, if I treat these boundary conditions as a siimple set of n equations in n unknowns, then this system must be solvable

The example you quote above whihc you "do not understand". You really have to grasp the difference between an equation and a function application. The attached "toy example" might help, but I encourage you to read the help page for the -> operator.

ToyExample.mw

When I made the changes for the functions m(), lambda(), and kf() - I was **GUESSING**. I have no real way of knowing whether my *GUESSES* were correct. Only you know this! I don't like making guesses because I often get it wrong!

There is another comment in your revised worksheet which is going to cause a problem, namely

we can calculate rho__g(x,t)*U__g(x,t) together. Separately, these values are not necessary.

You may *know* that these functions can be "calculated together", but Maple does not!! And Maple will certainly not assume it. As far as Maple is concerned, these are two independent functions which have to be solved for.

If there are not enough equations, to solve for all the unknowns which you supply, then no solution will be available

I have tried to untangle what you are attempting in you worksheet but have not been able to succeed.

I find it difficult even to determine exaclty which are the unknown functions and which are "known" functions - not helped by the fact that I am (nearly!) sure there are a few typos in function names in places

I suggest you read all the comments I have added to you worksheet and consider them very carefully

Mod03.mw

Since in your previous attempts with this problem (http://www.mapleprimes.com/questions/206320-Zero-Roots-Of-Equation), you stated that Maple was incapable of providing the answer, and you claimed

I solved my dproblem in Matlab by new method. I wrote a new code, and i got the true answer(the root 7.52) which in Maple I didn't find it.

I would have thought that subsequently plotting expressions involving HeunT() functions in Matlab, would be trivial. I have always found Matlab's plot routines very effective.

I guess we both know why you aren't doing this problem in Matlab!!

Well, Edgardo beat me to it, (and I agree with him that your basic problem is caused by inept syntax errors) but the attached worksheet should provide everything you need/want

HeunProb.mw

@zia9206314 

I use Maple and Matlab in equal proportions. I am always interested when someone claims that one of these (for numerical problems) can perform a task which the other cannot. This would influence my choice of software for solving problems of a related type

Hence I would be be very interested in seeing your Matlab code (if it exists)

@acer 

I'm running stock Matlab 2015b, with no toolboxes (can't justify the expense)

Entering "Heun" in the Matlab help produces no results: I'm not saying that one cannot calculate Heun functions using Matlab (cos obviously one could write the code to do so). However so far as I am aware it is not "built-in"

Is it possible to get third-part code to do this? - probably yes, but I haven't searched/checked.

My comment refer to "vanilla" Maple versus "vanilla" Matlab

When you enter (probably incorrectly, because od the missing multiply sign)

3*(2*x-1)(x+1) > 0,

Maple interprets this as 3 times the function composition (2*x-1) evaluated at the point (x+1), whic Maple is clever enough to decompose as

3*(2*x)(x+1) -3(x+1)

In other words 3 times the function (2*x) evaluated at (x+1) minus the function 3 evaluated at the point (x+1): Maple simplifies this further to

6*x(x+1)-3, because

1. the value of the function -3 evaluated at any argument (in your case x+1) is always -3
2. the value of the function (2*x) evaluated at any point is the the same as the value of the function 2*(x) evaluated at the same point - so you end up with 6*x(x+1) which is 6 times the value of the function (x) evaluated at the point (x+1). Note that this is a completey different object from 6*x*(x-1)

Amazing the difficulties one can get into by omitting a '*' from the original expression

When expressions are entered correctly, one can use commands such as simplify(), expand(), collect() to control the form of the displayed solution - depending on the form the user thinks is the simplest/prettiest