I guess my point was that I would not expect eval to work with infinity, and I always use limit with infinity (for the reason that @sand15 mentioned: they are different things). Elsewhere in Maple infinity is handled slightly differently to mathematics, e.g., a*infinity is left as is until simplify(a*infinity) assuming a>0 leads to infinity. But I think this is fairly well thought out and generally doesn't lead to inconsistencies. Another principle that is often found in Maple is that if something is going to be fairly compute intensive it may not be done by default but you can force it with an option or another command. Here I do not think you want to overload eval with special cases since then writing efficient code for long calculations in a loop degrades performance.

@C_R @nm I guess with infinity it is safer to routinely use limit.

A workaround is to use expand

eval(expand((A*x-1)/x),x=infinity);

But it is hard to see any reason to get zero here. Many other places Maple gives sensible results with infinity. For example, infinity/infinity gives undefined, which would be a better result here than zero.

The fractional powers are very hard to deal with. I think you have to transform your ode to get rid of them

simplify(PDEtools:-dchange(V(xi) = U(xi)^3, Fode, [U(xi)])) assuming U(xi) >0

Of course if you really want V(xi) negative there is a mathematical problem about which cube root you want, but I'm guessing the equation was produced with the same disregard for rigor.

I'm struggling to understand the meaning here. It seems you want x=1 at t=0 since the units of the upper and lower limits should be the same and the integral should go to zero at t=0 (from the rhs). But in your approximation for x(t) you have ln(t) which implies you want t=1 to be the initial time?

In your mimimization you minimized t. Probably you meant to mimimize the integral of the squared difference over some range of t? 

Under my guessed interpretation, there is an easy solution:

intsolve.mw

These are not files listed on the File format help page, so you are out of luck for an easy way. I guess if you know the details of the binary file you could write a routine to read them, but I don't think that would count as "easy". 

Just installed 2026.0 in windows 11; run as administrator to install; didn't import previous preferences. All is working fine.

@KIRAN SAJJAN A quick look suggests it is reasonable, assuming the R1(z) and R2(z) functions are correct. I believe you said the BCs depended on z, but I do not see that dependence, though it might be implicit.

@Suryakanth @KIRAN SAJJAN You set up the odes for other conditions, so why not set up for different R or z and solve them? Sorry, I don't understand what you want.

@KIRAN SAJJAN Sorry, the equations you provided do not contain z, so I'm confused. Do you mean it is another independent variable, and you want to solve a PDE? (I don't want to read and figure out the paper.)

@WD0HHU This seemed to be fixed in 2025.2

@salim-barzani Use a set for the 3 plots otherwise it will think it is a parametric plot.

Dr.D-N.mw

You can directly use the procedure for w(eta) returned by dsolve to evaluate w(0.999) etc and the integrals.

parentartery_and_daughter_artery_error.mw

@salim-barzani That explains why odetest didn't work; the rest is OK. The sum of kinetic energy and potential energy should be approximately constant, not each separately.

You undoubtedly know some better numerical values for the parameters. Here the variation in energy is about 20%. You could also just plot the approximate solution and the exact solution (which you know?) together and see how they look.

Download u-1.mw

@salim-barzani Most equations look correct but odetest fails - maybe check some assumptions or try some numerical checks, or maybe the theory doesn't work.

Download u-1.mw