@arctica1963 Your expression for Zsubload has an extra factor of "rho". Take out the (rhoload - rhowater) in front. Note that each term of the complicated coefficient at the end already contains a "rho" factor.

Just a guess, but do these formulae have to do with airplane radio interference caused by power transmission cables?

Is the x^0 term (the "constant" term) of the series supposed to set to zero also?

I see both uppercase Omega and lowercase omega in your formula, both always squared. Is that a typo, or do they represent different things?

That's an image, not plain text. Either upload a worksheet, or plain text.

@arctica1963

We can get a fairly close replica of the SCILAB plot like this: First, define a scaling function:

kscale:= k-> k/XKINT*0.001;

Then use this plot command:

plot(
   Zuncomp@kscale, 0..0.8
  ,labels= ["Wavenumber k (1/km)", "Free-air admittance"]
 , labeldirections = [horizontal, vertical]
  ,color = green, linestyle = dash
  ,view = [0..1, -30..80]
  ,axes = boxed, gridlines, legend = ["Uncompensated"], legendstyle = [location = top]
);

Note in particular that the first argument is Zuncomp@kscale. The `@` represents functional composition. Also note that the second argument, 0..0.8, is simply a range rather than variable= range. That is necessary because the first argument is now a function rather than an expression. In other words, it doesn't depend on k anymore. I got the 0.8 from the SCILAB plot. If for didactic reasons you need the upper limit expressed in terms of npts, then we can work on that. Let me know how it goes.

@arctica1963

We can get a fairly close replica of the SCILAB plot like this: First, define a scaling function:

kscale:= k-> k/XKINT*0.001;

Then use this plot command:

plot(
   Zuncomp@kscale, 0..0.8
  ,labels= ["Wavenumber k (1/km)", "Free-air admittance"]
 , labeldirections = [horizontal, vertical]
  ,color = green, linestyle = dash
  ,view = [0..1, -30..80]
  ,axes = boxed, gridlines, legend = ["Uncompensated"], legendstyle = [location = top]
);

Note in particular that the first argument is Zuncomp@kscale. The `@` represents functional composition. Also note that the second argument, 0..0.8, is simply a range rather than variable= range. That is necessary because the first argument is now a function rather than an expression. In other words, it doesn't depend on k anymore. I got the 0.8 from the SCILAB plot. If for didactic reasons you need the upper limit expressed in terms of npts, then we can work on that. Let me know how it goes.

@emma hassan I used your file and I was able to do the ImportData(). After selecting float[8](64-bit), on the next screen, Skip rows and Skip columns should both be 0. Then press Next. On the next screen, select Rectangular, then press Next. On the next screen, put in M for the variable name, then press Done. You'll be returned to your Maple worksheet, and you'll be able to issue the surfdata command.

@emma hassan I used your file and I was able to do the ImportData(). After selecting float[8](64-bit), on the next screen, Skip rows and Skip columns should both be 0. Then press Next. On the next screen, select Rectangular, then press Next. On the next screen, put in M for the variable name, then press Done. You'll be returned to your Maple worksheet, and you'll be able to issue the surfdata command.

Now we have three parameters: y, X, and T. Maple can give a parametric numeric solution, but in order to plot anything we'll need specific values for the parameters.

Also, you've used both x and t to represent the independent variable. That makes no difference to Maple, but it is sloppiness that makes your material more confusing for a human to read. Finally, y, X, and T are unusual letters to use to represent parameters. Again, it makes no difference to Maple, but without some context for why those letters are used, it causes confusion for the reader.

Now we have three parameters: y, X, and T. Maple can give a parametric numeric solution, but in order to plot anything we'll need specific values for the parameters.

Also, you've used both x and t to represent the independent variable. That makes no difference to Maple, but it is sloppiness that makes your material more confusing for a human to read. Finally, y, X, and T are unusual letters to use to represent parameters. Again, it makes no difference to Maple, but without some context for why those letters are used, it causes confusion for the reader.

@arctica1963 I'm sorry that I wasn't more specific about restart. Put the restart at the beginning of your document. It's a good idea to start all computations with restart, which erases all user-defined values from memory. It's like the "all clear" button on a pocket calculator. See ?restart. Where you have the restart now is erasing everything you just defined right before you try to plot it.

Let me know how it goes. I got the plot that you expect, except that the horizontal axis is from 0 to 512. Get the plot first, then we can rescale the axis.

@arctica1963 I'm sorry that I wasn't more specific about restart. Put the restart at the beginning of your document. It's a good idea to start all computations with restart, which erases all user-defined values from memory. It's like the "all clear" button on a pocket calculator. See ?restart. Where you have the restart now is erasing everything you just defined right before you try to plot it.

Let me know how it goes. I got the plot that you expect, except that the horizontal axis is from 0 to 512. Get the plot first, then we can rescale the axis.

In this case. the data are evenly spaced in both independent-variable dimensions, so the Matrix/GRID form of surfdata is more convenient than the listlist/MESH form.

In this case. the data are evenly spaced in both independent-variable dimensions, so the Matrix/GRID form of surfdata is more convenient than the listlist/MESH form.

Joe (and other experienced debuggers),

Try Inert:= ToInert(eval(soltn)). The result looks like the normal inert form of a procedure result from dsolve. Now do FromInert(Inert). The result is the literal symbol `invalid character in short integer encoding 70 F`.

The result is quite different if you use disassemble(eval(soltn)). Then you get an actual error message rather than a symbol: "Error, (in unspecified) Non-fatal error when reading data from kernel."

Joe (and other experienced debuggers),

Try Inert:= ToInert(eval(soltn)). The result looks like the normal inert form of a procedure result from dsolve. Now do FromInert(Inert). The result is the literal symbol `invalid character in short integer encoding 70 F`.

The result is quite different if you use disassemble(eval(soltn)). Then you get an actual error message rather than a symbol: "Error, (in unspecified) Non-fatal error when reading data from kernel."