Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

could you provide an example of running nonmem from R (on windows)? #6

Closed
nskoch opened this issue Oct 13, 2023 · 23 comments
Closed

could you provide an example of running nonmem from R (on windows)? #6

nskoch opened this issue Oct 13, 2023 · 23 comments

Comments

@nskoch
Copy link

nskoch commented Oct 13, 2023

No description provided.

@philipdelff
Copy link
Collaborator

Unfortunately, Windows is still not supported. I assume you are running Nonmem on Windows and not only R (connecting to a linux/unix machine running Nonmem).

It is a small task implementing support for Windows - especially if using PsN to call Nonmem. However, I don't use windows myself, and I could use some help.

I hope someone who is familiar with running Nonmem in Windows can help implementing this. Essentially, we need a system() call that will call PsN's execute on a Nonmem control stream and then close (return to the R console). Anyone?

@philipdelff
Copy link
Collaborator

@nskoch Would you be able to test this from the git main branch? I think it should now work with PSN if you have that installed.

Install from github:
library(remotes)
install_github("philipdelff/NMsim")

You can use this script to test a basic simulation:
https://github.com/philipdelff/NMsim/blob/main/inst/examples/R/testrun_NMsim.R

Currently, only the PSN execution method seems to work on Windows. This will allow you to do most with NMsim. If this works, next step will be to get the internal Nonmem execution method to work. That will unlock some more features to Windows users.

@nskoch
Copy link
Author

nskoch commented Oct 19, 2023 via email

@philipdelff
Copy link
Collaborator

Thank you Nicolas,

I would currently not recommend NMsim if the main purpose is running/calling Nonmem from R on a Windows system. NMsim does include the NMexec() function to call Nonmem but it's developed on linux and windows still needs work.

If you want to simulate Nonmem models from R, that is where NMsim becomes really helpful. Currently on Windows it has to be used in combination with PSN but that will hopefully soon be improved.

Best,
Philip

@philipdelff
Copy link
Collaborator

philipdelff commented Jul 17, 2024 •
edited
Loading

Hi @nskoch ,

I think this works in recent NMsim versions, 0.1.1 and 0.1.2. You can try this to run Nonmem on a model:

library(NMdata)
library(NMsim)
## Path to Nonmem executable on your system. This is an example:
NMdataConf(path.nonmem ="C:/nm75g64/run/nmfe75.bat")

## run Nonmem on a control stream:
NMexec("path/to/myctl.mod",sge=FALSE)

If you try this, I would appreciate feedback.

By the way, simulation is supported in windows so you can use NMsim() to simulate with the model.

@nskoch
Copy link
Author

nskoch commented Jul 18, 2024 via email

@philipdelff
Copy link
Collaborator

Thank you @nskoch !

That is not a very helpful error, but it looks like something we should be able to solve. It looks like there is no data available for some reason.

Before getting deeper into it, please make sure you have recent versions of NMdata and NMsim, so we are not looking into issues that have been solved already.

## NMdata should be 0.1.6
packageVersion("NMdata")
## NMsim should be 0.1.1 or 0.1.2
packageVersion("NMsim")

## If your package versions are older, you can upgrade this way (making sure we install from CRAN):
unloadNamespace("NMdata")
unloadNamespace("NMsim")
install.packages("NMdata",repos="https://cloud.r-project.org")
install.packages("NMsim",repos="https://cloud.r-project.org")

I don't have that example in my Nonmem installation, and I am unsure whether it is a complete example with data and correct paths. Can you try on one of your own models to see if you get the same issue? You can also try on a model provided with NMsim like:

NMexec(system.file("examples/nonmem/xgxr021.mod",package="NMsim"),sge=FALSE)

The drawback of using that example is that it will run it inside your NMsim installation folder. Not really a problem but not ideal either.

Best,
Philip

@nskoch
Copy link
Author

nskoch commented Jul 22, 2024 via email

@philipdelff
Copy link
Collaborator

Hi Simon @nskoch ,

NMsim is trying to run Nonmem through PSN's execute. It does so because it does not know where the Nonmem executable is located. Previously, you wrote this:

NMdataConf(path.nonmem ="C:/nm75g64/run/nmfe75.bat")

This is exactly how to tell NMsim where to find the Nonmem executable. Did you forget to execute that command this time? Note that NMdataConf() is a NMdata function so you need to load NMdata too.

@nskoch
Copy link
Author

nskoch commented Jul 22, 2024 via email •
edited by philipdelff
Loading

@philipdelff
Copy link
Collaborator

philipdelff commented Jul 22, 2024 via email •
edited
Loading

