Are there not infinitely many solutions, with x9 arbitrary and the others all zero?

What other ranges do you know, which have roots?

Download question1118_ac.mw

@AHSAN I don't see how you've explained anything. You get the same plot as before (in two ways) if instead you use the LHS of your eq1.

Help_Numeric_Solution_ac3.mw

Again, you don't need to "extract" the parts of the dsolve result to do that; the odeplot command handles such a formula automatically.

But now I've shown you one way with the extracted procedures from dsolve (correcting you attempt), and also two ways without having do do that more complicated approach.

All three produce the same plots. If that doesn't match your expectation for the plots then I suggest you look for another kind of cause.

For example: what is the role that you imagine to be played by the name x? You write of dpdx. But the independent variable in your differential equations is y. What exactly (and in proper detail, please), in your mind, is the relationship between y and x? I think that your posting is unclear on this.

Also, I've merely corrected your faulty substitution and the dsolve return. I'm just following your approach to the same dpdx formula -- except I've had to guess that the y vs x muddle because you haven't explained it. Perhaps you've made some miscalculation?

@Christopher2222 Setting Digits:=5 is a bad idea. Doing that in one's init file is a very bad idea.

One might use items like interface(displayprecision) instead (including that in an init file), although they're not quite as flexible as the Numeric Formatting.

I'm not sure that I completely understand your dpdx formula.

But, in terms of using the dsolve return and the parameter values, could the following be something like what you'e trying to accomplish!? You'll also need something like output=listprocedure along with your scheme of substituting the returned dsolve procs into the dpdx formula.

Help_Numeric_Solution_ac.mw

Note that odeplot itself is quite capable of accepting that dpdx formula without your having to manually substitute from the dsolve return. That substitution of the returned procs is not necessary, just to use those functions (in y) and their derivatives in odeplot. So here I just pass the straight formula involving derivative expressions (no extracted procs), which also means I didn't need to use listprocedure.

Help_Numeric_Solution_ac2.mw

Note that in both appoaches those new plots appear flat. You could check that aspect, the dpdx formula, etc. (What does "x" mean to you, in that context?)

@dharr I missed the manual re-insertion, sorry.

In my experience, combine brings constant factors inside an integrand, whilst simplify usually does the opposite.

(vote up, of course)

@dharr A negative sign seems to have disappeared.

(You might instead use combine(inte_eq) in the first step.)

@C_R Yes, the Java GUI can really struggle (in internal memory management?) with 3D animations that are modestly large.

Sometimes I've resorted to Explore, intsead. That command can animate, but only puts one frame at a time in the GUI's PlotComponent.

There's even a variant I've tried where I precompute all the frames up front, in a list L, and then Explore the frames L[i], w.r.t. a posint-valued parameter `i`. That parameter can be animated via an Explore option.

@sidyly1211 

Do you mean something like one of these?

enfonction_p_2_cas1_acP.mw
 

ps. If anyone's interested why I extracted the data for the curves from the 3D surfaces plot structure, instead of simply animating w.r.t. `t` the 2D plots of the original functions of `a`, my reasons are as follows: In Maple 2019 it was noticeably slower to do so. This has come up before, in some past discussion threads on this forum.

It is better to compute the values for all `t`, given each `a` value in turn. Picking a particular parameter `t` value and then asking the solver to compute the result at all `a` values can be markedly slower. That makes the solver repeatedly compute/throw-away the earlier (in time `t`) numeric DE results. There is a performance difference in the orderings in which `a` and `t` are used as independent variables here.

So, having constructed the 3D surfaces in the more efficient ordering, I then extracted the height data from the 3D plotting structures as a sequence of Vectors, to build the alternate ordering's 2D curves.

