## 18245 Reputation

14 years, 243 days

## and so...??...

The 3D surface is defined by two variables x and t. So what is left in that, to vary from frame to frame of an animation?

Look at the title of your own Question. It says "1D wave". How do you expect to animate that in 3D? The surface I showed is not a snapshot of a 2D wave in two spatial dimensions -- it is a 2D surface made by extruding a 1D wave over variable t.

As I mentioned, you could vary the number of terms in the sum (say, n terms in the summation), but it might converge too quickly for that to be meaningfully animated.

You continue to be exceptionally vague about what you want.

## updated...

I updated my previous comment to animate the 2D curve superimposed on the 3D plot.

If that's not what you mean, then you'll have to explain properly how you think that a 3D figure can ne animated here.

Is it because you want to animate with respect to n!?

So far, you haven't been clear about what you want.

## 3D...

You didn't mention 3D earlier.

Using the same code as before,

plot3d( sol15, x=0..1, t=0..2 )

Also somewhat fun,

```restart;
L:=1: c:=2: g:=0:
f:=(8*x*(L-x)^2)/L^3:
pde:=diff(u(x,t),t\$2)=c^2*diff(u(x,t),x\$2):
bc:=u(0,t)=0,u(L,t)=0:
ic:=u(x,0)=f,D[2](u)(x,0)=g:
sol:=pdsolve([pde, ic, bc],u(x,t)):
sol15 := rhs(subs(infinity=15,sol)):
tfinal := 2.0:
bg := plot3d( sol15, x=0..1, t=0..tfinal, transparency=0.5 ):
d23 := (p,T) -> plottools:-transform((X,Y)->[X,T,Y])(p):
mk3 := T -> d23(plot(eval(sol15,t=T), x=0..1,
color=red, thickness=3), T):
plots:-animate(mk3,[T],T=0..tfinal, frames=50,
background=bg, orientation=[-20,70]);
```

[edited, 17/04/2020] Or, another. I know, I know, this is not constructed efficiently. I do prefer using plot with its adaptive plotting instead of spacecurve. But still it would be more efficient to build up the surface as row upon row computed inplace on a re-usable Matrix passed to surfdata, and the rendered surface would appear more stable visually. Maybe when I get a little time.

```restart;
L:=1: c:=2: g:=0:
f:=(8*x*(L-x)^2)/L^3:
pde:=diff(u(x,t),t\$2)=c^2*diff(u(x,t),x\$2):
bc:=u(0,t)=0,u(L,t)=0:
ic:=u(x,0)=f,D[2](u)(x,0)=g:
sol:=pdsolve([pde, ic, bc],u(x,t)):
sol15 := rhs(subs(infinity=15,sol)):
tfinal := 2.0:
d23 := (p,T) -> plottools:-transform((X,Y)->[X,T,Y])(p):
mk3 := proc(T)
plots:-display(
d23(plot(eval(sol15,t=T), x=0..1,
color=red, thickness=5), T),
plot3d( sol15, x=0..1, t=0..T,
style=surface,
grid=[49,5+ceil(45*tfinal/(max(1,T)))] ));
end proc:
plots:-animate(mk3,[T],T=0..tfinal, frames=100,
orientation=[45,70]);```

