Closed kylebaron closed 7 years ago
Really cool option! I am trying to run through all the scenarios in my head where this can be useful -
Where else can this be really useful other than keeping the R object call within the model specification?
Have this working now:
code <- '
$ENV
mat <- cmat(1,0.8,2)
$OMEGA object="mat"
$SIGMA object="mat"
'
mod <- mcode("ENV2", code, quiet=TRUE)
revar(mod)
## $omega
## $...
## [,1] [,2]
## 1: 1.000000 1.131371
## 2: 1.131371 2.000000
##
##
## $sigma
## $...
## [,1] [,2]
## 1: 1.000000 1.131371
## 2: 1.131371 2.000000
exists("mat")
## [1] FALSE
@vjd Yes ... we've been doing some PBPK modeling with mrgsolve
lately and some huge OMEGA matrices with off diagonals etc .... it's really doesn't work well with the NONMEM-like specification. But would be easy if you could just run a couple of lines of R
.
This works ...
code <- '
$ENV
foo <- list(Y = 5, Z = 1)
yes <- TRUE
conv.factor <- 2.2
$PARAM >> object="foo"
$PARAM >> annotated=yes
Cl : 1.2*conv.factor : Clearance
Vc : 200/conv.factor : Volume
'
mod <- mcode("ENV3", code, quiet=TRUE)
param(mod)
##
## Model parameters (N=4):
## name value . name value
## Cl 2.64 | Y 5
## Vc 90.9 | Z 1
exists("conv.factor")
## [1] FALSE
Just an aside:
Keep in mind this only operates when the model is being parsed. It just helps you write more complicated but structured model code.
For a minute, I was also thinking of implementing something like this:
$PARAM CL = 1, VC = 2, KE = CL/VC
It's kind-of along the same lines and sometimes people ask for this. We could do it, but deciding not to. It gives the illusion that KE
is inherently some function of CL
and VC
. But it's not. Maybe when the model is parsed, it is. But if you ever change CL
or VC
, KE
stays the same. The way to do it is:
$PARAM CL = 1, VC = 2
$MAIN double KE = CL/VC;
The values in $PARAM
are always just fixed numbers. Anything that is a function of parameters needs be derived in $MAIN
.
R
code in$ENV
$ENV
are available down the line when parsing code blocksmrgsim
days. As models get larger and more complicated, I think this might come in handy.For example:
I'd like to expand this:
$OMEGA
and$SIGMA
fundamentally generate a matrix;$PARAM
(and others) generate a listobject
argument to each of these blocks; that would just name an object in$ENV
and use that as the basicR
object from the block. This would make it much easier to specify, for example, a really largeOMEGA
matrix with much less typing and freeing the user from the constraints of$OMEGA
.R
code lives in the model specification; we can always pull from the global environment for these objects, but the next time the model is parsed, who knows if those objects will be around.So far
$PARAM
has$ENV
lookup andobject
argument$INIT
has$ENV
lookup andobject
argument$FIXED
has$ENV
lookup$THETA
has$ENV
lookup$CMT
hasobject
argument$OMEGA
has$ENV
lookup andobject
argument$SIGMA
has$ENV
lookup andobject
argument$NMXML
has$ENV
lookup