5199 Reputation

9 years, 245 days

You will note...

This is the same error message which I obtained in a earlier post - and I suggested why this error message might occur. Try reading my earlier post

Using Matlab or Maple?...

Questions on this site only get an answer in Maple code. If you want an answer in Matlab code, then post on

If you have a Maple problem in Maple code, then post the code here

why is this posted here?...

"fminsearch" is a Matlab command to "Find minimum of unconstrained multivariable function using derivative-free method"

Why are you posting Matlab problems on a Maple forum??

"Exactly what is the problem???"

Your answer that " I think time-series result ( i mean graph) is incorrect?" isn't making it!!

On what mathematical basis do you think the solution provided by Maple is incorrect??

When I look at the 3D result provided by Maple, ie C(x,t) as a function of x and t, the only thing that looks  *slightly* suspicious is the region around C(1,0). The value at C(1,0) is forced to be 1 by the supplied ICs/BCs, but this value changes very rapidly (one might almost say "discontinuously") as (x,t) move even slightly from (1,0). This would make me double-check whether the relevant boundary/initial condition is "correct"

Otherwise I see no reason to doubt the result which Maple provides

Observation...

The code in the image you supply is "cheating" becuase the expressions you supply for 'c' and 'd' mean two completely different things, and are certainly not equivalent

See the attached

 >  (1)
 >  (2)
 >  (3)
 >  (4)
 > # # Convert the above to 1-D input for illustration # # Note that the code contains the variable 'names' # ui and uf, but also the 'functions' ui() and uf() # with arguments (1/lambda^2). # # Maple consider the name 'ui' and the function 'ui()' # to be two completely different entities # # The function definitions occur because there is # no multiplication (explicit or implicit) in a # subexpression like ui(1/lambda^2) # # Check what happens when these multiplications are # added #   d := ui*delta*ui(1/lambda^2) - ui*delta*uf(1/lambda^2) - uf*delta*ui(1/lambda^2) + uf*delta*uf(1/lambda^2);   d := ui*delta*ui*(1/lambda^2) - ui*delta*uf*(1/lambda^2) - uf*delta*ui*(1/lambda^2) + uf*delta*uf*(1/lambda^2);  (5)
 >

Observation...

"You could try testing whether StringTools:-Search returns a result greater than 1."

I think I'd check whether StringTools:-Search returns a result greater than 0

Errrrr...

Is the random selection of symbols in the worksheet you supply intended to do anything useful?

If so: what, exactly?

Like this...

