Hello NONMEM Users,
What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned error codes
somewhere?
Thank you!
Pavel
"ERROR IN LSODA: CODE -1"
Pavel,
This message looks familiar to me. I do not know about specifics of the error code, but LSODA is the integrator behind ADVAN13. You can safely assume that it has some problems with integration of your $DES block. You could check e.g. parameters that have become too large etc.
Unsatisfactory answer, actually. Some googling gave back this link: http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/deSolve/html/lsoda.html
where LSODA return values are mentioned. "[...]conditions under which the last call to lsoda returned. 2 if LSODA was successful, -1 if excess work done, -2 means excess accuracy requested. (Tolerances too small), -3 means illegal input detected. (See printed message.), -4 means repeated error test failures. (Check all input), -5 means repeated convergence failures. (Perhaps bad Jacobian supplied or wrong choice of MF or tolerances.), -6 means error weight became zero during problem. (Solution component i vanished, and atol or atol(i) = 0.) "
Still not satisfying. More digging revealed the documentation imbedded in fortran code in the odesolve package. The paragraphs on the returned istate:
"
c on output, istate has the following values and meanings.
c 1 means nothing was done, as tout was equal to t with
c istate = 1 on input. (however, an internal counter was
c set to detect and prevent repeated calls of this type.)
c 2 means the integration was performed successfully.
c -1 means an excessive amount of work (more than mxstep
c steps) was done on this call, before completing the
c requested task, but the integration was otherwise
c successful as far as t. (mxstep is an optional input
c and is normally 500.) to continue, the user may
c simply reset istate to a value .gt. 1 and call again
c (the excess work step counter will be reset to 0).
c in addition, the user may increase mxstep to avoid
c this error return (see below on optional inputs).
c -2 means too much accuracy was requested for the precision
c of the machine being used. this was detected before
c completing the requested task, but the integration
c was successful as far as t. to continue, the tolerance
c parameters must be reset, and istate must be set
c to 3. the optional output tolsf may be used for this
c purpose. (note.. if this condition is detected before
c taking any steps, then an illegal input return
c (istate = -3) occurs instead.)
c -3 means illegal input was detected, before taking any
c integration steps. see written message for details.
c note.. if the solver detects an infinite loop of calls
c to the solver with illegal input, it will cause
c the run to stop.
c -4 means there were repeated error test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c the problem may have a singularity, or the input
c may be inappropriate.
c -5 means there were repeated convergence test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c this may be caused by an inaccurate jacobian matrix,
c if one is being used.
c -6 means ewt(i) became zero for some i during the
c integration. pure relative error control (atol(i)=0.0)
c was requested on a variable which has now vanished.
c the integration was successful as far as t.
c -7 means the length of rwork and/or iwork was too small to
c proceed, but the integration was successful as far as t.
c this happens when lsoda chooses to switch methods
c but lrw and/or liw is too small for the new method.
c
c note.. since the normal output value of istate is 2,
c it does not need to be reset for normal continuation.
c also, since a negative input value of istate will be
c regarded as illegal, a negative output value requires the
c user to change it, and possibly other inputs, before
c calling the solver again.
"
Which says that -1 indicates that the solver actually has succeeded and nonmem could have continued by setting istate to 2 and mxstep to a larger value.... although completing the run could obviously take much more time.
For the nonmem development team: would it be an idea to (1) include LSODA return codes in the html help and (2) allow the user control of the mxstep input to ADVAN13?
Best regards,
Jeroen
J. Elassaiss-Schaap
Scientist PK/PD
MSD
PO Box 20, 5340 BH Oss, Netherlands
Phone: + 31 412 66 9320
Fax: + 31 412 66 2506
e-mail: jeroen.elassaiss
Quoted reply history
________________________________
From: owner-nmusers
Behalf Of nonmem
Sent: Thursday, September 22, 2011 05:41
To: nmusers
Subject: [NMusers] "ERROR IN LSODA: CODE -1"
Hello NONMEM Users,
What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned error codes somewhere?
Thank you!
Pavel
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
Pavel,
This message looks familiar to me. I do not know about specifics of the error
code, but LSODA is the integrator behind ADVAN13. You can safely assume that it
has some problems with integration of your $DES block. You could check e.g.
parameters that have become too large etc.
Unsatisfactory answer, actually. Some googling gave back this link:
http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/deSolve/html/lsoda.html
where LSODA return values are mentioned. "[...]conditions under which the last
call to lsoda returned. 2 if LSODA was successful, -1 if excess work done, -2
means excess accuracy requested. (Tolerances too small), -3 means illegal input
detected. (See printed message.), -4 means repeated error test failures. (Check
all input), -5 means repeated convergence failures. (Perhaps bad Jacobian
supplied or wrong choice of MF or tolerances.), -6 means error weight became
zero during problem. (Solution component i vanished, and atol or atol(i) = 0.) "
Still not satisfying. More digging revealed the documentation imbedded in
fortran code in the odesolve package. The paragraphs on the returned istate:
"
c on output, istate has the following values and meanings.
c 1 means nothing was done, as tout was equal to t with
c istate = 1 on input. (however, an internal counter was
c set to detect and prevent repeated calls of this type.)
c 2 means the integration was performed successfully.
c -1 means an excessive amount of work (more than mxstep
c steps) was done on this call, before completing the
c requested task, but the integration was otherwise
c successful as far as t. (mxstep is an optional input
c and is normally 500.) to continue, the user may
c simply reset istate to a value .gt. 1 and call again
c (the excess work step counter will be reset to 0).
c in addition, the user may increase mxstep to avoid
c this error return (see below on optional inputs).
c -2 means too much accuracy was requested for the precision
c of the machine being used. this was detected before
c completing the requested task, but the integration
c was successful as far as t. to continue, the tolerance
c parameters must be reset, and istate must be set
c to 3. the optional output tolsf may be used for this
c purpose. (note.. if this condition is detected before
c taking any steps, then an illegal input return
c (istate = -3) occurs instead.)
c -3 means illegal input was detected, before taking any
c integration steps. see written message for details.
c note.. if the solver detects an infinite loop of calls
c to the solver with illegal input, it will cause
c the run to stop.
c -4 means there were repeated error test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c the problem may have a singularity, or the input
c may be inappropriate.
c -5 means there were repeated convergence test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c this may be caused by an inaccurate jacobian matrix,
c if one is being used.
c -6 means ewt(i) became zero for some i during the
c integration. pure relative error control (atol(i)=0.0)
c was requested on a variable which has now vanished.
c the integration was successful as far as t.
c -7 means the length of rwork and/or iwork was too small to
c proceed, but the integration was successful as far as t.
c this happens when lsoda chooses to switch methods
c but lrw and/or liw is too small for the new method.
c
c note.. since the normal output value of istate is 2,
c it does not need to be reset for normal continuation.
c also, since a negative input value of istate will be
c regarded as illegal, a negative output value requires the
c user to change it, and possibly other inputs, before
c calling the solver again.
"
Which says that -1 indicates that the solver actually has succeeded and nonmem
could have continued by setting istate to 2 and mxstep to a larger value....
although completing the run could obviously take much more time.
For the nonmem development team: would it be an idea to (1) include LSODA
return codes in the html help and (2) allow the user control of the mxstep
input to ADVAN13?
Best regards,
Jeroen
J. Elassaiss-Schaap
Scientist PK/PD
MSD
PO Box 20, 5340 BH Oss, Netherlands
Phone: + 31 412 66 9320
Fax: + 31 412 66 2506
e-mail: [email protected]
Quoted reply history
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of [email protected]
Sent: Thursday, September 22, 2011 05:41
To: [email protected]
Subject: [NMusers] "ERROR IN LSODA: CODE -1"
Hello NONMEM Users,
What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned error codes
somewhere?
Thank you!
Pavel
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
Hi all,
When using ADVAN13 in NONMEM 7.2 the internal tolerance can be adjusted. The
default setting is ATOL=12! Reducing the ATOL (i.e. lower than TOL) in
$ESTIMATION may help. The problem is that ATOL cannnot be adjusted for
simulation.
Kind regards,
Jan-Stefan
Quoted reply history
On 22 September 2011 14:26, <[email protected]> wrote:
> Hello Jeroen,
>
> Thank you for the elaborate and useful reply.
>
> ADVAN13 was used. Changing to ADVAN8 caused "numerical difficulties with
> integration routine", but now it is clear where the issue may come from.
>
> Adding a careful explanation of error codes and recomendations to fix the
> issues may help a lot. I am getting quite a few messages like that and it
> takes a while to figure out a solution. Sometimes it is necessary to make
> random changes in the code and initial values and see if it helps.
>
> Kind regards,
> Pavel
>
>
> ----- Original Message -----
> From: "Elassaiss - Schaap, J. (Jeroen)" **
> Date: Thursday, September 22, 2011 3:25 am
> Subject: RE: [NMusers] "ERROR IN LSODA: CODE -1"
> To: "[email protected]" **
> Cc: nmusers **
>
> > Pavel,
> >
> > This message looks familiar to me. I do not know about specifics
> > of the error code, but LSODA is the integrator behind ADVAN13.
> > You can safely assume that it has some problems with integration
> > of your $DES block. You could check e.g. parameters that have
> > become too large etc.
> >
> > Unsatisfactory answer, actually. Some googling gave back this
> > link:
> http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/deSolve/html/lsoda.html
> > where LSODA return values are mentioned. "[...]conditions under
> > which the last call to lsoda returned. 2 if LSODA was
> > successful, -1 if excess work done, -2 means excess accuracy
> > requested. (Tolerances too small), -3 means illegal input
> > detected. (See printed message.), -4 means repeated error test
> > failures. (Check all input), -5 means repeated convergence
> > failures. (Perhaps bad Jacobian supplied or wrong choice of MF
> > or tolerances.), -6 means error weight became zero during
> > problem. (Solution component i vanished, and atol or atol(i) =
> > 0.) "
> >
> > Still not satisfying. More digging revealed the documentation
> > imbedded in fortran code in the odesolve package. The paragraphs
> > on the returned istate:
> >
> > "
> > c on output, istate has the following values and meanings.
> > c 1 means nothing was done, as tout was equal to t with
> > c istate = 1 on input. (however, an internal
> > counter was
> > c set to detect and prevent repeated calls of this type.)
> > c 2 means the integration was performed successfully.
> > c -1 means an excessive amount of work (more than mxstep
> > c steps) was done on this call, before completing the
> > c requested task, but the integration was otherwise
> > c successful as far as t. (mxstep is an optional input
> > c and is normally 500.) to continue, the user may
> > c simply reset istate to a value .gt. 1 and call again
> > c (the excess work step counter will be reset to 0).
> > c in addition, the user may increase mxstep to avoid
> > c this error return (see below on optional inputs).
> > c -2 means too much accuracy was requested for the precision
> > c of the machine being used. this was detected before
> > c completing the requested task, but the integration
> > c was successful as far as t. to continue, the tolerance
> > c parameters must be reset, and istate must be set
> > c to 3. the optional output tolsf may be used for this
> > c purpose. (note.. if this condition is detected before
> > c taking any steps, then an illegal input return
> > c (istate = -3) occurs instead.)
> > c -3 means illegal input was detected, before taking any
> > c integration steps. see written message for details.
> > c note.. if the solver detects an infinite loop of calls
> > c to the solver with illegal input, it will cause
> > c the run to stop.
> > c -4 means there were repeated error test failures on
> > c one attempted step, before completing the requested
> > c task, but the integration was successful as far
> > as t.
> > c the problem may have a singularity, or the input
> > c may be inappropriate.
> > c -5 means there were repeated convergence test
> > failures on
> > c one attempted step, before completing the requested
> > c task, but the integration was successful as far
> > as t.
> > c this may be caused by an inaccurate jacobian matrix,
> > c if one is being used.
> > c -6 means ewt(i) became zero for some i during the
> > c integration. pure relative error control (atol(i)=0.0)
> > c was requested on a variable which has now vanished.
> > c the integration was successful as far as t.
> > c -7 means the length of rwork and/or iwork was too
> > small to
> > c proceed, but the integration was successful as
> > far as t.
> > c this happens when lsoda chooses to switch methods
> > c but lrw and/or liw is too small for the new method.
> > c
> > c note.. since the normal output value of istate is 2,
> > c it does not need to be reset for normal continuation.
> > c also, since a negative input value of istate will be
> > c regarded as illegal, a negative output value requires the
> > c user to change it, and possibly other inputs, before
> > c calling the solver again.
> > "
> >
> > Which says that -1 indicates that the solver actually has
> > succeeded and nonmem could have continued by setting istate to 2
> > and mxstep to a larger value.... although completing the run
> > could obviously take much more time.
> >
> > For the nonmem development team: would it be an idea to (1)
> > include LSODA return codes in the html help and (2) allow the
> > user control of the mxstep input to ADVAN13?
> >
> > Best regards,
> > Jeroen
> >
> >
> > J. Elassaiss-Schaap
> > Scientist PK/PD
> > MSD
> > PO Box 20, 5340 BH Oss, Netherlands
> > Phone: + 31 412 66 9320
> > Fax: + 31 412 66 2506
> > e-mail: [email protected]
> >
> > ________________________________
> > From: [email protected] [mailto:owner-
> > [email protected]] On Behalf Of [email protected]
> > Sent: Thursday, September 22, 2011 05:41
> > To: [email protected]
> > Subject: [NMusers] "ERROR IN LSODA: CODE -1"
> >
> >
> > Hello NONMEM Users,
> >
> > What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned
> > error codes somewhere?
> >
> > Thank you!
> >
> > Pavel
> > Notice: This e-mail message, together with any attachments, contains
> > information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
> > New Jersey, USA 08889), and/or its affiliates Direct contact
> > informationfor affiliates is available at
> > http://www.merck.com/contact/contacts.html) that may be confidential,
> > proprietary copyrighted and/or legally privileged. It is
> > intended solely
> > for the use of the individual or entity named on this message.
> > If you are
> > not the intended recipient, and have received this message in error,
> > please notify us immediately by reply e-mail and then delete it
> > from
> > your system.
> >
>
--
/Jan-Stefan
The source code of LSODA is supplied in the ..\source directory of
NONMEM for NONMEM 7.1.2 and earlier. For NONMEM 7.2, the ..pr directory
has the PREDDPP source code available for viewing.
Typically when LSODA errors occur, is is corrected by modifying TOL.
However, sometimes LSODA errors occur only initially during estimation,
and may be ignored if they do not persist throughout the estimation.
Setting NOABORT allows getting through any initial difficulties.
Regarding:
For the nonmem development team: would it be an idea to (1) include
LSODA return codes in the html help and (2) allow the user control of
the mxstep input to ADVAN13?
LSODA return codes will be listed in html help in a future version
For ADVAN13,. the default mxsetp is 5000. To increase it further (say
to max integer value), insert the following in your control stream file
$PK
"FIRST
" USE PRDATA, ONLY: MXSTP01
" MXSTP01=2147483647
For a permanent change, modify MXSTP01 in ..\resource\prdata.f90, and
rebuild your NONMEM installation.
For ADVAN9, MXSTEP is controled by MXSTP0, which is presently set at
2147483647
Robert J. Bauer, Ph.D.
Vice President, Pharmacometrics
ICON Development Solutions
Tel: (215) 616-6428
Mob: (925) 286-0769
Email: [email protected]
Web: www.icondevsolutions.com <outbind://345/www.icondevsolutions.com>
Quoted reply history
________________________________
From: [email protected] [mailto:[email protected]]
On Behalf Of Elassaiss - Schaap, J. (Jeroen)
Sent: Thursday, September 22, 2011 2:58 AM
To: [email protected]
Cc: nmusers
Subject: RE: [NMusers] "ERROR IN LSODA: CODE -1"
Pavel,
This message looks familiar to me. I do not know about specifics of the
error code, but LSODA is the integrator behind ADVAN13. You can safely
assume that it has some problems with integration of your $DES block.
You could check e.g. parameters that have become too large etc.
Unsatisfactory answer, actually. Some googling gave back this link:
http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/deSolve/html/lsoda.htm
l
where LSODA return values are mentioned. "[...]conditions under which
the last call to lsoda returned. 2 if LSODA was successful, -1 if excess
work done, -2 means excess accuracy requested. (Tolerances too small),
-3 means illegal input detected. (See printed message.), -4 means
repeated error test failures. (Check all input), -5 means repeated
convergence failures. (Perhaps bad Jacobian supplied or wrong choice of
MF or tolerances.), -6 means error weight became zero during problem.
(Solution component i vanished, and atol or atol(i) = 0.) "
Still not satisfying. More digging revealed the documentation imbedded
in fortran code in the odesolve package. The paragraphs on the returned
istate:
"
c on output, istate has the following values and meanings.
c 1 means nothing was done, as tout was equal to t with
c istate = 1 on input. (however, an internal counter was
c set to detect and prevent repeated calls of this type.)
c 2 means the integration was performed successfully.
c -1 means an excessive amount of work (more than mxstep
c steps) was done on this call, before completing the
c requested task, but the integration was otherwise
c successful as far as t. (mxstep is an optional input
c and is normally 500.) to continue, the user may
c simply reset istate to a value .gt. 1 and call again
c (the excess work step counter will be reset to 0).
c in addition, the user may increase mxstep to avoid
c this error return (see below on optional inputs).
c -2 means too much accuracy was requested for the precision
c of the machine being used. this was detected before
c completing the requested task, but the integration
c was successful as far as t. to continue, the tolerance
c parameters must be reset, and istate must be set
c to 3. the optional output tolsf may be used for this
c purpose. (note.. if this condition is detected before
c taking any steps, then an illegal input return
c (istate = -3) occurs instead.)
c -3 means illegal input was detected, before taking any
c integration steps. see written message for details.
c note.. if the solver detects an infinite loop of calls
c to the solver with illegal input, it will cause
c the run to stop.
c -4 means there were repeated error test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c the problem may have a singularity, or the input
c may be inappropriate.
c -5 means there were repeated convergence test failures on
c one attempted step, before completing the requested
c task, but the integration was successful as far as t.
c this may be caused by an inaccurate jacobian matrix,
c if one is being used.
c -6 means ewt(i) became zero for some i during the
c integration. pure relative error control (atol(i)=0.0)
c was requested on a variable which has now vanished.
c the integration was successful as far as t.
c -7 means the length of rwork and/or iwork was too small to
c proceed, but the integration was successful as far as t.
c this happens when lsoda chooses to switch methods
c but lrw and/or liw is too small for the new method.
c
c note.. since the normal output value of istate is 2,
c it does not need to be reset for normal continuation.
c also, since a negative input value of istate will be
c regarded as illegal, a negative output value requires the
c user to change it, and possibly other inputs, before
c calling the solver again.
"
Which says that -1 indicates that the solver actually has succeeded and
nonmem could have continued by setting istate to 2 and mxstep to a
larger value.... although completing the run could obviously take much
more time.
For the nonmem development team: would it be an idea to (1) include
LSODA return codes in the html help and (2) allow the user control of
the mxstep input to ADVAN13?
Best regards,
Jeroen
J. Elassaiss-Schaap
Scientist PK/PD
MSD
PO Box 20, 5340 BH Oss, Netherlands
Phone: + 31 412 66 9320
Fax: + 31 412 66 2506
e-mail: [email protected]
________________________________
From: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: Thursday, September 22, 2011 05:41
To: [email protected]
Subject: [NMusers] "ERROR IN LSODA: CODE -1"
Hello NONMEM Users,
What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned error
codes somewhere?
Thank you!
Pavel
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you
are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
Hi,
I think it may be useful to understand that numerical differential equation solvers require an absolute tolerance as well as a relative tolerance. See http://www.gnu.org/software/octave/doc/interpreter/Differential_002dAlgebraic-Equations.html for an explanation and example of how these tolerances are typically used.
The need for an absolute tolerance is when the correct solution of the DE is zero. In this case a relative tolerance cannot guide the numerical DE solver to achieve a sufficiently precise solution.
An absolute tolerance is analogous to an additive residual error while relative tolerance is analogous to a proportional residual error. Thus the absolute and relative tolerance criteria have no direct numerical relationship to each other.
The online NM7 help describes ATOL like this:
ATOL=n
Absolute tolerance. Used only with ADVAN13, for which TOL is a rela-
tive tolerance. The default is 12; a smaller value (equal to TOL) may
improve run time. May also be set with $COVARIANCE record.
The NM7 definition is rather mysterious. If ATOL is really an absolute tolerance criterion then a value of 12 would be ridiculous if the scale of the solution was in say the 1 to 100 range. Perhaps we are expected to guess that ATOL means 10D-12?
I cannot see any reason to suggest why ATOL should be set equal to TOL because these numbers are like apples and oranges and cannot be compared. Some ODE solvers allow ATOL as a vector to match the DADT vector so that the absolute tolerance for each solution could be individually specified.
Nick
Quoted reply history
On 23/09/2011 7:48 a.m., Jan-Stefan Van der Walt wrote:
> Hi all,
>
> When using ADVAN13 in NONMEM 7.2 the internal tolerance can be adjusted. The default setting is ATOL=12! Reducing the ATOL (i.e. lower than TOL) in $ESTIMATION may help. The problem is that ATOL cannnot be adjusted for simulation.
>
> Kind regards,
> Jan-Stefan
>
> On 22 September 2011 14:26, < [email protected] < mailto: [email protected] >> wrote:
>
> Hello Jeroen,
> Thank you for the elaborate and useful reply.
> ADVAN13 was used. Changing to ADVAN8 caused "numerical
> difficulties with integration routine", but now it is clear where
> the issue may come from.
> Adding a careful explanation of error codes and recomendations to
> fix the issues may help a lot. I am getting quite a few messages
>
> like that and it takes a while to figure out a solution. Sometimes it is necessary to make random changes in the code and
>
> initial values and see if it helps.
> Kind regards,
> Pavel
>
> ----- Original Message -----
> From: "Elassaiss - Schaap, J. (Jeroen)"
> Date: Thursday, September 22, 2011 3:25 am
> Subject: RE: [NMusers] "ERROR IN LSODA: CODE -1"
> To: "[email protected] <mailto:[email protected]>"
> Cc: nmusers
>
> > Pavel,
> >
> > This message looks familiar to me. I do not know about specifics
> > of the error code, but LSODA is the integrator behind ADVAN13.
> > You can safely assume that it has some problems with integration
> > of your $DES block. You could check e.g. parameters that have
> > become too large etc.
> >
> > Unsatisfactory answer, actually. Some googling gave back this
> > link:
> http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/deSolve/html/lsoda.html
>
> http://hosho.ees.hokudai.ac.jp/%7Ekubo/Rdoc/library/deSolve/html/lsoda.html
> > where LSODA return values are mentioned. "[...]conditions under
> > which the last call to lsoda returned. 2 if LSODA was
> > successful, -1 if excess work done, -2 means excess accuracy
> > requested. (Tolerances too small), -3 means illegal input
> > detected. (See printed message.), -4 means repeated error test
> > failures. (Check all input), -5 means repeated convergence
> > failures. (Perhaps bad Jacobian supplied or wrong choice of MF
> > or tolerances.), -6 means error weight became zero during
> > problem. (Solution component i vanished, and atol or atol(i) =
> > 0.) "
> >
> > Still not satisfying. More digging revealed the documentation
> > imbedded in fortran code in the odesolve package. The paragraphs
> > on the returned istate:
> >
> > "
> > c on output, istate has the following values and meanings.
> > c 1 means nothing was done, as tout was equal to t with
> > c istate = 1 on input. (however, an internal
> > counter was
> > c set to detect and prevent repeated calls of this type.)
> > c 2 means the integration was performed successfully.
> > c -1 means an excessive amount of work (more than mxstep
> > c steps) was done on this call, before completing the
> > c requested task, but the integration was otherwise
> > c successful as far as t. (mxstep is an optional input
> > c and is normally 500.) to continue, the user may
> > c simply reset istate to a value .gt. 1 and call again
> > c (the excess work step counter will be reset to 0).
> > c in addition, the user may increase mxstep to avoid
> > c this error return (see below on optional inputs).
> > c -2 means too much accuracy was requested for the precision
> > c of the machine being used. this was detected before
> > c completing the requested task, but the integration
> > c was successful as far as t. to continue, the tolerance
> > c parameters must be reset, and istate must be set
> > c to 3. the optional output tolsf may be used for this
> > c purpose. (note.. if this condition is detected before
> > c taking any steps, then an illegal input return
> > c (istate = -3) occurs instead.)
> > c -3 means illegal input was detected, before taking any
> > c integration steps. see written message for details.
> > c note.. if the solver detects an infinite loop of calls
> > c to the solver with illegal input, it will cause
> > c the run to stop.
> > c -4 means there were repeated error test failures on
> > c one attempted step, before completing the requested
> > c task, but the integration was successful as far
> > as t.
> > c the problem may have a singularity, or the input
> > c may be inappropriate.
> > c -5 means there were repeated convergence test
> > failures on
> > c one attempted step, before completing the requested
> > c task, but the integration was successful as far
> > as t.
> > c this may be caused by an inaccurate jacobian matrix,
> > c if one is being used.
> > c -6 means ewt(i) became zero for some i during the
> > c integration. pure relative error control (atol(i)=0.0)
> > c was requested on a variable which has now vanished.
> > c the integration was successful as far as t.
> > c -7 means the length of rwork and/or iwork was too
> > small to
> > c proceed, but the integration was successful as
> > far as t.
> > c this happens when lsoda chooses to switch methods
> > c but lrw and/or liw is too small for the new method.
> > c
> > c note.. since the normal output value of istate is 2,
> > c it does not need to be reset for normal continuation.
> > c also, since a negative input value of istate will be
> > c regarded as illegal, a negative output value requires the
> > c user to change it, and possibly other inputs, before
> > c calling the solver again.
> > "
> >
> > Which says that -1 indicates that the solver actually has
> > succeeded and nonmem could have continued by setting istate to 2
> > and mxstep to a larger value.... although completing the run
> > could obviously take much more time.
> >
> > For the nonmem development team: would it be an idea to (1)
> > include LSODA return codes in the html help and (2) allow the
> > user control of the mxstep input to ADVAN13?
> >
> > Best regards,
> > Jeroen
> >
> >
> > J. Elassaiss-Schaap
> > Scientist PK/PD
> > MSD
> > PO Box 20, 5340 BH Oss, Netherlands
> > Phone: + 31 412 66 9320 <tel:%2B%2031%20412%2066%209320>
> > Fax: + 31 412 66 2506 <tel:%2B%2031%20412%2066%202506>
> > e-mail: [email protected]
> <mailto:[email protected]>
> >
> > ________________________________
> > From: [email protected]
> <mailto:[email protected]> [mailto:owner- <mailto:owner->
> > [email protected] <mailto:[email protected]>] On
> Behalf Of [email protected] <mailto:[email protected]>
> > Sent: Thursday, September 22, 2011 05:41
> > To: [email protected] <mailto:[email protected]>
> > Subject: [NMusers] "ERROR IN LSODA: CODE -1"
> >
> >
> > Hello NONMEM Users,
> >
> > What is "ERROR IN LSODA: CODE -1"? Is there a list of explaned
> > error codes somewhere?
> >
> > Thank you!
> >
> > Pavel
> > Notice: This e-mail message, together with any attachments, contains
> > information of Merck & Co., Inc. (One Merck Drive, Whitehouse
> Station,
> > New Jersey, USA 08889), and/or its affiliates Direct contact
> > informationfor affiliates is available at
> > http://www.merck.com/contact/contacts.html) that may be
> confidential,
> > proprietary copyrighted and/or legally privileged. It is
> > intended solely
> > for the use of the individual or entity named on this message.
> > If you are
> > not the intended recipient, and have received this message in error,
> > please notify us immediately by reply e-mail and then delete it
> > from
> > your system.
> >
>
> --
> /Jan-Stefan
--
Nick Holford, Professor Clinical Pharmacology
Dept Pharmacology& Clinical Pharmacology
University of Auckland,85 Park Rd,Private Bag 92019,Auckland,New Zealand
tel:+64(9)923-6730 fax:+64(9)373-7090 mobile:+64(21)46 23 53
email: [email protected]
http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford
Nick,
The help entry makes sense to me. When one assumes that both tolerances are converted as
tolerance = 10^(-TOL)
they are appropriately scaled.
And with regard to the html fragment you referred to, it seems to me like a pragmatic advice rather than stating that those numbers should be kept equal. It also makes sense that if you want more accurate positive numbers you also may want the zero defined more accurately.
Thanks for the solver link!
Best regards,
Jeroen
Quoted reply history
-----Original Message-----
From: owner-nmusers
Behalf Of Nick Holford
Sent: Thursday, September 22, 2011 23:02
To: nmusers
Subject: Re: [NMusers] "ERROR IN LSODA: CODE -1"
Hi,
I think it may be useful to understand that numerical differential
equation solvers require an absolute tolerance as well as a relative
tolerance. See
http://www.gnu.org/software/octave/doc/interpreter/Differential_002dAlgebraic-Equations.html
for an explanation and example of how these tolerances are typically used.
The need for an absolute tolerance is when the correct solution of the
DE is zero. In this case a relative tolerance cannot guide the numerical
DE solver to achieve a sufficiently precise solution.
An absolute tolerance is analogous to an additive residual error while
relative tolerance is analogous to a proportional residual error. Thus
the absolute and relative tolerance criteria have no direct numerical
relationship to each other.
The online NM7 help describes ATOL like this:
ATOL=n
Absolute tolerance. Used only with ADVAN13, for which TOL is a rela-
tive tolerance. The default is 12; a smaller value (equal to TOL) may
improve run time. May also be set with $COVARIANCE record.
The NM7 definition is rather mysterious. If ATOL is really an absolute
tolerance criterion then a value of 12 would be ridiculous if the scale
of the solution was in say the 1 to 100 range. Perhaps we are expected
to guess that ATOL means 10D-12?
I cannot see any reason to suggest why ATOL should be set equal to TOL
because these numbers are like apples and oranges and cannot be
compared. Some ODE solvers allow ATOL as a vector to match the DADT
vector so that the absolute tolerance for each solution could be
individually specified.
Nick
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
Nick,
The help entry makes sense to me. When one assumes that both tolerances are
converted as
tolerance = 10^(-TOL)
they are appropriately scaled.
And with regard to the html fragment you referred to, it seems to me like a
pragmatic advice rather than stating that those numbers should be kept equal.
It also makes sense that if you want more accurate positive numbers you also
may want the zero defined more accurately.
Thanks for the solver link!
Best regards,
Jeroen
Quoted reply history
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Nick Holford
Sent: Thursday, September 22, 2011 23:02
To: nmusers
Subject: Re: [NMusers] "ERROR IN LSODA: CODE -1"
Hi,
I think it may be useful to understand that numerical differential
equation solvers require an absolute tolerance as well as a relative
tolerance. See
http://www.gnu.org/software/octave/doc/interpreter/Differential_002dAlgebraic-Equations.html
for an explanation and example of how these tolerances are typically used.
The need for an absolute tolerance is when the correct solution of the
DE is zero. In this case a relative tolerance cannot guide the numerical
DE solver to achieve a sufficiently precise solution.
An absolute tolerance is analogous to an additive residual error while
relative tolerance is analogous to a proportional residual error. Thus
the absolute and relative tolerance criteria have no direct numerical
relationship to each other.
The online NM7 help describes ATOL like this:
ATOL=n
Absolute tolerance. Used only with ADVAN13, for which TOL is a rela-
tive tolerance. The default is 12; a smaller value (equal to TOL) may
improve run time. May also be set with $COVARIANCE record.
The NM7 definition is rather mysterious. If ATOL is really an absolute
tolerance criterion then a value of 12 would be ridiculous if the scale
of the solution was in say the 1 to 100 range. Perhaps we are expected
to guess that ATOL means 10D-12?
I cannot see any reason to suggest why ATOL should be set equal to TOL
because these numbers are like apples and oranges and cannot be
compared. Some ODE solvers allow ATOL as a vector to match the DADT
vector so that the absolute tolerance for each solution could be
individually specified.
Nick
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from
your system.
Jeroen,
The help entry only makes sense by making certain assumptions. It would be very simple to change the documentation so that users did not have to rely on making such assumptions. The definition of TOL could also do with some attention.
There is no pragmatic sense in making TOL=ATOL. It would only be appropriate for some specific problem if this choice was in fact the best.
Nick
Quoted reply history
On 23/09/2011 7:05 p.m., Elassaiss - Schaap, J. (Jeroen) wrote:
> Nick,
>
> The help entry makes sense to me. When one assumes that both tolerances are
> converted as
> tolerance = 10^(-TOL)
> they are appropriately scaled.
>
> And with regard to the html fragment you referred to, it seems to me like a
> pragmatic advice rather than stating that those numbers should be kept equal.
> It also makes sense that if you want more accurate positive numbers you also
> may want the zero defined more accurately.
>
> Thanks for the solver link!
>
> Best regards,
> Jeroen
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Nick Holford
> Sent: Thursday, September 22, 2011 23:02
> To: nmusers
> Subject: Re: [NMusers] "ERROR IN LSODA: CODE -1"
>
> Hi,
>
> I think it may be useful to understand that numerical differential
> equation solvers require an absolute tolerance as well as a relative
> tolerance. See
> http://www.gnu.org/software/octave/doc/interpreter/Differential_002dAlgebraic-Equations.html
> for an explanation and example of how these tolerances are typically used.
>
> The need for an absolute tolerance is when the correct solution of the
> DE is zero. In this case a relative tolerance cannot guide the numerical
> DE solver to achieve a sufficiently precise solution.
>
> An absolute tolerance is analogous to an additive residual error while
> relative tolerance is analogous to a proportional residual error. Thus
> the absolute and relative tolerance criteria have no direct numerical
> relationship to each other.
>
> The online NM7 help describes ATOL like this:
>
> ATOL=n
> Absolute tolerance. Used only with ADVAN13, for which TOL is a rela-
> tive tolerance. The default is 12; a smaller value (equal to TOL) may
> improve run time. May also be set with $COVARIANCE record.
>
> The NM7 definition is rather mysterious. If ATOL is really an absolute
> tolerance criterion then a value of 12 would be ridiculous if the scale
> of the solution was in say the 1 to 100 range. Perhaps we are expected
> to guess that ATOL means 10D-12?
>
> I cannot see any reason to suggest why ATOL should be set equal to TOL
> because these numbers are like apples and oranges and cannot be
> compared. Some ODE solvers allow ATOL as a vector to match the DADT
> vector so that the absolute tolerance for each solution could be
> individually specified.
>
> Nick
>
> Notice: This e-mail message, together with any attachments, contains
> information of Merck& Co., Inc. (One Merck Drive, Whitehouse Station,
> New Jersey, USA 08889), and/or its affiliates Direct contact information
> for affiliates is available at
> http://www.merck.com/contact/contacts.html) that may be confidential,
> proprietary copyrighted and/or legally privileged. It is intended solely
> for the use of the individual or entity named on this message. If you are
> not the intended recipient, and have received this message in error,
> please notify us immediately by reply e-mail and then delete it from
> your system.
--
Nick Holford, Professor Clinical Pharmacology
Dept Pharmacology& Clinical Pharmacology
University of Auckland,85 Park Rd,Private Bag 92019,Auckland,New Zealand
tel:+64(9)923-6730 fax:+64(9)373-7090 mobile:+64(21)46 23 53
email: [email protected]
http://www.fmhs.auckland.ac.nz/sms/pharmacology/holford