@Andiguys 

As you have a more recent version of Maple than mine's, replace 

InsertContent(Worksheet(Group(Input( Z )))):

by

InsertContent(Worksheet( Z )):

@MaPal93 

I'm curious, could you upload this calibration case?
Thanks

Here are a few works arround your ncal2 case Ideas_2__mmcdara_2.mw

@nm 

not ISODINE but ISOCLINE  isocline.mw

In case you read French this is an histortical description of a method for graphical_solution_of_ode  (if not plots are pretty, in partular the mechanical devices that draw thesolutions of odes)

@Andiguys 

I notice you are still unclear about the expression of Q2 that you write in two different ways:

Q2 = -Q1*delta*h+d*h*x
# and
Q2 = max(0, -Q1*delta*h+d*h*x)

So I consider the two cases in the attached file.
Do not be surprised that the value of I1 has no significative importance:

# In
Q1 = 0.2e-1*exp(.4*I1) +  4.000000000*10^7-4.000000000*10^7*exp(.5*I2);
# the influence of I1 is negligible when I1 and I2 are in 0..6

# same thing happens for Q2 and TRC

q2_mmcdara.mw

@MaPal93 

I started from INDEX=0.001 and used a smaller INDEX step:  fsolve cannot find any solution for INDEX > 0.31100616.
The ability of fsolve to go beyond this limit seems to depend strongly on the step you use and of the starting point (which "orients" to some initial solution).
Indeed, withe the same INDEX step of 1e-4 I was able to reach  INDEX = 0.8731 while starting from INDEX=0.25.

So I believe I'm done now with this thread because I have no more ideas to propose.

@Andiguys 

My mistake, the correct command is 

# First thing: construct TRC correctly

TRC_ok := eval(TRC, {alpha = (u -> 0.02*exp(0.4*u)), beta = (u -> 0.2e-1*(1-exp(.5*u)))})

The syntax eval(TRC, alpha = (u -> 0.02*exp(0.4*u))) means replace.the function alpha(u)=0.02*exp(0.4*u) (u could be anything else) .
I wrote mistakenly beta = (u -> 0.2e-1*(1-exp(.5*u))), but the result is the same because TRC contains only beta(I2).

How can we calculate Q1a and Q1b (not to mention that in your previous reply you said Q1a and Q2a...).

I suggest you to write a simple and clear new worksheet with the exact equation to solve, the correct conditions and/or constraints, the relations between auxiliary variables Q1a, Q1b, Q2a?) which do npt appear in TRC and express clearly what you want.

Your points 1 to 5 in your last reply only add more confusion.
So take the time to write your problem correctly and upload the corresponding worksheet.

@MaPal93 

Increasing Digits is very unlikely to help here (IMO).
A dynamic control of the step of INDEX  is extremely complex to do: even if you find a good strategy for one calibration case there is no guarantee it still performs well for another one.

Here are two questions you should think about:

• Why do you believe positive solutions exist for INDEX > 0.8731 ?
• Do you feel they do or are you sure they really do?

I'm not done looking at this thread, it's just that I'm not sure that your ncal2 problem cab be solved up to INDEX=1 and that spending time to try and solve it is not a waste of time.

@Andiguys 

4*10^8 = 4e8 in floating point representation

Read_this.mw  and stop posting consecutive replies until the first one has been answered, Mapleprimes is not a chat app.

PS: I don't understand your question "what is u?"

@mz6687 

Now that you have said what you wanted, could you please tell me what what are the three equations whose lambda, m0 and n0 values are supposed to be the solutions?

@MaPal93 

Here is my last, and complete, work.

It seems there is no positive solution (for lambda__i1) for INDEX > 0.8736.
Maybe reducing the step of INDEX before reaching this value or increasing the number of Digits would prove I'm wrong

ncal2_breaks__mmcdara_ideas.mw

Maybe you could try to do some things on your own based ont the few ideas I develop in this file.

You ask "how to determine lambda, m0, and n0?", so what are the three equations you want to solve?

