@MichaelVio Perhaps there is some problem with the derivation, but in any case, the parameters are varying over too many orders of magnitude to be easy to solve.

plm2.mw

You should non-dimensionalize to solve this problem. I can try to help with this but I need to know the units of all the quantitites. Tg in s, rp in m, N in ?, E in J, etc. Is N*V supposed to be energy?

I would supply an initial condition to dsolve. Otherwise you will need to supply a value for _C1. If you specify explicit=true in dsolve then you will get a solution of the form E(vu) = ...

You had a 4th dependent variable p(x,y) but there are only 3 pdes. So I just got rid of it by multiplying it by zero.

The problem is that the time-based variable, say x, is second order, and so needs 2 "initial" conditions for each function, say the value of the function at 0 and the value of its derivative at 0; it cannot have a boundary condition away from 0.

I adjusted the conditions to make sol_square successful, so you can see how these conditions would have to be. It you change a second derivative condition at zero to a boundary condition at 1 you will get an error message about elliptic equations.

Bottom line; Maple's solver cannot deal with the case of two boundary conditions for each of x and y.

cavity_work_error2.mw

@Suryakanth I'm sorry, I've misled you; the single-equation limitation is for methods other than the default method. The default method can do a system of pdes - see ?pdsolve,numeric. But there can be only one "time" variable and one "space" variable. So you should be able to use it for your (x,y) system for the square, by choosing one of them to be the time variable.

But you won't be able to do the h cavity.

I don't understand the streamlines, but can take a look at the basic code later, perhaps tomorrow.

pdsolve cannot numerically solve a system of  three pdes - "The use of pdsolve/numeric with these methods is restricted to a single parabolic/hyperbolic PDE that is first order in time." (see help page ?pdsolve,numeric,education).

The available methods (aside from the default) are listed on the same page as

ForwardTime1Space[backward/forward]
CenteredTime1Space[backward/forward]
BackwardTime1Space[backward/forward]
Euler/ForwardTimeCenteredSpace
CrankNicholson/CenteredTimeCenteredSpace
BackwardEuler/BackwardTimeCenteredSpace
Box[backward/forward]
LaxFriedrichs
LaxWendroff
Leapfrog
DuFortFrankel

so I'm not sure where you got "method=fd". Perhaps you wanted the first of these?

Even if pdsolve could solve this system it could only solve the simple square geometry. The h shape does not seem to have enough symmetry to break it into several smaller problems.

You need some specialized software like COMSOL to tackle these types of problems. 

@salim-barzani So in p1.mw, the linear/nonlinear part had a non-linear part, which by my definition is incorrect. [Edit: what I mean by that is the logic that works for p1.mw depends on the linear/nonlinear definition, which applied to pde-condition.mw gives the wrong answer]  So you need to answer my question. Otherwise I am not able to understand how it works.

@sand15 The  Kucharska & Pielaszkiewicz thesis in the NIG definition cites ref 4, which is at https://www.jstor.org/stable/4616433 and has an asymptotic formula for K1 (Eq. 2.9) that is the same as DLMF 10.25.3.

Strange and interesting. Thanks for the stimulation :-)

@sand15 I agree that the modified third kind is just what is usually called the modified second kind. 2.14 and 2.15  in Garcia are the same as 10.27.4 and 10.27.5 in DLMF. 2.14 and 10.27.4 are for any index; 10.27.5 doesn't have the limit, but says below it take the limit if necessary. Then 2.15 and 10.27.5 are for integers, just written in slightly different ways.

It is interesting tha Garcia doesn't mention any modified second kind, so there must be some historical reason for this.

The DLMF lists Bessel functions of 1st, 2nd and 3rd kinds, the last being Hankel functions, but for the modified Bessel functions there are only the two kinds. So your notation seems non-standard, but can probably be related to the others. Do you have a definition?

@Andiguys As far as I can see, it looks OK.

@Andiguys You have set lambda to something with w in it. Then you try to set w to something with lambda in it, which has w in it, so we have a problem. Not sure what was intended here but you can't define w in terms of w.

I agree that there is that tendency not to acknowledge, and it is disappointing. There might be different reasons for this. The question was asked 2 minutes before the assignment is due (of course I'm exaggerating), and an answer wasn't forthcoming in 10 seconds.

On a slower timescale a more complicated question may be asked and if there is not an answer in a day or two, the person doesn't check back (and didn't subscribe).

Then there is the question where the asker expects you to read 27 literature papers and generate 5 worksheets, and is unhappy that you only generated one worksheet on one aspect.

I'm fine with some indication that a vote has been given by the asker.

However, the status quo has the blissful ignorance advantage: if it was a vote from someone else in the community and not the asker I'm happier than if I actually knew the asker ignored me.

@lemelinm You're welcome. I aimed at your objective to assign values to c etc, but @acer's point about eval is a good one (I voted up). So I would urge you not to assign. If you assign at the beginning, then it is very hard to debug rearrangements and manipulations of symbolic formulas which just output numbers. Almost all my worksheets derive things symbolically and then put numbers in at the end using eval(.., params). So I think the extra work of eval is offset by the ability to debug and "really see what is happening".

@salim-barzani One aspect is that solving for lambda[0] must give a constant (independent of xi) otherwise when substituted into the ode for G(xi), we are not respecting the conditions it was derived for.

As for the paper's lambda[0] not working for the ode for G(xi), that suggests that it is not the ode that corresponds to F.

In your problem-.mw, the value of lambda[0] does not matter.

I randomly looked at W[2] and it has an extra term with Z[2] (the last term) that is not in the paper. So is it some earlier part that is incorrect that you want to correct? If so please be more specific about where it goes wrong and what you want done.

You should not use the deprecated package linalg. If you just had that for jacobian, the new Jacobian is in VectorCalculus.