@zenterix I think @C_R has the solution for the g=1 case, which was just your test case. For the physically realistic case of g>1, it can be done via the symbolic solution. But for numerical integration I think it has to be non-dimensionalized along @C_R's lines ,since V^g is problematic with g=1.1 - see end of worksheet.

Edit: updated to correct incorrect assumption about temperature

adiabatic.mw

Edit: like many derivations the derivation of P*V^g = k involved raising something with units to a non integral power, which is the root cause of the problem here. So probably the derivation can be improved by adding some variables that are just there to cancel the units, e.g., (V/V0)^g with V0 = 1 m^3, similar to @C_R's treatment . But then of course V0 will pop up somewhere else in k.

@salim-barzani OK, I think I understand. 

same_equation_different_parameter2.mw

@Scot Gould Yes, I find this sort of thing frustrating and have to rediscover it frequently when I want an unsual data structure. I think as a rule, Arrays are more permissive about what you put into them, but for Matrices and Vectors, elements that are Vectors/Matrices/lists get incorporated into a single Matrix/Vector of numbers/symbols.

In Maple 2024, I get a warning "Warning, units problem, not enough information to unambiguously deduce the units of the variables {V, n}; proceeding as if dimensionless"

in the integration limits you have n times a unit being a volume, which seems strange. Do you mean something like V = n*V1..m*V1 where n is dimensionless and V1 is a volume. Or did you mean n and m to have values before the integral? 

plot3d(-x^2/9 + y^2/4, x = -5 .. 5, y = -5 .. 5)

Do you mean surface? Do you want the shortest path on the surface?

@salim-barzani I believe you forgot to apply the chain rule in the part you did by hand. Here is a corrected version that verifies with pdetest on the original equation.

f12.mw

@dharr I am trying to understand how you get from the pde to the ode. I can't get Maple to do this so I am wondering if there is some hidden assumption here that needs to be specified. If so, that may be why pdetest fails. Or the solution may not be correct.

pde-solve2.mw

As others have already asked you to before, please upload your actual worksheet using the green up-arrow in the Mapleprimes editor (not just an image.) That way, we don't have to retype your input, and you may get a better response.

@mmcdara Nice analysis. Vote up. No, I don't have the GlobalOptimization toolbox.

@Ariathm It might be finding the wrong local minimum. In non-linear least square problems like this getting the initial guess values close to the right answer is key to success, and I might have chosen some bad values.

I noticed p__eng is strangely like p__3 but not quite. Perhaps it is better to calculate these in Maple from some earlier expression, rather than enter them by hand. Especially if you have some form without the fractional powers, it will help.

@dharr The long calculation has probably to do with the difficulty of finding derivatives for the horrible expression. The following simplifies the expression enough that it proceeds to a solution. I used simplify(..,symbolic) to get rid of the fractional powers. In principle that can give invalid results, but here I think it is probably OK since everything is positive, but you should check that the answer makes sense. Note that the kappa value found is at the end of the range.

test2.mw

Looks OK, given that kappa is not correct yet

test3.mw

The error message is "Error, (in fsolve) {delta[0], y[0]} are in the equation, and are not solved for", and indeed you have not given values for delta[0] or y[0].

For future reference, it is easier if you upload your worksheet using the green up-arrow in the Mapleprimes editor.

@michele Since you now get the same answer, you and I are now almost certainly checking the same polynomials, so the ratios between our times is now meaningful. For other polynomials the time will be different,, e.g., after running the worksheet, go back to the execution group with p:= etc and hit enter, then enter on the CodeTools:-Usage line and your answer will have x^25268 in and the time will be about 50% longer. If you choose 2 polynomials with gcd = 1, the times will be significantly longer.

Bottom line: it depends on the polynomials.

@michele I'm just worried that for different versions of Maple, different number of random numbers might be used, leading to a diffferent answer for later calculations, even if the first one, r, is the same. An across-versions comparison might need to save the actual polynomial to an .m file and the read them in. That seems like overkill, so try running this to see if you get the same answer, and then the timing comparisons might make more sense.

Edit: 13th Gen Intel(R) Core(TM) i5-1335U   1.30 GHz; 16.0 GB RAM, in "best performance" mode.

Download gcd.mw

@michele The version of Maple could make a difference here, and the exact random numbers might not be the same (which seems to be the case in the second example because a different answer is obtained). Different polynomials might take different times so unless you average a lot of examples, it is hard to know what an average time is. So for the class polynomials you are using these might not be typical.

So are these results not acceptable to you? You are getting answers without crashes for what I would call large degree polynomials. Your CPU and real times are the same suggesting only one CPU, and perhaps an older computer without multiple cores?