which is (more-or-less) a combination of the two worksheets I have previously supplied

 > restart;
 > with(geometry):
 > # # Define the sidelengths #   sa, sb, sc, ab, bc, ac:= 3,5,7,3,4,5:
 > ####################################################### # Define three points which will become the base triangle. # # Without loss of generality one can specify # # 1. point A2D is at the origin # 2. point B2D is along the +ve x-axis # 3. point C2D is in the x-y plane, with positive #    y-coordinate #   point( A2D,          [0, 0]        ):   point( B2D,          [x__b, 0]        ):   point( C2D,          [x__c, y__c]        ): # # Using the given side lengths, solve the distance # equations, to obtain (and assign) the unknown # coordinates x__b, x__c, y__c #   sol:=  assign          ( solve           ( [ x__b > 0,               y__c > 0,               distance(A2D,B2D)=ab,               distance(A2D,C2D)=ac,               distance(B2D,C2D)=bc             ]           )         ):   triangle(T1, [A2D,B2D,C2D]): # # Get the circumcircle for the triangle and generate # the directed line segment between the centre of this # circumcircle and the origin #   circumcircle(cc2d, T1):   dsegment( ds,             point             ( CS,               coordinates               ( center                 ( cc2d                 )               )             ),             point             ( O2,               [0,0]             )           ): # # Translate the circumcircle so that the centre # is at the origin. Translate the triangle by the # same amount #   translation( cc2d_trans,                cc2d,                ds              ):   triangle( T1_trans,             [ translation               ( A2D_trans,                 A2D,                 ds               ),               translation               ( B2D_trans,                 B2D,                 ds               ),               translation               ( C2D_trans,                 C2D,                 ds               )              ]           ):   draw( [T1_trans, cc2d_trans]); # # Convert the coordinates of the triangle in 2D # to 3D, just by adding a '0' for the z-coorcinate. # These coordinates will be used later # # Unload the geometry package, ready for loading # the geom3d package #   cA:=[coordinates(A2D_trans)[],0];   cB:=[coordinates(B2D_trans)[],0];   cC:=[coordinates(C2D_trans)[],0];   unwith(geometry):    (1)
 > with(geom3d): # # Specify the coordinate system #   _EnvXName:='x':   _EnvYName:='y':   _EnvZName:='z': # # Define the points for the tetrahedron. Note that # the coordinates for the points A, B, C are obtained # by solving the 2D problem above #   point(A, cA):   point(B, cB):   point(C, cC):   point(S, [xs, ys, zs]): # # Using the supplied distances, solve for the coordinates # of the "unknown" point S #   sol:=  assign          ( solve           ( [ zs>0,               distance(S,A)=sa,               distance(S,B)=sb,               distance(S,C)=sc             ]           )         ): # # Define a general tetrahedron based on the points A, B, C, S # where by construction A,B,C will lie in the x-y plane, and # the origin will be the centre of the circumcircle of the # triangle ABC #    gtetrahedron(tet,                 [A,B,C,S]                ):    draw(tet, axes=boxed, scaling=constrained);    detail(tet);  (2)
 > # # The four points A, B, C, S of the tetrahedron generated # above all lie on a sphere. Generate this sphere #   sphere( S1,           [A, B, C, S],           centername=c1         ): # # Produce the directed line segment between the centre of # this sphere and the origin #   dsegment( ds1,             [ point(T, coordinates(c1)),               point(OO, [0,0,0])             ]           ): # # Translate the sphere above to the origin. # Translate the embedded tetrahedron by the sam amount #   translation( Ttet, tet, ds1):   translation( S2, S1, ds1): # # Output details of the translated tetrahedron and sphere # Note that this construction is not unique. Any rotation # by any angle about any of the 'x', 'y', 'z'-axes is # equally valid #   detail(Ttet);   detail(S2); # # Draw both #   draw( [ Ttet(color=blue, style=surface),           S2(color=red, transparency=0.8, style=surface)         ],         axes=boxed,         scaling=constrained,         labels=["x", "y", "z"],         labelfont=[times, bold, 16]       );   >
 >

Observation...

This OP's questions have a habit of "disappearing" after answers has been posted

Clarification required...

In an undirected graph with three vertices A, B, C and two edges AB, BC, the "longest" path is obviously infinite!. One just follows the route A->B->A>B->A>B->A>B->A>B->A>B->A>B->A>B........infinite times......->C

A similar arguemnt can be applied to the term "longest" cycle.

So what exactly do you mean by "longest path" and "longest cycle"

More of an observation really...

It seems possible to generate at least two "different" answers for this problem - see the attached
I have no idea which is correct (except that I agree the answer cannot be negative)

 > restart:
 > with(Statistics): X := RandomVariable(Normal(1, sqrt(2.25))): int(PDF(X, x)*Heaviside(x^7-5*x^4-3*x+1), x = -infinity .. infinity); (1)
 > evalf(Int(PDF(X, x)*Heaviside(x^7-5*x^4-3*x+1), x = -infinity .. infinity)); (2)
 >

Observation...

Same problem with the variable 'f', which is used in both indexed and un-indexed form

One really should never use a simple variable name (liek 'f' or 'theta') and indexed versions of the same names like (f[i] or thets[i]) and expect these to be "independent" - they are not

Some observations...

although I admit that I am seriously confused

