Very big NONMEM

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 * *

From: [email protected] [mailto:[email protected]] On Behalf Of Bernard Murray Sent: 08 October 2010 9:13 PM To: [email protected] Subject: RE: [NMusers] Very big NONMEM Hello there, Now that the subject of (unusually) large versions of NONMEM has been raised again, I was wondering if it is possible to increase the number of observation records per subject (NO) past the value of 500 provided in the standard "big" version of SIZES with nm7. I am working with NONMEM 7.1.2 with g95 (version 0.93!) on win32 (WinXP SP3) If I increase NO and rebuild everything (as per User Guide III 2.9.2) Windows complains ("Not a valid win32 application"). I have also tried increasing LIM1, LADD and some of the other LIM buffers. I don't know if this is a fundamental limitation or poor understanding on my part. I am actually performing simulations of a somewhat stiff system, with 6 or more DVs over long time periods (weeks). Currently I can fit things in 500 records if I am careful with the selection of timepoints but I was wondering if larger versions than "big" were possible. I have seen some discussion of this subject in previous postings but these were with nmvi or earlier. I do realise that NONMEM may not look like the best tool for this but I'd like to try fitting real world data later. Thanks for any suggestions. All the very best, Bernard Bernard Murray, Ph.D. Senior Research Scientist, Drug Metabolism Gilead Sciences, Foster City CA

________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Xavier Woot de Trixhe Sent: Friday, October 08, 2010 8:25 AM To: NONMEM Subject: [NMusers] Very big NONMEM 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] Web: 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

From: [email protected] [mailto:[email protected]] On Behalf Of Bernard Murray Sent: Saturday, 9 October 2010 8:13 a.m. To: [email protected] Subject: RE: [NMusers] Very big NONMEM Hello there, Now that the subject of (unusually) large versions of NONMEM has been raised again, I was wondering if it is possible to increase the number of observation records per subject (NO) past the value of 500 provided in the standard "big" version of SIZES with nm7. I am working with NONMEM 7.1.2 with g95 (version 0.93!) on win32 (WinXP SP3) If I increase NO and rebuild everything (as per User Guide III 2.9.2) Windows complains ("Not a valid win32 application"). I have also tried increasing LIM1, LADD and some of the other LIM buffers. I don't know if this is a fundamental limitation or poor understanding on my part. I am actually performing simulations of a somewhat stiff system, with 6 or more DVs over long time periods (weeks). Currently I can fit things in 500 records if I am careful with the selection of timepoints but I was wondering if larger versions than "big" were possible. I have seen some discussion of this subject in previous postings but these were with nmvi or earlier. I do realise that NONMEM may not look like the best tool for this but I'd like to try fitting real world data later. Thanks for any suggestions. All the very best, Bernard Bernard Murray, Ph.D. Senior Research Scientist, Drug Metabolism Gilead Sciences, Foster City CA

________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Rik Schoemaker Sent: Friday, 08 October, 2010 21:47 To: 'Bernard Murray'; [email protected] Subject: RE: [NMusers] Very big NONMEM Dear Bernard, What I've recently found is that increasing the size of NO to 1000 would indeed make the application too large, but by then decreasing the number of subjects (MAXIDS; in my case from 15000 to 1500), it makes the footprint manageable again. Maybe going down a factor two to 7500 would have worked as well, but I didn't spend the time on testing more combinations... Apparently NONMEM 8 will adjust the sizes dynamically, but until then we'll just have to twiddle a bit ourselves :-) Cheers, Rik Rik Schoemaker, PhD Exprimo NV Tel:+31 (0)20 4416410 E-mail: [email protected] Web: www.exprimo.com <outbind://7/www.exprimo.com> ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Bernard Murray Sent: 08 October 2010 9:13 PM To: [email protected] Subject: RE: [NMusers] Very big NONMEM Hello there, Now that the subject of (unusually) large versions of NONMEM has been raised again, I was wondering if it is possible to increase the number of observation records per subject (NO) past the value of 500 provided in the standard "big" version of SIZES with nm7. I am working with NONMEM 7.1.2 with g95 (version 0.93!) on win32 (WinXP SP3) If I increase NO and rebuild everything (as per User Guide III 2.9.2) Windows complains ("Not a valid win32 application"). I have also tried increasing LIM1, LADD and some of the other LIM buffers. I don't know if this is a fundamental limitation or poor understanding on my part. I am actually performing simulations of a somewhat stiff system, with 6 or more DVs over long time periods (weeks). Currently I can fit things in 500 records if I am careful with the selection of timepoints but I was wondering if larger versions than "big" were possible. I have seen some discussion of this subject in previous postings but these were with nmvi or earlier. I do realise that NONMEM may not look like the best tool for this but I'd like to try fitting real world data later. Thanks for any suggestions. All the very best, Bernard Bernard Murray, Ph.D. Senior Research Scientist, Drug Metabolism Gilead Sciences, Foster City CA This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use or distribution of the information included in this message is prohibited --- Please immediately and permanently delete.

On 10/08/2010 04:22 PM, Leonid Gibiansky wrote: > 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 > > 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 * * -- --- Xavier Woot de Trixhe, Ir Exprimo NV Tel:+32 (0)485 033872 E-mail: [email protected] Web: 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.