@nskoch
Copy link
Author

nskoch commented Jul 22, 2024 via email •
edited by philipdelff
Loading

@philipdelff
Copy link
Collaborator

Execellent @nskoch ,

Let me recap. NMexec() does successfully execute Nonmem on a control stream on your Windows system. However, it was tricky to figure out how to make it do that in the absence of PSN. We saw that

  • NMsim needs the path to the Nonmem bat file. This can be provided as an argument to NMsim()/NMexec() using the path.nonmem argument or as you did using NMdata's configuration tool: NMdataConf(), again using the same path.nonmem argument. This is as expected because NMsim has no method to find this installation on its own.

  • On Windows, NMsim still relies on PSN even when path.nonmem is provided. You had to explicitly tell NMexec() to use the internal method by specifying method.execute="nmsim" In NMsim >= 0.1.1 this is not intended.

Can you please make sure if you have NMsim >= 0.1.1 by running this?

packageVersion("NMsim")

It is worth noting that having NMsim use its internal execution method is preferable over having it use PSN. The extra flexibility of using the built-in method allows NMsim to perform additional types of simulations.

@nskoch
Copy link
Author

nskoch commented Jul 23, 2024 via email

@philipdelff
Copy link
Collaborator

Thank you @nskoch

I consider this a bug. method.execute="nmsim" should be default when specifying path.nonmem.

It would also be useful to have a function available to the user to test what methods work on their system, given the installation paths they have provided. Something to work towards.

@nskoch
Copy link
Author

nskoch commented Aug 9, 2024 via email

@philipdelff
Copy link
Collaborator

philipdelff commented Aug 9, 2024 via email •
edited
Loading

@nskoch
Copy link
Author

nskoch commented Aug 9, 2024 via email •
edited by philipdelff
Loading

@philipdelff
Copy link
Collaborator

My bad, I read that too quickly.

The two instances of NMexec() that you are showing are different in two ways. They use distinct Nonmem installations due to the different path.nonmem paths, and they run on distinct control streams due to the different file.mod values.

The error you are getting is not very intuitive. But it suggests that the input data used by
C:/nm74g64/run/test/CONTROL6.ctl
is not being read correctly. This happens before calling Nonmem, so it does not look to me like it has to do with differences between the Nonmem executables - it seems to be the two control streams and their input data sets.

Can you please check that the input data set listed in that control stream exists on your file system? You can try to read it using
dat.inp <- NMdata::NMscanInput("C:/nm74g64/run/test/CONTROL6.ctl",applyFilters = FALSE)
If the input data file exists, but NMscanInput() fails, it would be useful to see the error. In that case, I am also curious about your NMdata version. You can check that with packageVersion("NMdata").

Best,
Philip

@nskoch
Copy link
Author

nskoch commented Aug 10, 2024 via email

@philipdelff
Copy link
Collaborator

Hi Nicolas,

Thank you for your patience and continued efforts to resolve this.

This seems to be an issue related to reading the input data file used by
"C:/nm74g64/run/test/CONTROL6.ctl"
Worth noting, the issue does not seem to affect reading the input data file from:
"C:/nm75g64/run/test/CONTROL6.ctl"

I don't have these files in my Nonmem installations so I can't debug well without your help.

This is technically an NMdata issue but for practical purposes that doesn't matter because it prevents you from running NMexec() on the former of those two control streams. We see the error from "NMtransInp()" which is being used by NMscanInput() which NMexec() uses to copy the data set to a new location in which it will go on an run Nonmem. Two things have happened prior to where the error occurs, and the issue is likely in one of those steps. The steps are

  1. Extracting the path to the input data set
  2. Reading the input data set

I suspect step 1). I know the current CRAN NMdata version (0.1.6) does not support data files without file name extensions. So a path like my/datafile could be causing this while my/datafile.csv or whatever file name extension should work. That is one thing to check.
For a more complete check of the first step, it would be informative for me to see:
1a) $INPUT and $DATA in the control stream.
1b) Results from NMdata::NMextractData("C:/nm74g64/run/test/CONTROL6.ctl")

For step 2, you can try to run NMreadCsv() on the path to the input data set. Just check that you get a reasonably looking data.frame. No need to check any details.

Best,
Philip

@nskoch
Copy link
Author

nskoch commented Aug 12, 2024 via email

@philipdelff
Copy link
Collaborator

OK, great. The next version of NMdata should resolve this. I am hoping to get NMdata 0.1.7 to CRAN within 2-3 weeks.

Best,
Philip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@philipdelff @nskoch