Nope still nothing

Another attempt

Nope still nothing

Another attempt

Nope still not working

Trying again

Nope

Using the big green up arrow

'Browse' allows me to select a file

'Upload' inserts the name of the file in the 'Upload link or Content section

'Insert Link' with our without 'Cancel' seems to do nothing - link does not appear in worksheet,- just nothing

'Insert Contents' with or without 'Cancel' seems to do nothing

Since it worked for you, let's try eliminating the obvious: which browser were you using? (I use 64-bit Firefox as default.)

Since this seems to have turned into a competition about who can get the answer with the shortest number of code lines, I have revised my second solution above ( ListCorr2.mw -the one using elementwise operators) to strip out everything except the basic elementwise calculation

This now provides the answer in 8 lines of code (and I could do it in 7 lines if I were prepared to sacrifice "efficiency" for "length"). So if you really want it short, check out

restart;
varepsilon[1] := [3.0, 18.0877$7]:
varepsilon[2] := [2.0, 1.1146$7]:
mu[1] := [2.0, 1.3657$7]:
mu[2] := [3.0, .2846$7]:
f := [1.184*10^9, 8.2*10^9$7]*~[0.50e-2, 0.15e-2, 0.18e-2, 0.21e-2, 0.24e-2, 0.27e-2, 0.31e-2, 0.34e-2]/~(3*10^8):
P := sqrt~((mu[1]-~I*~mu[2])/~(varepsilon[1]-~I*~varepsilon[2]))*~tanh~(2*I*Pi*~sqrt~((mu[1]-~I*~mu[2])*~(varepsilon[1]-~I*~varepsilon[2]))*~f):
RL := 20*~log10~(abs~((P-~1)/~(P+~1)));

I apologise for the formatting of the above code. It seems that the some incompetent idiot at Maple has now made it impossible to

1. Upload a worksheet!!
2. Do any kind of horizontal stretch on the MaplePrimes input window
3. As a result it is essentially impossible for me to upload any kind of usable '2D-input' code, so the above is in Maple '1D input' format - sorry, not my fault

when you are doing the seq() calculation, you have

mu[r] := [seq(varepsilon[1][k]-I*varepsilon[2][k], k = 1 .. 8)];
varepsilon[r] := [seq(mu[1][k]-I*mu[2][k], k = 1 .. 8)],

ie mu[r] depends on varepsilon[1], varepsilon[2] and

varepsilon[r] depends on mu[1] and mu[2]

When you are doing the "first-point-in-list" calculation you have

mu[r] := mu[1]-I*mu[2];
varepsilon[r] := varepsilon[1]-I*varepsilon[2]

You have to make these two consistent, to get meaningful answers!!!! In my previous responses, I changed the first of these to

varepsilon[r] := [seq(varepsilon[1][k]-I*varepsilon[2][k], k = 1 .. 8)];
mu[r] := [seq(mu[1][k]-I*mu[2][k], k = 1 .. 8)],

I recommend that you always have a 'restart' executiuon group as the first in your worksheet (as in my previous post)

I admit that I do not understand why your use of 'i' and 'j' as the square root of -1 did not result in some sort of syntax error, or non-numeric answers to be generated. I don't propose to work out why: just use 'I' whenever you want sqrt(-1)

I have added an execution group to my previous response, which does the same calculation (and gets identical answers) - but uses only elementwise operators. No seq() commands are strictly necessary

ListCorr2.mw

Of course in could be that Maple2D is the only "parser" I have come across where a space is 'sometimes' treated as a 'multiply'.

Please identify any other "modern language" where a space would be interpreted as a 'multiply' operation

Entering ?Arrayplot at the Maple prompt will direct you to a help page which shows how to generate an 'array' of plots.

Why does this not meet what you want?

Pretty sure I'm not adding much to what loramina123 has posted, but you might want to see the thought process which he/she and I went through

