It is still not clear to me what you are trying to achieve (or why), but see if the attached does what you want

euMethod2.mw

You are enteing boundary conditions as, for example

diff( T(0,t), x)

since T(0,t) does not depend on x, Maple correctly evaluates this to 0.

What I assume you want is diff(T(x,t), x) evaluated at x=0.

Easiest way to do this is to use the D-operator notation

D[1](T)(0,t);

See the help page at ?D

If I understand you correctly, this only makes sense if you perform the calculation for a specific t-value.

v, u are functions of x, t so e is a function of x, t:

because of the summation over spacesteps, e_h is a function of t only

The attached worksheet does the calculation you specify for a more or less arbitrary list of spacesteps, and for one t-value (although this is simple to change - just change the tval assignment)

PDEplt3.mw

However I don't think you are going to like it because the resulting curve is not linear

When I try to download yourworkseet I just get an error. This is either a problem with the Mapleprimes site, or (possibly) with the filename you have chosen - try renaming with no special characters and upload again

@Al86 

If I understand your requirement, then the following worksheet (same as my previous one) with one execution group added at the end, provides an answer

PDEplt2.mw

NB because I have no idea of the significance/meaning of this function for your problem - I have no idea whether the plot generated is  what would be expected - I sugget you check very carefully

In a vain attempt to work out what your spaghettiCode was trying to do, I reorganised it into some kind of logical sequence. I'm pretty sure that the following is functionally identical to your original (but the original was so *random*, I wouldn't necessarily bet on it, and in any case it didn't really help me solve your problem!!)

euMethod.mw

The logical sequence *seems* to be

1. Define a lot of constants
2. Define a couple of procedures
3. Use the two procedures to generate two 301-element arrays (v4 and z) , each of whose entries is a 2-element list
4. Run a loop which determines the maximal index in these arrays which satisfies a given condtion
5. Select four scalar entries from one of these arrays (z) and compute an expression based on these four scalars. This returns a scalar

This makes the remark in your question

Trying to get the values into a table but struggling to get for more than one v value...

completely meaningless - you are computing a scalar!

The comment

suppose to get 20 x-values for the different initial v=0.2..4 in steps 0.2

is equally nonsensical - ther are no "different initial v" values anywhere in your worksheet.

You need to do some serious clarification!

First of all, use Maple syntax to express the quantity you want to plot, because I'd have to guess what you mean by

|| e ||_h = \sqrt{\sum_{j=0}^N h |e_j|^2}

You have been shown how to compute ln(v) against ln(u) - trust me the u-v is not difficult. However since u(x,t) and v(x,t) are 2-dimensional functions, so also is e(x,t)=v(x,t)-u(x,t) -but what the hell is  e_j??

You are specifing both spacestep and timestep in the problem - so apparently you already know the quantity 'h'. Similarly N is the product of spacestep and timestep so it is fixed. Therefore your requirement to plot log || e||_h reads as a requirement to plot an undefined function (e is defined, |e| is be defined but wtf is ||e||_h????) against an unknown. Plot this ill-defined function against what???

This makes no sense at all.

Your last paragraph is even more obscure - I have no idea what you are talking about

Pretty much any clearly-posed question on this site will be answered - muddled/ambiguous/meaningless questions will generally be ignored (or receive responses like this one)

BTW attached is my solution to your original problem. I didn't bother posting it before beceuse vv/Carl uploaded a perfectly viable solution amd mine wasn't sufficiently different/interesting to make it worthwhile. Rough, but it works - and you might as well have a copy before I consign it to the bit-bucket

PDEplt.mw

If you type

?wav

at the maple prompt you will be taken to an appropriate help page giving some information on the sub-types of wav files which can be read/written. These help pages are a little sketchy on the precise wav sub-types which can be read/written. You might have to do a little experimentation to accurately determine supported sub-types, and restrict yourself to using these.

If I try to download your worksheet, I juat get an error message:

if I can't read it,  I can't help. Can you download your own upload????

Do you have a problem using the inbuilt commands

sturm() and

sturmseq()

In other words, do you want to write your own version of these commands as some kind of learning exercise?

If you do want to write your own - then it may be helpful to read how the Maple built-in versions are implemented, which you can do with

interface(verboseproc=3):
print(sturm);

Considering that I posted a worksheet using DirectSearch[Search] - it is amusing to note that one of its method options is "brent", although the default is CDOS.

I don't really know enough about root-finding/optimisation methods to select an optimum one for a given problem. I work on the general assumption that methods with higher convergence rates (eg cubic rather than quadratic) usually require that the target function is more restricted in some way - eg continuous, or continuous first derivatives etc, etc. Methods with better convergence rates, generally require more complex calculations to be performed on each iteration, so one is hoping that

complex calculation + fewer iterations beats simple calculation + more iterartions

and this trade-off will be affected by the particular function whose root/optimum is being sought.

