Warning: NMTRAN does not interpret conditional abbreviated code properly

From: Nick Holford <n.holford@auckland.ac.nz> Subject: Warning: NMTRAN does not interpret conditional abbreviated code properly Date: Sun, 27 Aug 2000 10:10:15 +1200 Hi, The following fragment from an NMTRAN control stream has "DOSCAS=0.0 ;set doscas=0 for all RX.NE.1" as the first statement in the first IF_THEN_ELSE block. This statement is not copied to the FSUBS Fortran source created by NMTRAN which means that DOSCAS is not initialized properly when RX.NE.1. This failure to copy parts of nested conditional statements suggests care is needed when using conditional statements, particularly nested ones with NMTRAN abbreviated code. Do not assume that statements that are not within the innermost IF THEN ELSE blocks are properly or entirely copied by NMTRAN. NMTRAN Control Stream IF (RX.EQ.1) THEN TVBA=THETA(3) F0ST=THETA(14) DOSCAS=1.0 ELSE DOSCAS=0.0 ;set doscas=0 for all RX.NE.1 IF (RX.EQ.2) THEN TVBA=THETA(4) F0ST=THETA(15) ELSE IF (RX.EQ.3) THEN TVBA=THETA(5) F0ST=THETA(16) ELSE TVBA=THETA(6) F0ST=THETA(17) ENDIF ENDIF ENDIF FSUBS Generated by NMTRAN. No value assigned to DOSCAS if RX.NE.1 IF(RX.EQ.1.D0)THEN TVBA=THETA(03) F0ST=THETA(14) DOSCAS=1.D0 ELSE IF(RX.EQ.2.D0)THEN TVBA=THETA(04) F0ST=THETA(15) ELSE IF(RX.EQ.3.D0)THEN TVBA=THETA(05) F0ST=THETA(16) ELSE TVBA=THETA(06) F0ST=THETA(17) ENDIF ENDIF ENDIF -- Nick Holford, Dept Pharmacology & Clinical Pharmacology University of Auckland, Private Bag 92019, Auckland, New Zealand email:n.holford@auckland.ac.nz tel:+64(9)373-7599x6730 fax:373-7556 http://www.phm.auckland.ac.nz/Staff/NHolford/nholford.htm

From: "Jean-Xavier.Mazoit@kb.u-psud.fr" <jean-xavier.mazoit@kb.u-psud.fr> Subject: Conditional statements and NMTRAN Date: Tue, 29 Aug 2000 11:47:19 +0200 Dear all, Nick Holford is right. It is necessary to be careful with the abbreviated code and to use only very simple statements. For example, I only use IFTHEN non-nested statements. In this case you get a warning message from NMTRAN because you need to be certain that all the possible conditions are covered by the code. It is better to be obliged to check everything rather than to have a wrong generated code. Jean Xavier Mazoit MD, PhD Laboratoire d'Anesthésie Université Paris-Sud Faculté de Médecine du Kremlin-Bicêtre F-94276 Bicêtre France Tel. (33) (0)1 49 59 67 35-37 (33) (0)1 45 21 34 41 (Hopital) Fax (33) (0)1 45 21 28 75 e-mail Jean-Xavier.Mazoit@kb.u-psud.fr

From: ABoeckmann <alison@c255.ucsf.edu> Subject: nested if Date: Wed, 30 Aug 2000 11:00:49 -0700 (PDT) Nick Holford and Jean Xavier Mazoit have recently sent email about a problem in NMTRAN in handling nested IF statements. They are correct. There is a bug in NMTRAN. As soon as this bug can be identified and characterized, more information will be sent. Till then, avoid nested IF statements, especially if there is more than one ELSE clause (i.e., ELSE in a level other than the first). If you do have such code, look carefully at the generated code in FSUBS. -- Alison Boeckmann NONMEM Project Group

From: ABoeckmann <alison@c255.ucsf.edu> Subject: NMTRAN bug fix Date: Mon, 25 Sep 2000 08:34:34 -0700 (PDT) Nick Holford and Jean Xavier Mazoit have recently sent email describing a bug in NMTRAN that affects both generated and NMTRAN Library routines when the abbreviated code contains nested IF statements. The bug does not in fact affect all codes with nested IF statements. The bug may affect abbreviated code in which a variable is defined in an ELSE block and then redefined in another ELSE block which is nested within the first ELSE block. If you can avoid such nested ELSE blocks, you will avoid the bug. The chances are good that you have not encountered this bug, and can easily avoid it in the future, because the bug *cannot* affect the following kinds of code: 1) Code defining random variables. Nested IF statements cannot be used in such code. 2) Initialization, finalization or simulation blocks, i.e., a block of code that starts with one of the following: IF (ICALL.EQ.0) THEN IF (ICALL.EQ.1) THEN IF (ICALL.EQ.3) THEN IF (ICALL.EQ.4) THEN 3) Nested IF statements that do not contain ELSE within ELSE. You can fix this bug by making changes to NM-TRAN source code, as described below. Once CPYOLD and SAVOLD source code have been changed, NMTRAN must be recompiled. (See Users Guide III, p, 125 and p. 130, in which we suggest erasing all object modules (.obj or .o) in the tr subdirectory, and using the SETUP command as it was originally typed.) Here are changes you may make to the NM-TRAN source code. 1) Changes to subroutine CPYOLD Note that character "X" must be in column 6 of the Fortran source record. Locate: IF (LHSTYP(K).EQ.35.AND.LHSPOS(K).EQ.ITEMP) THEN Replace with: IF (LHSTYP(K).EQ.35.AND. X (LHSPOS(K).EQ.SAVTRU(I).OR.LHSPOS(K).EQ.SAVELS(I))) THEN Locate: IF (RHSTYP(J).EQ.35.AND.RHSPOS(J).EQ.ITEMP) THEN Replace with: IF (RHSTYP(J).EQ.35.AND. X (RHSPOS(J).EQ.SAVTRU(I).OR.RHSPOS(J).EQ.SAVELS(I))) THEN 2) Changes to subroutine SAVOLD Locate: DO 75 J=1,KOLD Replace with: DO 75 J=KOLD,1,-1 Locate: JOLD=J Replace with: IF (SAVTRU(J).EQ.0) GO TO 80 JOLD=J