Very big NONMEM

From: Xavier Woot de Trixhe Date: October 08, 2010 technical Source: mail-archive.com
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
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