@nm 

ALso Student:-ODEs:-ODESteps() works only on ode's, Burger's equation is pde. If you mean the same one as here

(Stange that Mapleprime will not let me edit my reply above. Clicking on more does not work. Something is wrong with Mapleprimes now. May be software update went wrong).

Unfortunately, I am unable to share the worksheet I made. 

well, you could always copy and paste the code. 

Anyway, if you mean Student:-ODEs:-ODESteps() on Burger's ode, then you are out of luck. ode step by step in Maple in limited to basic differential equations only.

maybe I misunderstood you. Why can't you use the seq command? something like

the_sequence:=seq(n*Pi/8,n=0..16);

plots:-animate(plot, [sin(x + C), x = 0 .. 2*Pi, thickness = 3], 
               C = [the_sequence], 
               background = G, 
               labels = ["", ""]
               )

@ 

Update:

per comment below, need to use this syntax:

           FeynmanIntegral(integrand,[[p__1],[p__2],[p__3]])
 

old answer

I have not used FeynmanIntegral but you can always integrate it one at a time instead of passing a list for the integration variable which FeynmanIntegral does not like the list form for multiple integration.

Something like this

Download feynman_march_9_2025.mw

But notice the messages it generated `Expected denominator with factors quadratic in `*p__2*` representing propagators; received the factor(s)`

That is something to look into.

This has nothing to do with Latex. Maple rewrites things itself, (based on some internal representation it chooses how to arrange terms when it stores things in memory) and that is what you see on the screen.

Latex relfects what you see on the screen, not how you type the expressions.

Example. When you type

R:=exp(x+L*y+r*z)

Maple replies with 

See? your x is no longer the first term as when you typed it in. The Latex is based on the above output (i.e. the internal representation)

This happens with other CAS systems also, not just Maple:

is the output in English when you type "dir C:" in windows command window? if not, then this is windows own configuration issue and nothing to do with Maple. Maple just gives you what the windows command gave.

This looks like a bug in Maple own code somewhere. 

@acer 

Yes, Mint now show 

 These local variables were not declared explicitly:  sol

But unfortunatly, can't use your workaround in actual code, since proc() now is not called, since it is mapped to empty list.

I think now mint is wrong here.

Here is proof:

Maple itself, gives warning that `sol` is implicitly declared local  but mint does not. This is foo.mpl:

foo := proc()
    local C1,y,x;

    proc()
         sol:=y(x)=  C1;
         print("In  anonymous");
    end proc();

end proc:

foo();

This is what mint says

Procedure foo() on lines 1 to 9
  These local variables were never used:  C1, x, y

No mention of sol !

But this is what Maple itself says when I actually run foo.mpl:

>"C:\Program Files\Maple 2024\bin.X86_64_WINDOWS\cmaple.exe" foo.mpl

Warning, (in anonymous procedure within foo) `sol` is implicitly declared local |foo.mpl:5|

> foo();
                                                                                 "In  anonymous"

You see? Maple gave warning. Maple is correct by giving warning that sol is not declared. But this is something that mint should also have done. After all, that is what mint is supposed to do.

Do you think this is a bug in mint then? I have not reported this yet. 

@acer 

The name sol is implicitly declared local within that anonymous procedure

Does this mean semantics of anonymous procedure  is different than named one when it comes to local variables? Because on named proc, mint gives this

foo := proc()
local C1;
local y,x;

    C1:= `tools/genglobal`(_C); 
    sol:=y(x)=  C1; 

end proc;

This is mint output

Procedure foo() on lines 1 to 8
  These global variables start with an _:  _C
  These local variables were used but never assigned a value:  x, y
  These local variables were assigned a value, but otherwise unused:  sol
  These local variables were not declared explicitly:  sol

Notice it says These local variables were not declared explicitly:  sol 

I think this is what I meant, i.e. mint should warn the user, whether this line of code sol:=y(x)= C1; is inside anonymous procedure or outside, about sol not being declared. It would be better to do so.

btw, I always declare local variables that I use, even inside anonymous procedure. But use mint to detect places where I forget to do so.

@mmcdara 

Here is an example, where I just now wanted to check if solution of ode has form    A*ln(y)=B*ln(x)+C, where here C is constant of integration. By hand we rewrite this by raising both sides to exponential giving   y^A=C*x^B. But wanted to do this only of the solution has this pattern with A,B not ln and no other form. Normally A,B will be constants, but ok to be functions, but not has ln.

For me pattern matching was the most logical way to do it. I can't just raise both sides to exponential for other pattern directly, else it will mess up the solution form.

May be there is a way to do this using structured types such as evalidents and such commands, I do not know, if there is, it will probably be more complicated.

So here is a quick proc that does this. Ofcourse, I need to test this more, I just wrote it in 30 minutes. but this is just to give the idea.

Download pattern_matching_use.mw

@acer 

I am ofcourse can't be sure it is cache/memory problems. It is just an educated guess based on earlier problems I had. For example Why-Odetest-Sometimes-Works-And-Sometimes. But will change the wording to say I think it can be cache issue.

I also said in one of the update the following

So there is something else that causes this. If someone can suggest other things to try, that will be great.

The "else" above refers to clearing memory tables and cache.

@aroche 

Could you please look into Bug-Report-Order-Of-Using-Odetest-Changes

I find big problem. With Physics 1840 it works OK. Starting with Physics 1841, it fails. By works and fails, I mean using odetest to verify an ode. 

Please look at the bottom of my question above and you will see two worksheets showing clearly this. The one using Physics 1840 works. No timeout and odetest returns zero. When changing to Physics 1841, with same exact code, now it gives timeout and fails.

All on windows 10, Maple 2024.2

If you like me to try something else, feel free to let me know. 

@Arya-S-AA 

To find degree of ode see Finding-Order-And-Degree-Of-ODE-In-Maple

@Arya-S-AA 

I assume you are asking about the error you got at end of your worksheet. This has nothing to do with  LambertW. The solution dsolve returns is called expression squence. When you type sol:=dsolve(...) and it returns  A,B,C as solutions, you can't do odetest(sol,ode). This will give an error, and that is what you had. odetest(....) expects ONE solution at a time. Not sequence of solutions.

You need to do something like map(X->odetest(X,ode),[sol])

And now it works. Attached worksheet for your last example which had the error

Download using_odetest.mw

how define order and any other topic related to ode

To find the ode order, use the command PDEtools:-difforder(ode) like this

ode:=diff(y(x),x$3)+ x*diff(y(x),x)+sin(x)=0; 
PDEtools:-difforder(ode)

This gives 3.

@dharr 

Numerically, may be yes, and for that specific value of a=1/2 you picked.

But analytically, and for any a, the ode solution that dsolve gives, does not give a solution for C1 when plugging in these initial conditions.

Maple gives two general  solutions to this ode, and it can't solve for the C1 from either one.

Also tried using limit. It just can't resolve the C1 constant from these IC.

Download no_solution.mw