Re: Very big NONMEM

From: Leonid Gibiansky Date: October 08, 2010 technical Source: mail-archive.com
Just out of curiosity, what type of problem will require 100K subjects? If this is parametric, 15K should be sufficient to describe any number of normal-type distributions. Is this a non-parametric model to catch a very rare events? Thanks Leonid -------------------------------------- Leonid Gibiansky, Ph.D. President, QuantPharm LLC web: www.quantpharm.com e-mail: LGibiansky at quantpharm.com tel: (301) 767 5566
Quoted reply history
On 10/8/2010 8:25 AM, Xavier Woot de Trixhe wrote: > Hi, > > NONMEM7 is limited to 15000 individuals (in big install), which is a lot > but not enough for a project.... > > A quick look at the SIZES_reg & SIZES_big files showed the following: > > !CTL > ! MAXIDS: MAX. NO. OF INDIVIDUALS IN DATA SET > PARAMETER (MAXIDS=15000)! TL 4/22/09 > > Setting this to 100k I hoped for the best... Reinstalling nonmem with > recompilation (Intel fortran 11 on Linux x64) everything goes smoothly > Unfortunately the very last steps gives a nasty error message in > function `pk_` (PrGlobal.o). (see Appendix A) > > After some googling I found this: > http://software.intel.com/en-us/articles/avoiding-relocation-errors-when-building-applications-with-large-global-or-static-data-on-intel64/ > In essence there is more than 2Gig allocated for data and adding the > -mcmodel=medium option to the setup (SESTU7 line 358) should solve the > issue... > > Unfortunately this only moved the issue to function `output_open_' > (NMDATA.o). (see Appendix B) > > Now I am out of ideas... > > So here are my questions, if anyone can help it would be great > 1) How do I compute the size of the data array? MAXID * NO * ?? * > sizeof( a number ) > 2) Why does output_open fail? > 3) Has anyone done this before? > > K. Regards, > > Xavier > > PS: In SETUP7 only allows SIZES_reg and SIZES_big to replace SIZES.f90 > It might be nice to allow any SIZES_xxx as template for SIZES.f90 (not > to mess up the defaults) > > Is disabling lines 112-118 and changing line 275 onwards to the > following code enough to do the trick? > > if [ -s ./resource/SIZES_$s ]; then > echo Using resource/SIZES_$s > cp resource/SIZES_$s resource/SIZES.f90 > else > if [ -e resource/SIZES.f90 ] > then > echo Using existing resource/SIZES.f90 > else > echo Using resource/SIZES_reg > cp resource/SIZES_reg resource/SIZES.f90 > fi > fi > > Appendix A: > > Testing the installation. Commands are > cd /opt/NONMEM/7.1.0/huge_i11.1/run > ./nmfe7 CONTROL5 REPORT5.txt > If the run is successful, file REPORT5.txt will be created. > > WARNINGS AND ERRORS (IF ANY) FOR PROBLEM 1 > > (WARNING 2) NM-TRAN INFERS THAT THE DATA ARE POPULATION. > > (WARNING 43) THE $PK BLOCK REQUESTS "CALL ONCE PER INDIVIDUAL RECORD", BUT > DATA ITEMS ARE USED IN THE $PK BLOCK. VALUES OF THESE DATA ITEMS > SUBSEQUENT TO THOSE FROM THE FIRST EVENT RECORD WILL BE IGNORED. IF THIS > IS NOT APPROPRIATE, THE CALL DATA ITEM CAN BE USED TO OBTAIN ADDITIONAL > CALLS, OR $PK'S CALLING PROTOCOL SHOULD BE CHANGED. > CREATING MUMODEL ROUTINE... > /tmp/ifortNDVtJq.o: In function `pk_': > FSUBS.f90:(.text+0x56): relocation truncated to fit: R_X86_64_PC32 > against symbol `procm_int_mp_pnewif_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(PrGlobal.o) > FSUBS.f90:(.text+0x6f): relocation truncated to fit: R_X86_64_32 against > symbol `nmprd_real_mp_eta_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(Global.o) > FSUBS.f90:(.text+0x84): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd_int_mp_iquit_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(Global.o) > FSUBS.f90:(.text+0x97): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd_real_mp_eta_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(Global.o) > FSUBS.f90:(.text+0xab): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd_real_mp_eta_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(Global.o) > FSUBS.f90:(.text+0xd2): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd4p_mp_ka_' defined in COMMON section in > /tmp/ifortNDVtJq.o > FSUBS.f90:(.text+0xe1): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd4p_mp_a00071_' defined in COMMON section in > /tmp/ifortNDVtJq.o > FSUBS.f90:(.text+0xf8): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd_real_mp_eta_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(Global.o) > FSUBS.f90:(.text+0x102): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd4p_mp_k_' defined in COMMON section in > /tmp/ifortNDVtJq.o > FSUBS.f90:(.text+0x10e): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmprd4p_mp_a00072_' defined in COMMON section in > /tmp/ifortNDVtJq.o > FSUBS.f90:(.text+0x119): additional relocation overflows omitted from > the output > No nonmem execution. > > Appendix B: > Testing the installation. Commands are > cd /opt/NONMEM/7.1.0/huge_i11.1/run > ./nmfe7 CONTROL5 REPORT5.txt > If the run is successful, file REPORT5.txt will be created. > > WARNINGS AND ERRORS (IF ANY) FOR PROBLEM 1 > > (WARNING 2) NM-TRAN INFERS THAT THE DATA ARE POPULATION. > > (WARNING 43) THE $PK BLOCK REQUESTS "CALL ONCE PER INDIVIDUAL RECORD", BUT > DATA ITEMS ARE USED IN THE $PK BLOCK. VALUES OF THESE DATA ITEMS > SUBSEQUENT TO THOSE FROM THE FIRST EVENT RECORD WILL BE IGNORED. IF THIS > IS NOT APPROPRIATE, THE CALL DATA ITEM CAN BE USED TO OBTAIN ADDITIONAL > CALLS, OR $PK'S CALLING PROTOCOL SHOULD BE CHANGED. > CREATING MUMODEL ROUTINE... > /opt/NONMEM/7.1.0/huge_i11.1/nm/nonmem.a(ifortlinux.o): In function > `output_open_': > ifortlinux.f:(.text+0x17): relocation truncated to fit: R_X86_64_PC32 > against symbol `nmdata_mp_iun_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(NMDATA.o) > /opt/NONMEM/7.1.0/huge_i11.1/nm/nonmem.a(ifortlinux.o): In function > `output_open2_': > ifortlinux.f:(.text+0xfb): relocation truncated to fit: R_X86_64_32S > against symbol `nmdata_mp_iun_' defined in COMMON section in > /opt/NONMEM/7.1.0/huge_i11.1/resource/resource.a(NMDATA.o) > /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o): > In function `for__io_return': > for_diags_intel.c:(.text+0xcb): relocation truncated to fit: R_X86_64_32 > against `tmp_buf' > for_diags_intel.c:(.text+0xf4): relocation truncated to fit: R_X86_64_32 > against `tmp_buf' > for_diags_intel.c:(.text+0x64d): relocation truncated to fit: > R_X86_64_PC32 against symbol `for__user_iomsg_len' defined in .bss > section in > /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0x654): relocation truncated to fit: > R_X86_64_PC32 against symbol `for__user_iomsg_buf' defined in .bss > section in > /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0x892): relocation truncated to fit: > R_X86_64_PC32 against symbol `for__user_iomsg_len' defined in .bss > section in > /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0x899): relocation truncated to fit: > R_X86_64_PC32 against symbol `for__user_iomsg_buf' defined in .bss > section in > /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0x9f7): relocation truncated to fit: > R_X86_64_PC32 against symbol `message_catalog' defined in COMMON section > in /opt/intel/Compiler/11.1/056/lib/intel64/libifcore.a(for_diags_intel.o) > for_diags_intel.c:(.text+0xa38): relocation truncated to fit: > R_X86_64_PC32 against `tmp_ptr' > for_diags_intel.c:(.text+0xab9): additional relocation overflows omitted > from the output > No nonmem execution. > > You should now compare REPORT5.txt vs. REPORT5IDS.txt > Values should be similar. > E.g., the following should be identical: > grep #OBJV: REPORT5.txt > grep: REPORT5.txt: No such file or directory > grep #OBJV: REPORT5IDS.txt > > -- > --- > Xavier Woot de Trixhe, Ir > Exprimo NV > Tel:+32 (0)485 033872 > E-mail:[email protected] <mailto:[email protected]> > Web:www.exprimo.com http://www.exprimo.com > > This e-mail is confidential. It is also privileged or otherwise protected by > work product immunity or other legal rules. The information is intended to be > for use of the individual or entity named above. If you are not the intended > recipient, please be aware that any disclosure, copying, distribution or use of > the contents of this information is prohibited. You should therefore delete > this message from your computer system. If you have received the message in > error, please notify us by reply e-mail. The integrity and security of this > message cannot be guaranteed on the Internet. > > Thank you for your co-operation. > > This e-mail message has been scanned for Viruses by Norman Virus Control > and it's Content by MailMarshal * *
Oct 08, 2010 Xavier Woot de Trixhe Very big NONMEM
Oct 08, 2010 Leonid Gibiansky Re: Very big NONMEM
Oct 08, 2010 Bernard Murray RE: Very big NONMEM
Oct 08, 2010 Rik Schoemaker RE: Very big NONMEM
Oct 08, 2010 Thomas Ludden RE: Very big NONMEM
Oct 08, 2010 Stephen Duffull RE: Very big NONMEM
Oct 11, 2010 Jeroen Elassaiss-Schaap RE: Very big NONMEM
Oct 11, 2010 Xavier Woot de Trixhe Re: Very big NONMEM