The following constructs more efficiently (although it could easily be made even more so, by ripping the spacecurve data from Array AA instead of recomputing it, forming AA by layer without the nested `if`, etc). But the animation now gets constructed fast enough. (I could make it construct this animation yet ten or more times faster, but one would hardly notice as it's already quick. But the GUI would just get overwhelmed playing it, if such improvements in the construction speed used to build it with far more resolution or frames.) A more important improvement here is that the surface drawn "so far" doesn't change from frame to frame, even when the wireframe lines are included.

```restart;
L:=1: c:=2: g:=0:
f:=(8*x*(L-x)^2)/L^3:
pde:=diff(u(x,t),t\$2)=c^2*diff(u(x,t),x\$2):
bc:=u(0,t)=0,u(L,t)=0:
ic:=u(x,0)=f,D[2](u)(x,0)=g:
sol:=pdsolve([pde, ic, bc],u(x,t)):
sol15 := rhs(subs(infinity=15,sol)):
(xa,xb,ta,tb):=0,1,0,2:
M,N := 49,85:
d23 := proc(i::posint, N)
plots:-spacecurve(eval([x, t, sol15],t=ta+(tb-ta)*(i-1)/(N-1)),
x=0..1, numpoints=M, color=red, thickness=4):
end proc:
AA:=Array(1..M,1..N,1..3,(i,j,k)->
evalhf(`if`(k=1,xa+(xb-xa)*(i-1)/(M-1),
`if`(k=2,ta+(tb-ta)*(j-1)/(N-1),
eval(sol15,[x=xa+(xb-xa)*(i-1)/(M-1),
t=ta+(tb-ta)*(j-1)/(N-1)])))),
datatype=float[8]):
mk3 := proc(i,N) local temp; uses plots;
temp := d23(trunc(i),N);
if i=1 then temp;
else display(temp,surfdata(AA[..,1..trunc(i),..]));
end if;
end proc:
plots:-animate(mk3, [i,N], i=1..N, frames=N,
orientation=[45,70], paraminfo=false);```

## example...

Please include a complete example, eg. a worksheet as an attachment uploaded using the green up-arrow in the Mapleprimes editor's menubar. Please include an example of the data, if necessary to execute.

note. Presumably your Maple version is at least as recent as Maple 2015, in which the dataplot command was introduced. If not then examples could still be dispatched to other plotting commands.

## right...

@Kitonum Right, that's exactly what I was suggesting. (It was done previously, in a couple of those old postings which I linked to in my Answer.)

## misunderstood...

@digerdiga You've misunderstood the key point (which is probably my fault for not explaining myself better, sorry).

Of course we can program the operation to convert wrt some key prime factors in the denominator, as Kitonum showed. That is of course very simple to do -- so simple that I deliberately focused instead on the more generally applicable question.

If you know how to handle a particular example then you may build a re-usable identity. We all know various half-angle and double-angle formulas (and can apply in a compound manner). The example you gave is trivial to do.

But if you also want to be able to handle cos(Pi/17), cos(Pi/(3*17)), and other examples then you're better off with a way to generate conversion identities (or an efficient re-usable mechanism) that could then be later applied (and compounded if need be).

Sure, such formulas or a mechanism may only need to be generated once, and stored. But one needs to know how to do that.

More general rules for convert(...,radical) can be constructed. I think that's far more interesting that handling the original example by trivially iterating a formula that is already well known.

## comment...

@Carl Love In my opinion this is not great general workaround, for a few reasons.

It forces the value to be computed and returned, getting in the way of further programmatic use of the inert sum form. Eg, following natural use of simplify or expand on a larger expression that merely contains the inert sum. And it can take measurably longer than value (even if that's an acceptable result).

So, rather than being a workaround for simplifcation -- even if that were just a "no-op", and the original text suggests that is acceptable here --  it seems like a way to accidentally force a slower value computation.

And doesn't help deal with some related tricky cases with symbolic end-points.

But, who knows, perhaps it will serve the OP's purposes -- in which case, OK.

## original attachment...

Somebody removed the original attachment on this Question.

It is here: copy1.mw

## typo...

@JAMET You have,

found=false

found:=false

as Carl had in his code.

@anthonyfl   I learned through study, experimentation, and practice.

## attaching...

@wswain In the popup dialog, you can:
3) close using the "OK" button

## importmatrix...

If you used ImportMatrix from a csv file (as the tags suggest) then your Matrix accidentally have some nonnumeric entries.

But you have not attached any actual data file, or a worksheet that shows how you imported it, so we cannot tell what might be wrong.

You can use the green up-arrow in the Mapleprimes editor, to upload and attach files here. You could put data files such as .csv into a .zip file and upload that.

## h...

@Kitonum What about making h be a function of 4.0 and the number of frames? Do you want to avoid overlaps or gaps? Perhaps your h=0.15 was intended as h=4.0/60=1.0/15=0.066... instead?

As given (with h=0.15 and frames=60 and the range of x) I don't see how the overlap could be ok, since the total volumes of the shells/washers is high.

It might also be nice to allow a midpoint/low/high choice.

 Here is an attachment showing that using option grid=[2,49] (for the plot3d constructions of the 3D extruded annulus) saves about 60% of the size of these animations. This also improves GUI responsiveness while playing. annulus_grid.mw

## thanks...

@Anthrazit I see, thanks. You may well have good reasons for wanting to use tables as the data structures, further down the line. And if using trunc gets you the conversion you want then great.

If your example is just a downsized sample, and you'll actually have much larger examples then you want to consider refactoring some of that processing code so that it scales up with good performance. Much of it could be done with a few passes through the data, eg. more efficiently using seq rather than repeatedly building up sets, etc.

## recent past...

@mikerostructure I was trying to ask about whether the problematic machine had recently undergone an OS update where before it worked and after it didn't. (I wasn't asking about all recent updates where behavior remained the same, or whether any update done now would affect it.)

Sorry, I don't understand what you are saying about a colleague's machine. Are you saying that he too can (as of recently) no longer right-click export even simple plot3d examples from either Maple 2019.2 or Maple 2020.0? Or are you describing mixed circumstances and results, using various examples. It's not clear to me what you are describing, sorry.

 5 6 7 8 9 10 11 Last Page 7 of 414
﻿