RE: MAXIDS=10000

-----Original Message----- From: owner-nmusers [mailto:owner-nmusers Solutions Sent: Friday, December 01, 2006 7:31 AM To: Nick Holford Cc: nmusers Subject: RE: [NMusers] MAXIDS000 Nick, You make a good point about LIM1, and the others. Interestingly, I tried this, maybe 10 years ago, thinking I might be able to improve performance (reduced I/O). The good news is that the memory footprint of NONMEM is, as you point out, really small, so increasing buffer sizes really doesn't hurt, they will all fit easily in memory. The bad news is that it didn't help at all. I was told (and it makes sense to me), that modern operating systems are very, very good at figuring out what to buffer from disc. So, even if you tell NONMEM only to keep a small part of the data, the OS keeps pretty much all of it in memory, when you have 1 Gb of memory and only 800k of data, not a challenge. If you look at the task manager, you'll almost always see NONMEM at 100%, meaning it really isn't waiting for any disc I/O. But, your point is good, the days of when memory was an issue for NONMEM are long past, but my experience is that is doesn't make much difference, at least in Windows (and I'd guess Linux is at least as good a memory management). It may be time to try it again, did you benchmark your version with the large LIM1? Mark Sale MD Next Level Solutions, LLC www.NextLevelSolns.com > -------- Original Message -------- > Subject: Re: [NMusers] MAXIDS000 > From: Nick Holford <n.holford > Date: Fri, December 01, 2006 4:59 am > To: nmusers <nmusers > > Mark, > > Thanks for suggesting I look at LIM6. > > I've struggled again to comprehend Guide III Installation (the NMVI version is not changed from NMV). > These are the key words I think: > > "The size of buffer 1 is related to the number, LIM1, of data records stored in memory at > any one time. A large proportion of data sets will consist of no more than 400 data > records. Consequently, the size of buffer 1 has been set to allow LIM1@0 data records. > The least number of data records allowable must exceed the largest number of data > records used with any one individual, which rarely will be as large as 400." > > The size of buffer 2 has been set to allow LIM2@0 residual records. > The least number of residual records allowable must exceed the largest number of data > records used with any one individual, which rarely will be as large as 400. > > The size of buffer 6 has been set to allow LIM6 0 PREDdefined > records. The least number of PRED-defined records allowable must exceed the > largest number of data records used with any one individual, which rarely will be as large > as 200." > > It seems that the values for LIM1, LIM2 and LIM6 should be no less than the maximum number of data records in any one individual. The way I intepret a data record it means any kind of record, observation, dose, other event, etc. (i.e. EVID 0 to 4). But for LIM1 it may be helpful to increase its value up to the maximum total number of records in the data set so that as many records as possible stay in memory (or at least in virtual memory). > > LIM2 and LIM6 need only be the size of the largest number of data records used with any one individual. But I dont understand why the "rarely will be as large" example for LIM2 is 400 and for LIM6 is only 200. > > I increased LIM1 to 2500000 (I have just under 2.5 million recs) but Windows 2003 Server with 1 GB RAM wouldn't start the executable - I suspect because it wanted too much initial memory. However with LIM100000 and LIM2 and LIM6 to 5000 (I have upto 3200 recs/subject) then NONMEM started. The NONMEM executable uses 90 MB of actual memory and 711 MB of virtual memory and there are no page faults reported by the Task Manager. I assume this means that most of the data is in actual memory. > > There doesn't seem to be any good reason to have LIM1, LIM2 and LIM6 set to the same small default values of 400. I think LIM2 and LIM6 should usually be the same and LIM1 some multiple of LIM2 (or LIM6) reflecting the number of individuals in the typical data set. > > C LIM1: SIZE OF BUFFER 1 > C Altered on installation by NMQual (copyright metruminstitute.org): 2006.12.01.2124 > C PARAMETER (LIM1@0) > PARAMETER (LIM100000) > C LIM2: SIZE OF BUFFER 2 > C Altered on installation by NMQual (copyright metruminstitute.org): 2006.12.01.2124 > C PARAMETER (LIM2@0) > PARAMETER (LIM2P00) > C LIM3: SIZE OF BUFFER 3 > PARAMETER (LIM3 0) > C LIM4: SIZE OF BUFFER 4 > PARAMETER (LIM4P) > C LIM5: SIZE OF BUFFER 5 > PARAMETER (LIM5 0) > C LIM6: SIZE OF BUFFER 6 > C Altered on installation by NMQual (copyright metruminstitute.org): 2006.12.01.2124 > C PARAMETER (LIM6@0) > PARAMETER (LIM6P00) > > Mark Sale - Next Level Solutions wrote: > > > > Nick, > > There is a buffer 6 size parameter (LIM6) in NSIZES in v5 and in > > SIZES in v6. I don't recall what array(s) are dimensioned with this. > > But, looks like the default size in v5 is 600 and default is 400 in v6. > > Another upward compatiability problem, perhaps. Do you have an > > individual with between 400 and 600 observations? > > > > Mark Sale MD > > Next Level Solutions, LLC > > www.NextLevelSolns.com > > > > -- > Nick Holford, Dept Pharmacology & Clinical Pharmacology > University of Auckland, 85 Park Rd, Private Bag 92019, Auckland, New Zealand > email:n.holford > http://www.health.auckland.ac.nz/pharmacology/staff/nholford/