1. You code as posted generates the error message "Error, (in dsolve/numeric) delay equations are not supported for bvp solvers". Now this is an 'unusual' error message!! As in - how is Maple interpreting this as a 'delay equation'. After some inspection, I concuded that the problem was proabably with your definition of the boundary condition in the statement icc1:=......., which contained (as far as I can tell) two different symbols for 'e' and three(!) different symbols for '-'. Ahh the pleasures of 2D-input. So the first thing I did was to convert this to simple, unambiguous 1-D input, as in ic1 := h(0) = 0, (D(h))(0) = (1/180)*theta*Pi, (D(D(h)))(2.0*10^(-6)) = 1/R, h(2.0*10^(-6)) = 200*10^(-9);
2. Having made this change, re-executing gives the error message 'Error, (in dsolve/numeric/bvp) system is singular at left endpoint, use midpoint method instead'. Actually this is progress, since this message is not too uusual - it simply means that the provided equation and the provided bcs cannot be solved along the boundaries. It might be that Maple is trying to compute 0/0 or x/0 or something which is numerically impossible at the boundaries of the problem.
3. The standard 'solution' for this problem is to shift from an end-point method (Maple default) to a mid-point method, which sneakily avoids evaluation along the boundaries. loramina123 tried this by specifying method=bvp[middefer] and got the error message 'Error, (in dsolve/numeric/bvp) initial Newton iteration is not converging'
4. Just to check, I also tried method = bvp[midrich], but this also resulted in the same error message as obtained by loramina123, in other words 'Error, (in dsolve/numeric/bvp) initial Newton iteration is not converging'
5. I played around a little with various erro criteria etc, but basically, I am forced to conclude that Maple cannot find a numeric solution for this ODE with these boundary conditions

1. In the definition of eq2, you use square brackets '[]' to group terms. In Maple, 'simple' term grouping is always done using round brackets '()'.
2. Even fixing the above, the bcs are incorrect, The ODE is third order, so you need three: but you cannot just pick three different values as the arguments for h(). The clue is in the name boundary conditions. A one-dimensional problem cannot have three boundaries. The 'conventional' third boundary condition for your case would be the first differential of h(), on either of the two boundaries, ie D(h)(0)=something, or D(h)(1.5e-06)=something else
3. Note also if your boundaries are defined by the arguments in the BCs, then you cannot use a range-value in the dsolve() command which lies 'outside' these boundaries - again the clue is in the name boundary

Not sure why you are using PLOT() rather than plot() - the former refers to the underlying dtata structure, which users are generally recommended not to play with.

However, leaving that aside, if I create a simple graph, and examine the undelrying data structure with

restart;
with(GraphTheory):
G := Graph(undirected,{{1,2},{2,3},{3,4},{4,1}}):
plottools:-getdata(DrawGraph(G));

I see a lot of 'polygon' definitions - but no indication of 'foreground' or 'background'

Suggest you provide an example of a graph which exhibits the behaviour you are concerned about - in other words it contains CURVES and POLYGONS and the undesirable foreground/background behaviour to which you refer: with an explanation of the foreground/background issue - as in what should be foreground? and why?

Values for g, vs, r, m0???

@Preben Alsholm 

Setting abserr=10¹⁰ generates "something" in Maple 18 but not in Maple 2016.

Setting abserr=10⁹ generates precision error even in Maple 18. Using the output from the abserr=10¹⁰ command as an 'approxsoln' for the case abserr=10⁹ also generates a precision error

My faith in the generated "solution" is not high.

so far as I know the Maple's numeric PDE solvers only allow you to calculate values of the dependent variables (not their partial derivatives) in terms of the independent variables. One can of course compute assorted expressions involving the independent variables - but not their (partial) derivatives.

I could be seriously wrong about the above - but if I continue the thought process assuming the above is correct.

Since the returned expressiono of the independent variables are essentially piecewise linear functions, I wouldn't want to go differentiating them. On the other hand could one generate some kind oif interpolating function (splines nayone?) through the returned data "points" and tnen differntiate - ugly as sin but might work I guess

So fundamental question to OP is that pdsolve() does not return derivatives of the dependent variables - so how you propose computing them??