First of all you will have to clarify what you mean, by the terms D(diff(u(x, t), x, x)) and E(diff(v(x, t), x, x)). Maple will interpret these as the functions D() and E(), supplied with the arguments diff(u(x, t), x, x), and diff(v(x, t), x, x) respectively.

I'm pretty sure that any attempt at a solution (either symbolic or numeric), would require tthat the functions D() and E() be defined.

Just for my own amusement, I assumed that D(diff(u(x, t), x, x)) was a typo for the simple product D*diff(u(x, t), x, x) and E(diff(v(x, t), x, x)) was a type for the simple product E*diff(v(x, t), x, x). Using pdsolve() on the resulting pde system *might* produce a symbolic solution in terms of the parameter D, E, alpha, beta, as well as 6 other arbitrary integration constants. I interrupted this computation after about 5mins: Maple might have been able to come up with a symbolic solution, if I had let this computation complete, but I doubt it. The next alternative would be to use a numeric solver, but this would require 6 boundary conditions, as well as numeric values for the parameters D, E, alpha, beta.

Your code executes with no errors, so I can only assume that your "problem" is that the final solve() command returns no answers, because Maple cannot find a solution.

If I aim for a 'numeric' rather than 'symbolic' solution by using fsolve() rather than solve(), and using add() functions rather than sum() functions, Maple still returns no answer

If I use the DirectSearch[SolveEquations]() command then this fails with the error message

Warning, complex or non-numeric value encountered; trying to find a feasible point

Examining the output of DirectSearch[SolveEquations]() more closely, then one or more of the equations you wish to solve is generating infinite values, for some value(s) of the variables A, B.

The only thoughts I have at this point are

1. There are no solutions
2. There might be solutions, but the equations are so nasty (coefficients up to order 10³² and variable powers such up to A¹⁷, B¹⁷) that neither fsolve(), nor DirectSearch[SolveEquations]() can find solution(s). It may still be possible to obtain solutions for [A, B], but would probably require additional information, such as the approximate values for the required solutions eg -10<A,B<10?????

In the attached I have changed the computation of values in the beta-list so that they correspond to the above, by simply selecting real() and imaginary() parts of entries in the list of p-values. I have made no other changes

corrPlot3.mw

An observation. The computation of values in the 'B'-list was originally very similar to that in the 'beta'-list. Now they are very, very different. Only you know whether this is correct!

Rather than debug your code (again!) it is much easier for me just to remove the first value in the list of p-values in the worksheet I originally posted. Then the whole divide-by-zero thing disappears.

Then all I have to do is use corresponding values from all lists so I don't have to run some sequences starting from 2, and I don't have to worry about when to use 'j' and 'j+1' as index values.

I also inserted the extended list of p-values in your worksheet.

The attached should work for any list of p-values (of any length), provided that this starting list does not contain 0

corrPlot2.mw

1. In 1-d math input evalf(pi*Pi) returns 3.141592654*π: however if one converts this to 2-D math input, then one 'sees' evalf(π·π) and it returns 9.869604404
2. In 2-d math input evalf(pi*Pi) also returns 3.141592654*π: if one converts this to 1-D math input, then one 'sees' evalf(pi*Pi) and it returns 3.141592654*π. So 'obviously', if one converts back to 2-d input, then bulletPoint(1) applies!
3. On the other hand if one uses the symbol/greekLetter palettes, selecting one "representation" of π from the "Common Symbols", and the other from "Greek", then one 'sees' either evalf(Pi*Pi) or evalf(π*π) depending on whether one is in 1-D or 2-D input modes respectively. Obviously both evaluate to 9.869604404. So far as I know there is no way to get the 'simple' Greek letter π using palettes - it is always interpreted as the symbol for 'circumference/diameter'

I reformatted/rearranged your worksheet just to make it easier (for me) to read. I'm pretty sure I did't alter your intentions (but it is possible). See the attached

odeProb.mw

This now executes, but doesn't really produce anything interesting. The form of your differential equations and, in particular, your boundary conditions (all zero), means that the first ODE system 'dsys3' is satisfied by f1=f2=f3=0, for all values of the independent variable.

In turn this means that your approximating polynomials 'f11', 'f22',' f33', are also identically zero.

The above facts, in conjunction with the form of your second ODE system 'dsys4' and its associated boundary conditions (again all zero) means that this system is satisfied by h1=h2=h3=0 for all values of the independent variable

So the second set of approximating polynomials 'g1', 'g2', 'g3' are also identically zero.

I can see many other "curious" statements, which I haven't bothered to fix/improve. There doesn't seem much point in doing any more until the ODE systems return something other than 0 for all dependent variables

You said

"But the formatting must then be applied to the each line."

In Maple 2016, using the Format->Numeric Formatting window, and then hitting the "Apply and set as default" button sets the selected "engineering notation" to be applied to the output of all subsequent (floating-point) calculations. This works for me - so I'm not sure why you have a problem

