Dr. David Harrington

5804 Reputation

21 Badges

19 years, 242 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

Maple Application Center
I am a professor of chemistry at the University of Victoria, BC, Canada, where my research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity

These are replies submitted by dharr

@Joe Riel My mistake; I intended them to be the same size. (Usually I test and upload, but since Matrix output from Maple 2024 is not correctly rendered on Mapleprimes, I got lazy)

@goebeld The extend command was for older style matrices in the linalg package. These are no longer used (deprecated) as the help page tells you. Older matrices used "matrix", current ones use "Matrix" and commands in the LinearAlgebra package;

The brackets are entered with the < "less than" and > "greater than" keys, even though they display slightly differently. The objects produced are exactly the same as those from Matrix

The best way to extend a Matrix with zeros is probably just to embed it in a larger Matrix of zeroes.

XX := Matrix(2, 4, [[1, 1, 1, 1], [2, 2, 2, 2]]);
X2 := Matrix(5, 6); # Matrix of zeroes
X2[1..2,1..4] := XX:


@Scot Gould extend is in the old linalg package, so extend(XX,1,0,0) added 1 row and 0 cols of values 0, .i.e, a row of zeros.

@akbarhp As I said, the a(n,j):=coeff(eq[n],A[j]): line gives an error for n=6 and j=9 because coeff didn't work on eq[6], which contains an expression containing the word constcoeffsols, suggesting that constcoeffsols earlier in the code did not work. This is the same error message in the version you posted above. So you need to take a look at the printed out eq[6] and see if there is something being passed to constcoeffsols that doesn't look right. Or since the other ones worked, mabe this one is just too hard for constcoeffsols.

- if so you could just run the code up to n=5,j=5 and see if the code give sensible output for that smaller problem.


Using more Digits than you need is poor practice, since it slows everything down, makes output hard to read, and you almost never need that accuracy. If you really, really, really need that accuracy, use it only after your code runs and you find you have accuracy issues.

Is n supposed to be an integer? Then use n:=2 and not n:=2.0. Note that you set X[n]: =  1.0, but then you use X[2], which is not 1.0. X[2] and X[2.0] are not the same. In general, avoid decimal points if you want an exact value. 

To create entries in a Matrix a, use a:=Matrix(16,16); before your loop, then assign the coefficients in the loop by


then you just need  Alanda := simplify(a);

(I left this.)

If I add print(n,j) before the line 


I find if fails after n=6 and j=9.

So I now do

if n=6 and j=9 then print(n,j,eq[n],A[j]) end if;

then the long expression for eq[6] contains "constcoeffsols", meaning that that command did not work.

I suppressed the long output; commented out Digits:=100; and closed off the opening part of a procedure that wasn't completed in one execution group. At least in Maple 2024, it runs without any error messages. Perhaps you could provide a similarly shortened (without many pages of output) worksheet that shows the actual error message you describe.


@acer I'm not sure I understand your point. The OP knows the matrix MM, having set it above in the code but didn't name it. So I'm assuming the definition of MM would be made before its first use. Presumably the OP knows eq13 is of the form v = MM %. v1 - MM %. v2, and wants it in the form v = MM %. simplify(v1-v2). 

@Christian Wolinski convert(..,Image) was introduced in Maple 2021.

@pallav By default, gamma in Maple has a special meaning as Euler's constant (see ?gamma), so if you want to use it as a regular variable, use local gamma.

Looks like you are using Maple 2022; simplify has improved since then. I was using Maple 2024, so you may want to upgrade. In general, finding the right commands to get the exact form you want is a difficult issue, so maybe someone else can give you some guidance on that. Certainly for the second ode, using simplify@expand (i.e., expand then simplify) gives a nicer result. But to get the factored form you probably have to take ode2, divide out y(t) on each side, try various simplifications and then mutliply back the y(t). Same for ode1.

@MaPal93 When Sigma = 0 (or T = 0) the polynomial has a root at 0 that fsolve is picking up, which leads to the falloff. A simple fix is just to not go there. For a plot range Sigma = 0.01 .. 5, the Lambda__1 plot looks good (Maple 2024), and for Sigma = 0.03 .. 5, the Lambda__2 plot looks almost good.

@dharr The region for small Sigma and T was giving numerical issues, but once these are solved it seems there is a positive solution for all Sigma and T (Sigma=0 a possible exception).


@MaPal93 I think that finding the boundary from the symbolic solutions will be difficult. However, you can always go back to the original two equations and solve them numerically for a grid of parameter values to get an approximate answers. My attempt to just solve them for Lambda__2 = 0 somehow didn't work as expected, but maybe can be fixed. I'll think a bit more about why that didn't work.

@Aung Yes, it should be usable for curvefitting etc.

@Aung If you ask FunctionAdvisor this

FunctionAdvisor(special_values, hypergeom([1/2, -k/2], [1 - k/2], z))

and look through the possibilities, most require special values such as integer of half-integer for the parameters. The exception seems to be for JacobiP, and indeed

convert(y, JacobiP) assuming k::positive;


but I'm guessing that is not what you want. I agree with @Preben Alsholm that there is no reason not to use the hypergeom function: it can be evaluated, plotted, differentiated etc just like any other function.

@MaPal93 Here's some progress, though Lambda__2 is so complicated it is very slow to find the boundary between positive and negative values, e.g, by implicitplot or even fsolve. I'll give some thought to a faster method. I didn't explore the other solutions to see if the first RootOf is the only one.


Edit: In principle, substituting Lambda__2 =0 into the original equations and solving is simpler than working with the complicated solutions, but doesn't seem to agree - maybe it is implicitly using the wrong solutions. I also did the non-dim in one step.


Its possible there is some better non-dimensionalization that is simpler to work wth, but I guess somehow the degree 10 polynomial is essential.

Edit2: Here's a different non-dimensionalization but the conclusions are the same.


1 2 3 4 5 6 7 Last Page 1 of 59