1. In the attached, without using the 'method' option, I can actually produce a 3-D plot for v(x,t) which does not seem to exhibit the same numerical oscillation - although if I then produce the 2-D slice along v(0,t), then the numeric oscillation "reappears"
2. If I had known that I could invoke an "Euler" method, then I probably would have tried this to investigate numerical oscillation. This is based purely on some half-forgotten(?) idea that many numerical methods for solving ODEs/PDEs are "underdamped" and produce errors of alternating sign at adjacent solution points - which looks like oscillation. However "Euler" methods tend to be overdamped and produce errors of the same sign at adjacent solution points - which doesn't look like oscillation
3. The documentation about use of the "default theta methods" is non-existent

Anyhow for what it is worth

I solve a boundary value problem for a linear system of first order PDEs
in the unknowns and Ultimately, I am interested in the graph
of the function but numerical artifacts distort that graph badly by
imposing spurious oscillation.

Is there a way to maneuver the calculations to obtain the graph of without the oscillation?

 > restart;
 > pde1 := diff(u(x,t),t)=diff(v(x,t),x):
 > pde2 := diff(u(x,t),x)=v(x,t):
 > ibc := u(x,0)=1, u(0,t)=0, u(1,t)=0:
 > # # Rouben's original calculation. # # The "solution" for v(x,t) certainly appears to have # numerical artefacts close to the boundaries v(0,t) # and v(1,t) #   dsol1:= pdsolve( {pde1, pde2},                    {ibc},                    numeric,                    spacestep=0.01,                    timestep=0.01                  ):   dsol1:-value(output=listprocedure):   my_u := eval(u(x,t), %):   my_v := eval(v(x,t), %%):   plot3d( my_u(x,t),           x=0..1,           t=0..0.5         );   plot3d( my_v(x,t),           x=0..1,           t=0..0.5         );   plot( my_v(0,t),         t=0..0.5       );   > # # Nothing wrong with Rouben's approach above, but *by default* # I would have generated these plots in a slightly different # way. I do not consider that this involves "solving" the PDE # system in a different way, just a slightly different method # of accessing/ displaying the results. # # In the 3D-graph of v(x,t), this approach does not appear # to exhibit the same numerical oscillation close to the # boundaries v(0,t) and v(1,t). # # However if one explicitly plots v(x,t) for x=0, then the # numerical artefacts "reappear"!!! Why is the 2D-plot so # different from the same "slice" of the 3-D plot? #   dsol1:-plot3d( u(x,t),                  x=0..1,                  t=0..0.5                );   dsol1:-plot3d( v(x,t),                  x=0..1,                  t=0..0.5                );   dsol1:-plot( v(x,t),                x=0,                t=0..0.5               );   > # # Code suggestion from Allen Wittkopf # # (1) The pdsolve/numeric help page does not even list #     a 'method' option # # (2) The pdsolve/numeric/method help page refers to #     "the default theta methods", but does not explain #     how these may be accessed or controlled # # (3) The pdsolve/numeric/method help page provides #     details of other methods, but claims that these #     are "restricted to a single parabolic/hyperbolic #     PDE  that is first order in time" # # (4) The help page # #     ?Numerical PDE Methods Available for pdsolve/numeric # #     gives descriptions of the "other" methods referred #     to in (3) above, but no discussion of "the default #     theta methods" # # Anyhow just adding the option method=theta appears # to improve things, but I have no idea why   dsol2:= pdsolve( {pde1,pde2},                    {ibc},                    numeric,                    spacestep=0.01,                    timestep=0.01,                    method=theta                  ):   dsol2:-plot3d( u(x,t),                  x=0..1,                  t=0..0.5                );   dsol2:-plot3d( v(x,t),                  x=0..1,                  t=0..0.5                );   dsol2:-plot( v(x,t),                x=0,                t=0..0.5              );   >
 >
 >

-infinity

seems redundant, given a<-1. The following just "works"

restart;
solve({a < -1, -1 < b ,  b < 0});

{-1 < b, a < -1, b < 0}

Am in UK...

So looks like we might not be in EU for very long!!

﻿