This approach can be faster without even striving for all optimizations (eg. I didn't even both to extract the data Matrix just once, up front).

Are you seeing this as new behavior?

If so, then were you seeing it before the Maple 2024.2 point-release? Etc.

This sounds like something for a bug-report, including worksheet, OS details, version details, etc. Try support@maplesoft.com

Could you not make a smaller edit to your original, rather than have two conditional branches in which X can attain?

F:=proc(X::anything,x::symbol)
    local la,y,n;
    if patmatch(X, (y::anything)^(n::'nonunit'(anything)) ,'la')
      and eval(y,la)<>1 then
        f(eval(n,la));
    else
        X;
    end if;
end proc:

@Scot Gould 

I started out just trying to mention that using odeplot is generally better that plotting extracted procedures/functions via the plot command. I'm pretty sure that that generally true, even if in practice it's just means that it's faster.

And then I digressed about the output choices, sorry! I'm sure there's no issue with our disagreeing about how hard or error prone manual use of the default output=procedurelist might be. Comparing those two output choices is a sidebar here.

I wonder whether it might be nicer if odeplot could use pi-ticks automagically on a relevant axis, say if either component of the "view" (eg. [x,y(x)] or [y(x),x)]) were simply the independent variable and the supplied range involved multiples of Pi.

@Scot Gould The dsolve,numeric command does not return a "solution module". That's not correct nomenclature, sorry. (It is pdsolve,numeric which does that.)

By default (output=procedurelist) it returns a procedure which when called with a numeric value then returns a list of the results.

Using output=listprocedure it returns a list of procedures which when each called with a numeric value return the corresponding result.

Extracting final values from either approach can be done using eval, with strong similarities. Eg, for a single value of the independent variable,

de := {diff(y(t),t,t)=cos(t),y(0)=1,D(y)(0)=0}:

solsPL := dsolve(de, numeric, output=listprocedure):

eval(y(t), solsPL)(2.4);
                        2.73739313285275

solLP := dsolve(de, numeric): # default output=listprocedure

eval(y(t), solLP(2.4));
                        2.73739313285275

One difference is that with output=listprocedure the extraction (eval) can be done just once (per dependent function), up front, and then utilized for multiple values of the independent variable. For some people that's an advantage, since in contrast the output=procedurelist return needs extraction (eval) for each value of the independent variable.

As for procedures which one could pass to the plot command and get the pi-tickmarks on the first axis due just to the choice of supplied range, well, that too can be done for either output form. It's only slightly more effort to build such a "function" from the dsolve return in the output=procedurelist case. But stand-alone procedures can be had from both approaches.

YPL := eval(y(t),solsPL):
YPL(2.4);
plot(YPL, 0..4*Pi);

YLP := s->eval(y(t),solsLP(s)):
YLP(2.4);
plot(YLP, 0..4*Pi);

I'm not sure that I understand why the latter of those might be taken as significantly harder to remember than the first. It's a little more effort.

Note that with either of these output choices the odeplot command will more generally produce a better plot, and more quickly, that will another plotting command such as plot. For the OP's simple example there may be no easily discernable difference.

So I would say that in general it is better to specify the pi-ticks in odeplot then it is to utilize the plot command and get any pi-ticks just be virtue of the particular supplied range.

There are some alternatives which deal specifically with each axis separately.

For the horizontal (first) axis,

  xtickmarks = piticks

or,

   axis[1] = [tickmarks = piticks]

See also the Help page for tickmarks.

I got the impression that this talk was by a member of a team that is working on enhancements to that package's functionality, and that the video is showing current results of that. In other words, it seemed to me like a report on current progress, which might have attained since the last major Maple release.

This supposition seems (to me) to be borne out by the speech and text appearing between 33:00 and 37:00 in the video.

ps. The presenter works with ORRCA, and there are tie-ins between that group and development of Maple's RegularChains, etc. This is one of a few research groups which contribute to Maple. It's quite common for such conference talks to show current development.

@Eunsang 

1) You write of problems when you make the step timestep too large. You also write of wanting, "higer [sic] spacestep". Are you sure that you don't mean smaller?

1) What is the specific desired spacestep that you want?

2) Do you know what timestep you want to use? Or do you just want the smallest timestep for which the computation is quick enough, when using your target spacestep? How fast is fast enough?

3) Are you seeing aspects in the plot that seem qualitatively wrong to you, due to, say, overly coarse step sizes?

4) You wrote, "I tried to find the optimal plotting points by adjusting the timestep while maintaining the desired spacestep...". What does "optimal plotting points" mean, exactly?

5) Do you have concerns about the scaling in your system, or suspect numeric difficulties due to inadequate working precision?

6) Your constant values contain floats like 0.33 and 3.14.  Are those coarse approximations of 1/3 and Pi? Do your have more accurate values for any of the floats and, if so, any reason not to use them?