Here are a few examples of what can be done solA_mmcdara.mw

@MaPal93 

Two issues related to running your script for ncal2: fsolve_help_mmcdara_ncal2_breaks.mw

1. A discontinuity emerges for sigma__delta1~0.27
   This discontinuity is not really an issue of my "my script".
   To see that, focus arrounf INDEX=0.27  by changing the for loop this way

   for INDEX from 0.250 by 1e-4 to 0.300 do

   and plot this

   display(
     seq(
       dataplot(
         lamRes1[1..arrInd-1,1], lamRes1[1..arrInd-1,i+1]
         , style=line
         , legend=typeset(U[i])
         , color=ColorTools:-Color([rand()/10^12, rand()/10^12, rand()/10^12])
       )
       , i=1..6
     )
   )
   

   There is no discontinuity displayed.
   I guess this is the result of my using as initial point the value lam took at the previous INDEX value.
    
2. fsolve() "breaks" at the 614th iteration
   Not a problem with "my script" but with a problem whose cause is your lam_ranges.
   
   Explanation:

For INDEX = 0.613,  lambda__i1 =0.01001499459 and is a decreasing function of INDEX.
It is likely that the search range lambda__i1= 0.01 .. 1000 is the reason why fsolve fails for INDEX=0.614.

Solution:

Reduce the lower bound of the search range for lambda__i1.

Be cautious, the same problem is going to happen lately for lambda__d1, so proceed the same wat for the lower search range of this latter  (For  INDEX = 0.808,  lambda__d1 =0.0100009314 and is a decreasing function of INDEX).

Last point: setting very lower bounds since the starting point appears to be a wrong idea because fsolve seems to be stucked somewhere.
So I implemented a kind of dynamic adjustment where we start with quite small lower bounds and decrease them if necessary as the previous solution approaches them.

In a couple of hours I will send you a file which enables reaching INDEX=1 (For the moment I'm stucked at INDEX=0.8733)

What you have to keep in mind is that fsolve will never be capable to solve any problem without ad hoc adjustments.
Very often you have to customize the way fsolve is used to give the correct/expected/desired/reliable result.
For instance my first script worked "by chance" on your first test case but failed four your second one. 
Identifying the causes of a failure is the first step, the simple one in fact.
Finding a reliable strategy to avoid it can be more tricky more specifically if you want to preserve reasonnable computational times.
I insist on these points because you will find soon a third or fourth or nth case on wich my last script fails.
In this case identify the causes and try to imagine 

@Carl Love 

hardheaded is the exact term.

@Carl Love 

I really have a hard nipple... 
I widened my eyes reading this and went to my favorite translator.

What does Deepl propose as alternative traductions for that?
(the French translation has the same sexual sense)

But looking for alternative translations we get

Whose reverse translation gives

I'm relieved, everything's back to normal.

But how the hell can Deepl translates nipple as "têton" (=nipple) or "neurone" (=neuron)?

This funny thing reminds me of something I read 30 years ago about the first translator.
People translated "The flesh is weak but the spirit is strong" into russian and next back to english to verified they recovered something close to the original text.
It is said they got "The flesh is rotten but the vodka is strong"  instead.

The moral is: Always translate back and forth to avoid an embarassing situation

I believe I got it! This is a Deepl bug.
Look at these three translations

The first one corresponds to what the OP wanted to say.
The third one translates just as the first one.
But if you want to change the last name in the first translation, Deepl proses "skull, brain, mind, nut, face, ...", but it proposes "nipple, noggin, nip, face, ... " for the third one.
It looks like Deepl was using the corpus correspondig to the second translation as a corpus for "head" in the third one.
Note that if you delete the three lines in the left panel and write again "J'ai vraiment la tête dure", proposals for "head" still are "nipple, noggin, nip, face, ... ".
Big Deepl is watching you.

@Carl Love 

I wrote all that a bit too quickly, this kind of question upsets me a bit.
I should stay more composed