Paolo: MCETA=5 is a small number of random samples of etas to test, and when you parallelize, your random seed pattern changes, unless, you include $EST RANMETHOD=P. Yes, sometimes a worse result follows if a lower OBJ is chosen, yet those etas that gave a lower OBJ offered a worse path than when eta=0. I suggest the following:
$EST METHOD=1 INTERACTION MAXEVAL=0 MCETA=1000 RANMETHOD=P ... ; spend a lot of random samples doing a thorough search with MCETA=1000, but it takes time, so do it just for the first iteration. $EST METHOD=1 INTERACTION MAXEVAL=9999 MCETA=5 RANMETHOD=P ... ; remaining iterations use MCETA more lightly. Robert J. Bauer, Ph.D. Vice President, Pharmacometrics, R&D ICON Development Solutions 7740 Milestone Parkway Suite 150 Hanover, MD 21076 Tel: (215) 616-6428 Mob: (925) 286-0769 Email: [email protected] Web: www.iconplc.com -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paolo Denti Sent: Tuesday, July 29, 2014 3:54 PM To: nmusers Subject: [NMusers] Funny behaviour with MCETA>1 and parallel computation Dear all, I am working with FOCE-INTERACTION and a PK model with some issues in optimising the individual ETAs. A couple of subjects in the dataset are very fast absorbers and sometimes NONMEM fails to find the optimal value for their individual ETAs. This results in the OFV randomly jumping up a lot (~100 points) when I restart the model from the final estimates of a previous run. The model may sometimes find its way back to the same minimum, but not always. So I decided to use the new feature MCETA, which is supposed to address these kinds of issues by trying several randomly generated sets of initial ETAs, increasing the chance of finding the best value of individual ETA for each subject. I first tested the new feature on a single CPU and everything worked as expected: using MCETA=0 (the default) the OFV jumps up after restarting with the final values, while with MCETA=5 the problem is solved and the OFV is stable. I then ran the same test using the parallel computation feature to speed it up, but I noticed that here the OFV was jumping up anyway. Not only, using MCETA=5 was actually giving a WORSE OFV than the default value of MCETA=0, which is indeed giving the same result irrespectively of whether I use the parallel computation or not. I have retried several times to make sure I hadn't made any mistakes and when I use MCETA>1 and the parallel computation feature, it sometimes perform worse than the default MCETA=0. I tried other values of MCETA too, but same story. When I say that the OFV goes up, I am referring to the first iteration, so I have replicated these results using MAXEVAL=0. Any suggestion about what may be going on? My understanding is that using MCETA>1 CANNOT be any worse than the default behaviour (MECTA=0) of just using 0 as initial value. The guide says NONMEM is supposed to try both 0 AND some other values as initial estimates, and choose in every subject the option that minimises the OFV. So in the worst case scenario NONMEM will just use 0 and I will have wasted some electrons. Am I misunderstanding something? Sorry for the lengthy email and thanks for any input on this. Paolo -- ------------------------------------------------ Paolo Denti, PhD Pharmacometrics Group Division of Clinical Pharmacology Department of Medicine University of Cape Town K45 Old Main Building Groote Schuur Hospital Observatory, Cape Town 7925 South Africa phone: +27 21 404 7719 fax: +27 21 448 1989 email: [email protected] ------------------------------------------------ ________________________________ UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. <br /><br /> ICON plc made the following annotations. ------------------------------------------------------------------------------ This e-mail transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that ICON plc can arrange for proper delivery, and then please delete the message. Thank You, ICON plc South County Business Park Leopardstown Dublin 18 Ireland Registered number: 145835
