NONMEM Users Network Archive

Hosted by Cognigen

RE: MAXIDS=10000

From: Bob Leary <bleary>
Date: Fri, 1 Dec 2006 09:19:42 -0500

Mark and Nick,

If any of these buffer sizes are used internally as the leading =
dimension
of a Fortran array with 2 or more indices, then to avoid thrashing the =
various caches
it is usually a good idea to make the size an odd number (the point is =
to avoid
numbers which have a factor of 2 or even worse 4 or even worse 8, etc.
An unfortunate memory access pattern in such an array can severely =
inpact performance.

Bob Leary


-----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] MAXIDS=10000


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] MAXIDS=10000
> 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=400 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=400 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=200 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 =
LIM1=1000000 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=400)
> PARAMETER (LIM1=1000000)
> C LIM2: SIZE OF BUFFER 2
> C Altered on installation by NMQual (copyright =
metruminstitute.org): 2006.12.01.2124
> C PARAMETER (LIM2=400)
> PARAMETER (LIM2=5000)
> C LIM3: SIZE OF BUFFER 3
> PARAMETER (LIM3=200)
> C LIM4: SIZE OF BUFFER 4
> PARAMETER (LIM4=50)
> C LIM5: SIZE OF BUFFER 5
> PARAMETER (LIM5=200)
> C LIM6: SIZE OF BUFFER 6
> C Altered on installation by NMQual (copyright =
metruminstitute.org): 2006.12.01.2124
> C PARAMETER (LIM6=400)
> PARAMETER (LIM6=5000)
>
> 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/
Received on Fri Dec 01 2006 - 09:19:42 EST

The NONMEM Users Network is maintained by ICON plc. Requests to subscribe to the network should be sent to: nmusers-request@iconplc.com.

Once subscribed, you may contribute to the discussion by emailing: nmusers@globomaxnm.com.