Re: "ERROR IN LSODA: CODE -1"

From: Nick Holford Date: September 22, 2011 technical Source: mail-archive.com
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
Sep 22, 2011 NONMEM "ERROR IN LSODA: CODE -1"
Sep 22, 2011 Jeroen Elassaiss-Schaap RE: "ERROR IN LSODA: CODE -1"
Sep 22, 2011 Jeroen Elassaiss-Schaap RE: "ERROR IN LSODA: CODE -1"
Sep 22, 2011 Jan-Stefan van der Walt Re: RE: "ERROR IN LSODA: CODE -1"
Sep 22, 2011 Robert Bauer RE: "ERROR IN LSODA: CODE -1"
Sep 22, 2011 Nick Holford Re: "ERROR IN LSODA: CODE -1"
Sep 23, 2011 Jeroen Elassaiss-Schaap RE: "ERROR IN LSODA: CODE -1"
Sep 23, 2011 Jeroen Elassaiss-Schaap RE: "ERROR IN LSODA: CODE -1"
Sep 23, 2011 Nick Holford Re: "ERROR IN LSODA: CODE -1"