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
message "A VALUE IN THE ESTIMATION RECORD IS INAPPROPRIATE" whene there is no $sigma record
2 messages
2 people
Latest: Nov 26, 2015
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]