Preben Alsholm

11719 Reputation

22 Badges

15 years, 255 days

MaplePrimes Activity

These are replies submitted by Preben Alsholm

@Carl Love Thanks Carl for taking the time to explain these notions. I really appreciate that!

@lcz You get exactly the same error if you drop the list brackets. So those are irrelevant here.
Whether xxx[1] is used to select the first element in a list xxx or the first element of a sequence xxx is irrelevant.
(But notice there will be problems in this regard if the sequence xxx consists of 1 element, but you have 11 graphs).

The important point is that Tom Leslie has added to your code UnderlyingGraph. That is the problem mentioned by the error message.

I'm speaking as somebody who knows next to nothing about graph theory.

By reading the help page for ChromaticNumber I see that it is applied to an undirected unweighted graph. Your graph1 is weighted, but the underlying graph is not:
Take a look at the output from UnderlyingGraph(graphsof4[1]).

@fatemeh1090 My conclusion is that the statement in the paper about the derivative of the trace of the Jacobian is wrong.
( Clearly this doesn't invalidate the whole paper, but it teaches us to be on guard when something is claimed to be obvious. )

Use instead the Maple expression given already in this discussion by dharr above.

You can check his result with the example given by vv above:
So try with TrJ and E__2 from dharr's worksheet

TrJ_explicit:=eval(TrJ, E__2);
dTrJ:=simplify(diff(TrJ_explicit, alpha));
params_vv:=[alpha,beta,gamma,delta]=~[-1/2 + 2*sqrt(3), 1/6, 1, 13/6]; #Parameters from vv
simplify(%); # 0
simplify(%); # 3/4


@vv Thank you for a very well chosen counter example to the "obvious" statement about the derivative of the trace in the paper:

Stability and bifurcation analysis in a predator–prey system with Michaelis–Menten type predator harvesting
by Dongpo Hu and Hongjun Cao.


@fatemeh1090 I understand that you had to remove the full pdf-file for copyright reasons.

Thus I won't be able to find the authors' reasoning.

I tried a little on my own, but didn't manage to get down to the result given for the derivative of the trace w.r.t. alpha.

I'll give the steps I tried:

local gamma;
##The system in the pdf-file. Right hand sides:
simplify(%,{TRxa=0}); # simplifying with the side relation TRxa=0


@fatemeh1090 The expression for the trace of J in (24) in the pdf-file is correct.

But how do you get from that to the expression given for the derivative of the trace w.r.t. alpha?
Of course x and y  depend on alpha, but it seems that the author is not using the explicit dependence we find easily with Maple.

The text continues after that with "Obviously, ..." and gives the derivative in terms of x etc.

Why is it obvious? There are several pages missing in the uploaded pdf-file. Maybe the derivative of x w.r.t. alpha has been found in those pages?

@vv I use a similar device for fsolve. I give the procedure (here PUV) the option remember to minimize the expense of calling the procedure (PUV)  several times.

@666 jvbasha Your worksheet doesn't run without several errors on my machine in Maple 2020, Maple 2018 and Maple 18 (which you apparently use).

Since this is a new project you should start a new thread, where everybody is invited to participate.

@666 jvbasha Please see my response above to your question directed to several users including me.

Besides that be aware of misunderstanding my answers about plotting errors.

In my answer comparing the solution of an ivp with the given bvp the initial conditions for the ivp (ics) were taken from the bvp. Thus the best I can get out of a comparison is the comfort that they are pretty close.
The ics are "contaminated" by the numerical errors in solving the bvp of course, so the ivp will be too, besides introducing its own errors. So we are not plotting the actual errors in solving the bvp.

@666 jvbasha Are you talking about iterations done by `dsolve/numeric/bvp` ?

If so the answer is that you have no control over the number of iterations done in order to satisfy the abserr requirement.

You can give a value to maxmesh in the range 32 ..13421772 according to the help. But that doesn't give you the control you (probably) want.

You need to write your own algorithm to gain that control.

@Kitonum Yes, it was introduced in Maple 2019.

@666 jvbasha Notice that in R_init T comes first, then diff(T(eta),eta), then f(eta), etc.

Thus use the order:
H, H1, F, F1, F2, G, G1, G2 := op(rhs~(R_init[2 .. -1]));

and everything else is fine.

@Alger What do you mean by saying that " Variables of the model should be null when C<40e-6 and can be not null when C>40e-6 with imposing high range." ?

Do you mean that for C <40e-6 all the dependent variables (like e.g. ids(t))  go to zero as t -> infinity?

And for C>40e-6 they tend to a periodic solution (not identically 0)?

@Alger I had another look at your system. Although it starts out looking linear it ends up being highly nonlinear. Thus there isn't any a priori reason to deny the actual existence of singularities.

The "singularity" problem I ran into with C = 0.000050 and range 0..50 disappeared, however, when I used your original equations eq1, eq2, eq3, and eq4 together with ep5 and ep6.

Unfortunately, for C = 0.000045 and range 0..100 I still got a "singularity" at the same point you got one.

There are obvious numerical difficulties with this problem, so I'm still not convinced that a genuine singularity is present.

Here is the revised worksheet:

@Alger When dsolve/numeric talks about a probable singularity one should (as you surely do) notice the adjective "probable".

What exactly is a singularity in this numerical context? What triggers the error (or warning) message?
Your system is very complicated, so it isn't easy to see. It would be nice to find a simpler example with the same problem.

2 3 4 5 6 7 8 Last Page 4 of 202