Furthermore I don't believe that changing methods will necessarily change the precision of the result - all methods come with some sort of "tolerance" setting - and this is the accuracy which will be achieved. Different methods may achieve the required precision in different elapsed times through two factors

1. Number of iterations - eg does the method exhibit quadratic or cubic convergence
2. Complexity of the calculation at each iteration

Just FYI, I ran the DirectSearch[Search] part of my last worksheet (dsolPar2.mw)  with the four available methods - all other tolerance/Digits settings unchanged: the results were

default (ie CDOS)

A = 199.961318896644828817410971088
r(theta) = 10000.0000000000000000000003661
time: 154 secs

method=powell

A = 199.961318896644828817410971088
r(theta) = 10000.0000000000000000000003661
time =155secs

method=brent

A = 199.961318896644828817410971088
r(theta) = 10000.0000000000000000000003661
time =155secs

method=quadratic

A = 199.961318896644828817410971088
r(theta) = 10000.0000000000000000000003661
time =155ecs

My first reaction was not to believe the above!!

But, it may be the case that the overall "accuracy" of the result is completely determined by the abserr/relerr settings in the dsolve/numeric process, rather than the optimisation. Similarly, the total time for the optimisation process may be (more or less) completely determined by the evaluation(s) for the dsolve() function at each iteration.

I suppose I could repeat the above process, with 10x tighter settings for abserr/relerr in the dsolve/numeric stage - or I could find somethiingmore interesting to do ;-)

@vv 

dsolve() with or without parameters is computes an error-driven solution whose accuracy is determined by the settings of abserr and relerr and are unaffected by Digits. Snip from the dsolve/numeric help page (Maple2015.1), my highlighting

Defaults for 'abserr' and 'relerr' are specific to each method, but it should be noted that the default error tolerance for the non-stiff methods rkf45 and ck45 is now fixed (rather than controlled by the value of Digits).

So whether one wants to use an optimisation routine or fsolve, one first has to adjust relerr/abserr within dsolve(). Otherwise one will be accurately solving/optimising an inherently inaccurate dsolve(numeric)

fsolve() itself *may* have precision issues - at least it should be used with the fulldigits option

@Ken_obi 

I don't understand the question - and googling "p stability" tells me the guys on stackexchange didn't understand either when you asked the same question there about 12 hours ago

@Preben Alsholm 

A difficulty with this problem is that there are two numeric processes - the dsolve/numeric and the optimisation. Logically, it makes no sense to produce an accurate optimisation of an underlying inaccurate(?) dsolve. So before one even starts playing with different methods for the dsolve or the optimisation, one has to start "tuning" the accuracy of both. I'm not smart enough to do this other than manually.

The attached (somewhat revised) worksheet attempts to make this easier to do. With the included settings it takes about 3mins to run on my machine

dsolPar2.mw

Whilst playing with it

1. I discovered that default dsolve( abserr, relerr) parameters do not seem to "track" the Digits setting in any way (at least for the rkf45 method): apparently one has to tune these explicitly
2. Even although I thought I was forcing use of software floats everywhere, I am suspicious that somewhere "under-the-hood", NLPSolve is using hardware floats - simply on the basis that I couldn't adjust the tolerances on either the dsolve(numeric) or the NLPSolve() routine to produce an answer for A with more than about 16 "accurate" digits - which looks (to me) like a hardware float issue
3. For comparison I included a routine from the DirectSearch package, which for the same tolerance settings on the dsolve() process, and similar(?) accuracy settings (to NLPSolve) on the optimisation, I ended up getting about 25 "accurate" digits. This definitely suggests that the DirectSearch[Search] definitely isn't using hardware floats anywhere

As well as these numerical accuracy issues, I fully accept that one may be able to come up with a quicker solution by changing the method used either in the dsolve(numeric) or optimisation processes - too many alternatives for my small brain to cope:-(

Markiyan,

I had actually done the same normalisation (in a trivially different way) - as in

restart:
with(DiscreteTransforms):
A:=Vector([1.0, 0, -3.0, 2.0, 1.0, 0.0, 1.0, 2.0],datatype=float[8]):
w1,w2:=WaveletCoefficients(Daubechies, 2):
for i from 1 by 1 to 1 do
    A:=DiscreteWaveletTransform(A, sqrt(2.0)*w1, sqrt(2.0)*w2, storagetype=singlearray);
od;

If the loop ending value is 5 then I get the answer which you reported (no surprise). However with a loop ending value of 1 (ie do the transform once), I got, for A

However this did not agree with the result in the OP's quoted reference (Wavelets for Kids, Vidakivic & Mueler) which has

[ 1/2, -1/2, 1/(2*sqrt(2)),  -1/(2*sqrt(2)), 1/4, -5/4, 1/4, -1/4]

and I was unable to come up with a normalisation which would produce the result in the OP's reference, so I went off for a think - and I didn't get anyhwere  :-(