Hi,
My colleagues and I are running into problems using modelling and simulation
tools which rely on Rcpp (e.g. Stan, mrgsolve, PKPDsim) alongside an existing
NONMEM installation. The problem is that we have TWO versions of compilers
installed - one for NONMEM and one from the Rtools set.
For NONMEM we're using gfortran 4.5.0 installed in C:\Program Files
(x86)\gfortran\libexec\gcc\i586-pc-mingw32\4.5.0. (Running Windows 8).
When Rtools installs it allows me to configure where the RBuildTools sits on
the PATH, but if I put it first (as recommended) then it stops NONMEM picking
up the gfortran compiler above, and NONMEM doesn't run successfully. But if I
put the RBuildTools further down the path, then it doesn't set up c++ as a
command line executable.
If anyone has experience at making these play nicely together without having to
hack the PATH, I'd be really interested to hear from you. While hacking PATH
variables is fine individually, it's not a recipe that's easily rolled out and
supported across an organisation... (Although I'd still like to know how you
might hack the PATH info to get this to work!).
M
Mike K. Smith
Pharmacometrics
Pfizer WRD, Sandwich (IPC 096)
Tel: +44 (0)1304 643561
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this e-mail by
anyone else is unauthorised. If you are not an addressee, any disclosure or
copying of the contents of this e-mail or any action taken (or not taken) in
reliance on it is unauthorised and may be unlawful. If you are not an
addressee, please inform the sender immediately.
Pfizer Limited is registered in England under No. 526209 with its registered
office at Ramsgate Road, Sandwich, Kent CT13 9NJ
Rcpp alongside NONMEM
Hi Mike,
I had the same problem some months ago and what I finally did was to update
the path environment variable for the current R session only with the
following code:
path <- "C:\\RBuildTools" #Write the path to your Rtools or RBuildTools
folder
rtools <- paste(path, "\\bin", sep = "")
gcc <- paste(path, "\\gcc-4.6.3\\bin", sep = "")
path <- strsplit(Sys.getenv("PATH"), ";")[[1]]
new_path <- c(rtools, gcc, path)
new_path <- new_path[!duplicated(tolower(new_path))]
Sys.setenv(PATH = paste(new_path, collapse = ";"))
I always run this before using simulation tools which rely on Rcpp and it
works. When you close your R session this information is lost, so you
wouldn't have problems with other compilers. Then you can leave the NONMEM
gfortran compiler in the first place on the PATH.
If you have more questions, don't hesitate to ask.
Itziar Irurzun
Quoted reply history
2016-11-03 17:42 GMT+01:00 Smith, Mike K <[email protected]>:
> Hi,
>
>
>
> My colleagues and I are running into problems using modelling and
> simulation tools which rely on Rcpp (e.g. Stan, mrgsolve, PKPDsim)
> alongside an existing NONMEM installation. The problem is that we have TWO
> versions of compilers installed – one for NONMEM and one from the Rtools
> set.
>
>
>
> For NONMEM we’re using gfortran 4.5.0 installed in C:\Program Files
> (x86)\gfortran\libexec\gcc\i586-pc-mingw32\4.5.0. (Running Windows 8).
>
>
>
> When Rtools installs it allows me to configure where the RBuildTools sits
> on the PATH, but if I put it first (as recommended) then it stops NONMEM
> picking up the gfortran compiler above, and NONMEM doesn’t run
> successfully. But if I put the RBuildTools further down the path, then it
> doesn’t set up c++ as a command line executable.
>
>
>
> If anyone has experience at making these play nicely together without
> having to hack the PATH, I’d be really interested to hear from you. While
> hacking PATH variables is fine individually, it’s not a recipe that’s
> easily rolled out and supported across an organisation… (Although I’d still
> like to know how you might hack the PATH info to get this to work!).
>
>
>
> M
>
> *Mike K. Smith*
> *Pharmacometrics*
>
> *Pfizer WRD, Sandwich** (IPC 096)*
> Tel: +44 (0)1304 643561
>
> LEGAL NOTICE
>
> Unless expressly stated otherwise, this message is confidential and may be
> privileged. It is intended for the addressee(s) only. Access to this e-mail
> by anyone else is unauthorised. If you are not an addressee, any disclosure
> or copying of the contents of this e-mail or any action taken (or not
> taken) in reliance on it is unauthorised and may be unlawful. If you are
> not an addressee, please inform the sender immediately.
>
> Pfizer Limited is registered in England under No. 526209 with its
> registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ
>
>
>
--
Itziar Irurzun Arana, PhD Student
Department of Pharmacy and Pharmaceutical Technology
School of Pharmacy, University of Navarra
Pamplona, Spain
Hi Mike,
Similar to Itziar, I've run into near-equivalent problems. I've not tested this as a solution, but my thought is to setup a specific batch file that runs NONMEM for me, and at the top of the batch file it updates the PATH variable to point to the NONMEM copy of gfortran, and at the end, it returns the PATH to its original state.
Currently, I don't have similar problems with my Docker setup since NONMEM and gfortran are within the Docker container and can't reasonably interact with the outside environment.
Thanks,
Bill
Quoted reply history
On 11/3/2016 1:48 PM, Itziar Irurzun Arana wrote:
> Hi Mike,
>
> I had the same problem some months ago and what I finally did was to update the path environment variable for the current R session only with the following code:
>
> path <- "C:\\RBuildTools" #Write the path to your Rtools or RBuildTools folder
>
> rtools <- paste(path, "\\bin", sep = "")
> gcc <- paste(path, "\\gcc-4.6.3\\bin", sep = "")
> path <- strsplit(Sys.getenv("PATH"), ";")[[1]]
> new_path <- c(rtools, gcc, path)
> new_path <- new_path[!duplicated(tolower(new_path))]
> Sys.setenv(PATH = paste(new_path, collapse = ";"))
>
> I always run this before using simulation tools which rely on Rcpp and it works. When you close your R session this information is lost, so you wouldn't have problems with other compilers. Then you can leave the NONMEM gfortran compiler in the first place on the PATH.
>
> If you have more questions, don't hesitate to ask.
>
> Itziar Irurzun
>
> 2016-11-03 17:42 GMT+01:00 Smith, Mike K < [email protected] < mailto: [email protected] >>:
>
> Hi,
>
> My colleagues and I are running into problems using modelling and
> simulation tools which rely on Rcpp (e.g. Stan, mrgsolve, PKPDsim)
> alongside an existing NONMEM installation. The problem is that we
> have TWO versions of compilers installed – one for NONMEM and one
> from the Rtools set.
>
> For NONMEM we’re using gfortran 4.5.0 installed in C:\Program
> Files (x86)\gfortran\libexec\gcc\i586-pc-mingw32\4.5.0. (Running
> Windows 8).
>
> When Rtools installs it allows me to configure where the
> RBuildTools sits on the PATH, but if I put it first (as
> recommended) then it stops NONMEM picking up the gfortran compiler
> above, and NONMEM doesn’t run successfully. But if I put the
> RBuildTools further down the path, then it doesn’t set up c++ as a
> command line executable.
>
> If anyone has experience at making these play nicely together
> without having to hack the PATH, I’d be really interested to hear
> from you. While hacking PATH variables is fine individually, it’s
> not a recipe that’s easily rolled out and supported across an
> organisation… (Although I’d still like to know how you might hack
> the PATH info to get this to work!).
>
> M
>
> *Mike K. Smith*
> /Pharmacometrics/
>
> /Pfizer WRD, Sandwich//(IPC 096)/
> Tel: +44 (0)1304 643561 <tel:%2B44%20%280%291304%20643561>
>
> LEGAL NOTICE
>
> Unless expressly stated otherwise, this message is confidential
> and may be privileged. It is intended for the addressee(s) only.
> Access to this e-mail by anyone else is unauthorised. If you are
> not an addressee, any disclosure or copying of the contents of
> this e-mail or any action taken (or not taken) in reliance on it
> is unauthorised and may be unlawful. If you are not an addressee,
> please inform the sender immediately.
>
> Pfizer Limited is registered in England under No. 526209 with its
> registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ
>
> --
>
> Itziar Irurzun Arana, PhD Student
> Department of Pharmacy and Pharmaceutical Technology
> School of Pharmacy, University of Navarra
> Pamplona, Spain
------------------------------------------------------------------------
Human Predictions Logo < http://www.humanpredictions.com >*William S. Denney, PhD*
Chief Scientist, Human Predictions LLC
+1-617-899-8123
[email protected]
This e-mail communication is confidential and is intended only for the individual(s) or entity named above and others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by replying to the e-mail or by calling +1-617-899-8123. Please then delete the e-mail and any copies of it. Thank you.
If you have nonmem7.3 or greater, then you can fill in nmloc or nmloc.bat in
the root nonmem installation directory with the gfortran path.
Then nonmem executions will rely on the location of gfortran specified in the
nmloc file.
Please see section I.5 of nm730.pdf for details.
Robert J. Bauer, Ph.D.
Pharmacometrics R&D
ICON Early Phase
820 W. Diamond Avenue
Suite 100
Gaithersburg, MD 20878
Office: (215) 616-6428
Mobile: (925) 286-0769
[email protected]<mailto:[email protected]>
http://www.iconplc.com/
Quoted reply history
From: [email protected] [mailto:[email protected]] On
Behalf Of Itziar Irurzun Arana
Sent: Thursday, November 03, 2016 10:49 AM
To: Smith, Mike K
Cc: [email protected]
Subject: Re: [NMusers] Rcpp alongside NONMEM
Hi Mike,
I had the same problem some months ago and what I finally did was to update the
path environment variable for the current R session only with the following
code:
path <- "C:\\RBuildTools" #Write the path to your Rtools or RBuildTools
folder
rtools <- paste(path, "\\bin<file:///\\bin>", sep = "")
gcc <- paste(path, "\\gcc-4.6.3\\bin<file:///\\gcc-4.6.3\bin>", sep = "")
path <- strsplit(Sys.getenv("PATH"), ";")[[1]]
new_path <- c(rtools, gcc, path)
new_path <- new_path[!duplicated(tolower(new_path))]
Sys.setenv(PATH = paste(new_path, collapse = ";"))
I always run this before using simulation tools which rely on Rcpp and it
works. When you close your R session this information is lost, so you wouldn't
have problems with other compilers. Then you can leave the NONMEM gfortran
compiler in the first place on the PATH.
If you have more questions, don't hesitate to ask.
Itziar Irurzun
2016-11-03 17:42 GMT+01:00 Smith, Mike K
<[email protected]<mailto:[email protected]>>:
Hi,
My colleagues and I are running into problems using modelling and simulation
tools which rely on Rcpp (e.g. Stan, mrgsolve, PKPDsim) alongside an existing
NONMEM installation. The problem is that we have TWO versions of compilers
installed – one for NONMEM and one from the Rtools set.
For NONMEM we’re using gfortran 4.5.0 installed in C:\Program Files
(x86)\gfortran\libexec\gcc\i586-pc-mingw32\4.5.0. (Running Windows 8).
When Rtools installs it allows me to configure where the RBuildTools sits on
the PATH, but if I put it first (as recommended) then it stops NONMEM picking
up the gfortran compiler above, and NONMEM doesn’t run successfully. But if I
put the RBuildTools further down the path, then it doesn’t set up c++ as a
command line executable.
If anyone has experience at making these play nicely together without having to
hack the PATH, I’d be really interested to hear from you. While hacking PATH
variables is fine individually, it’s not a recipe that’s easily rolled out and
supported across an organisation… (Although I’d still like to know how you
might hack the PATH info to get this to work!).
M
Mike K. Smith
Pharmacometrics
Pfizer WRD, Sandwich (IPC 096)
Tel: +44 (0)1304 643561<tel:%2B44%20%280%291304%20643561>
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this e-mail by
anyone else is unauthorised. If you are not an addressee, any disclosure or
copying of the contents of this e-mail or any action taken (or not taken) in
reliance on it is unauthorised and may be unlawful. If you are not an
addressee, please inform the sender immediately.
Pfizer Limited is registered in England under No. 526209 with its registered
office at Ramsgate Road, Sandwich, Kent CT13 9NJ
--
Itziar Irurzun Arana, PhD Student
Department of Pharmacy and Pharmaceutical Technology
School of Pharmacy, University of Navarra
Pamplona, Spain