There is a clear distinction to be drawn between the precision with which calculations are performed, and how results are displayed. You have to think about this: by adopting "engineering" notation, the number of digits preceding the decimal point can vary from 1..3. For the default setting of Digits() (ie 10), this means that the number of meaningful digits after the decimal point can be anything from 7..9.

The "Numeric Formatting" dialog allows you to set the number of "decimal places" which you want to be "displayed". Assuming that you are using a default Digits() setting of 10, then it makes little sense to display more than 7.

Notice that having set the number of "decimal places", then Maple will always display accordingly - trailing zeros will not be discarded. After all the numbers 2.5 and 2.50 mean two different things!

In terms of storage formats "*.m" is probably more efficient (faster/smaller) than anything else. But since it is an internal Maple format, such files canonly be read by Maple. If you want to read these files with different software, then yo may want to consider the ExportMatrix(fileName, MatrixName, options) command where the options parameter will permit you to specify a number of different 'formats' which might be acceptable to the alternative software

In order to programmatically generate the matrix names and file names, I would probably use something based on the "toy" example below

  i:=7:j:=3: k:=5:
#
# MatrixName
#
  A||i||j||k;
#
# FileName
#
  cat("A",i,j,k,".m");
#
# So obviously you could use
# something like
#
# save A||i||j||k, cat("A",i,j,k,".m");

More or less equivalent to vv's

ranges:=[t=-infinity..0,t= 0..1, t=1..2, t=2..3, t=3..infinity]:
fvals:= [0, t^2, 1, 3-t, 0]:
max(zip((x,y)->maximize(x,y,location)[1], fvals, ranges));

I have tried your code in Maple18, Maple2015, and Maple2016, and it works in all of them.

A tidied version of your code (see attached) also works in all three versions.

Can you post a worksheet which demonstrates the problem

nonProblem.mw

Your original system of odes is

fourth order in w(x) - requires four boundary conditions,

third order in G(x) - which requires a further three boundary conditions

for a total of 7 boundary conditions.

However, you also have one further "unknown" - ie omega2. Effectively the problem has 8 'unknowns'.

In order to solve such a system, then you must have 8 'subsidiary conditions'

In your original worksheet you supplied only 7 boundary conditions: 6 from 'bcs' and 1 from 'extra_bcs' - which is insufficient to determine a solution.

In my original response, I eliminated one of the unknowns, by just giving it a an arbitrary value. As my original worksheet shows, it is then trivial to solve the system for the remaining 7 unknowns using your 7 supplied boundary conditions.

Carl has adopted an alternative approach for producing the required 8 'subsidiary conditions': just take 6 conditions from 'bcs' and 2 from 'extra_bcs'. Only you can determine whether this approach is valid

I can think of other ways in which the additional condition might be defined. For example, one could maximise the value of w(x) for some value of x, with omega2 as the optimisation parameter. - but, once again only you know whether or not such a condition would be valid.

Two processes  which I will call 'elision' and 'lengthCheck'

If you run them in the order 'lengthCheck' followed by 'elision' you will fail. And if you run them in the order 'elision' followed by 'lengthCheck' you never will.

Now I accept that for relatively 'short' procedure definitions, such a simple process would suppress displays when I might actually want to see them, but I don't see anything spectacularly difficult with something like

(Warning - following is preudocode (not Maple))

if lengthCheck > someValue
then do elision        display output
else display output
fi

Whilst I agree with everything Preben has said (particularly in regard to the solutions which are 0 everywhere for everything) - one thing bothers me. The command

dsolve(dsys3, numeric, initmesh = someValue, abserr = 0.1e-4);

*ought* to return a "procedure" something like

proc(x_bvp) ... end proc

My experiments show that it does so, provided that the argument to initmesh any number <=2010. For reasons which are a complete mystery to me, if initmesh=2011 (or any larger number), then instead of getting the simple returned 'proc' statement above, one gets `[Length of output exceeds limit of 1000000]`

If I change the output from the default to

dsolve(dsys3, numeric, initmesh = someValue, abserr = 0.1e-4, output = listprocedure);

then the same thing happens whenever the value for initmesh is >=2004

I can think of no reason why the 'length' of the output should change, just becuase the value of 'initmesh' changes - one should always get either a procedure definition or a list of procedure definitions, and neither of these should hit the output length limit

Something weird is happening!

FWIW, I'm running Maple 2016.1 on 64-bit win7

Attached is a modified worksheet.

I didn't see any problem with producing a smooth plot

projProc4.mw

Well your latest worksheet contains 13 boundary conditions and I'm very doubtful about 3 of them

1. I don't think you can have boundary conditions which are second order in the time derivative, if the pdes themselves are second order in the time derivative. This applies to the first two entries in bcs1 in the attached
2. the final boundary condition D[2](u)(La, 0) = -ve

Anyway the attached has all the boundary conditions coded correctly. I only used the first 12. As I expected Maple does not like the boundary conditions which contain second derivatives in time.

pdeSol.mw

Are you sure about these bcs/ics????