message "A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE" whene there is no $sigma record

2 messages 2 people Latest: Nov 26, 2015
Hello The NONMEM Team, I removed $sigma record because ERR(1) and ERR(2) were not used (home-made likelihood was used instead; SD was parameterized as THETA) and got "A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE" (see below). The message sounds rather emotional than mathematical ("inappropriate"). When I used a dummy record $SIGMA 1 FIX 1 FIX or $SIGMA 1 FIX the issue disappeared. The reason I removed $sigma was that some very different SAEM jobs (and possibly some other methods) did not provide error messages when unused omegas remained in the code (for example, there are 5 etas and $OMEGA DIAGONAL(6) is used), but the algorithm became unstable or provided much less meaningful THETAS. (I believe something similar happened when unnecessary $sigma records were in the code.) So, I assumed that any unused but reserved sigmas and omegas can be damaging. It feels like there is a simple fix without adding dummy $SIGMA, but I did not find any discussions of such error message. Can it be fixed? LOWER BOUND INITIAL EST UPPER BOUND -0.6000E+01 0.3290E+01 0.6000E+01 -0.6000E+01 0.9620E+00 0.6000E+01 -0.4000E+01 0.5160E+01 0.1500E+02 -0.1000E+02 -0.2570E+01 0.3000E+01 -0.7000E+01 -0.1290E+01 0.4000E+01 -0.7000E+01 -0.3200E+01 0.2000E+01 -0.5000E+01 0.2810E+01 0.1000E+02 0.1000E+00 0.7020E+00 0.5000E+01 0.1000E-02 0.1000E-02 0.1000E-02 0INITIAL ESTIMATE OF OMEGA: BLOCK SET NO. BLOCK FIXED 1 NO 0.1724E+00 2 NO 0.6246E+00 3 NO 0.1570E+02 4 NO 0.1408E+01 5 NO 0.1183E+01 6 NO 0.1331E+00 7 YES 0.3000E-02 8 YES 0.1000E-02 0A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE Thanks, Pavel
Hi Pavel, This is a generic error message that comes from NONMEM itself. NMTRAN is supposed to detect any mistake in the control stream, and produce a specific error message, e.g., * 582 WITH PRESENT OPTIONS AND POPULATION DATA, EPS VARIABLES ARE REQUIRED.* Either NMTRAN is not catching the error before it gets to NONMEM or NONMEM is generating the error message when it should not. Please send your control stream with a fragment of the data to me and Bob Bauer, and we can investigate the situation and fix it. For now, it appears that the dummy $SIGMA is a good enough workaround. Alison
Quoted reply history
On Thu, Nov 26, 2015, at 05:26 AM, Pavel Belo wrote: > Hello The NONMEM Team, > > I removed $sigma record because ERR(1) and ERR(2) were not used (home- > made likelihood was used instead; SD was parameterized as THETA) and > got "A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE" (see below). > The message sounds rather emotional than mathematical > ("inappropriate"). When I used a dummy record $SIGMA 1 FIX 1 FIX or > $SIGMA 1 FIX the issue disappeared. The reason I removed $sigma was > that some very different SAEM jobs (and possibly some other methods) > did not provide error messages when unused omegas remained in the code > (for example, there are 5 etas and $OMEGA DIAGONAL(6) is used), but > the algorithm became unstable or provided much less meaningful THETAS. > (I believe something similar happened when unnecessary $sigma records > were in the code.) So, I assumed that any unused but reserved sigmas > and omegas can be damaging. It feels like there is a simple fix > without adding dummy $SIGMA, but I did not find any discussions of > such error message. Can it be fixed? > > LOWER BOUND INITIAL EST UPPER BOUND > -0.6000E+01 0.3290E+01 0.6000E+01 > -0.6000E+01 0.9620E+00 0.6000E+01 > -0.4000E+01 0.5160E+01 0.1500E+02 > -0.1000E+02 -0.2570E+01 0.3000E+01 > -0.7000E+01 -0.1290E+01 0.4000E+01 > -0.7000E+01 -0.3200E+01 0.2000E+01 > -0.5000E+01 0.2810E+01 0.1000E+02 > 0.1000E+00 0.7020E+00 0.5000E+01 > 0.1000E-02 0.1000E-02 0.1000E-02 > 0INITIAL ESTIMATE OF OMEGA: > BLOCK SET NO. BLOCK FIXED > 1 NO > 0.1724E+00 > 2 NO > 0.6246E+00 > 3 NO > 0.1570E+02 > 4 NO > 0.1408E+01 > 5 NO > 0.1183E+01 > 6 NO > 0.1331E+00 > 7 YES > 0.3000E-02 > 8 YES > 0.1000E-02 > 0A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE > > Thanks, Pavel -- Alison Boeckmann [email protected]