Four Tools, Two Different Jobs
A pharmacometric workflow may use several software tools, but they do not all perform the same task. NONMEM, Monolix, and nlmixr2 are commonly used to fit population models to observed data and estimate model parameters. mrgsolve is commonly used to simulate outcomes from a specified model and parameter set. Distinguishing estimation from simulation helps determine what information must be supplied, what result to expect, and what a result can support.
The distinction is about a tool’s typical role, not an absolute boundary on what a larger workflow can do. For example, estimated parameter values from an estimation environment can be transferred into a simulation workflow. That transfer requires care: the model, parameter meanings, units, and assumptions must agree. A simulated concentration is not, by itself, evidence that the parameters were estimated from data.
Typical Inputs and Outputs
For population estimation, the inputs usually include a structured data set, a model specification, and settings that determine how the estimation is performed. The data commonly contain subject identifiers, times, doses or other records describing treatment, and measured outcomes such as concentrations. The model describes how those outcomes relate to parameters and allows for between-subject variability and residual unexplained variation where appropriate. The analyst also chooses an estimation method and relevant run settings.
NONMEM, Monolix, and nlmixr2 provide environments for this kind of population-model fitting. They differ in implementation, interfaces, available methods, and workflow conventions; they should not be treated as interchangeable merely because each can estimate population models. Typical outputs include estimated fixed-effect parameters, estimates describing variability, residual error estimates, measures of uncertainty, and fit or diagnostic results. Which outputs are available and how they are reported depend on the model, method, settings, and successful completion of the run.
mrgsolve has a different typical role. A user supplies a model implementation, parameter values, and simulation inputs such as dosing and the times at which results are wanted. The output is a set of simulated trajectories or values, for example predicted concentrations over time for one or more individuals. mrgsolve does not, by itself, turn observed concentration data into population parameter estimates. An estimation workflow and a simulation workflow can be connected, but the source and status of the parameters used in simulation should remain clear.
| Tool | Typical role | Typical inputs | Typical outputs |
|---|---|---|---|
| NONMEM | Population-model estimation | Observed data, model specification, estimation settings | Parameter estimates, uncertainty and fit-related results |
| Monolix | Population-model estimation | Observed data, model and project specifications, estimation settings | Parameter estimates, uncertainty and fit-related results |
| nlmixr2 | Population-model estimation in an R workflow | Observed data, model specification, estimation settings | Parameter estimates, uncertainty and fit-related results |
| mrgsolve | Model-based simulation | Model implementation, parameter values, dosing and simulation inputs | Simulated values or trajectories under the specified inputs |
The table describes typical use, not a guarantee of a particular output. An estimate can be missing or unreliable if a run fails, a parameter is not identifiable from the data, or the fitted model is unsuitable. Likewise, a simulation can be computed correctly but still answer an unhelpful question if the model or inputs do not represent the intended scenario.
Worked Example: Choosing an Estimation Environment
Hypothetical setting. A team has concentration measurements from 24 participants after a single oral dose. Its data file records participant identifiers, sample times in hours, administered doses in milligrams, and measured concentrations in milligrams per litre. The team has specified a population model and wants to estimate its parameters from those observations.
This is an estimation task. The team could use NONMEM, Monolix, or nlmixr2, provided the model, data, and analysis plan are implemented appropriately in the selected environment. The inputs are not just the concentration column: participant identifiers, timing, dose information, units, model specification, and estimation settings all matter.
Suppose a successful hypothetical fit reports clearance of 4.2 L/h and volume of 21 L. These are estimated parameters under the specified model and analysis; they are not raw measurements and are not simulated concentration values. As a simple derived quantity, the ratio of clearance to volume is
The units cancel to inverse hours. The ratio can be used in calculations implied by a suitable model, but computing it does not establish that the model fits well. The team should review run status, uncertainty, and diagnostics before treating the estimates as a useful basis for decisions or for a later simulation.
From Estimated Parameters to a Simulation
A common workflow uses an estimation environment to fit a model and then uses a simulation engine to explore scenarios. The handoff is not automatic proof that both implementations represent the same model. Before using estimated values in simulation, the analyst must confirm that parameter definitions and units match, that the model assumptions remain appropriate, and that the simulation inputs represent the question being asked.
A simple one-compartment intravenous bolus model illustrates what a simulation engine calculates. This example is deliberately limited to a known parameter set; it is not an estimation procedure. Assume an instantaneous dose into one compartment, linear elimination, constant clearance and volume, and no additional doses during the interval considered. If \(A(t)\) is the amount in the compartment and \(k=CL/V\), the model is
The corresponding concentration is \(C(t)=A(t)/V\). Separating variables and integrating gives
This derivation shows why a simulation requires both the model and values for its parameters. Supplying a dose and time alone is not enough to determine a concentration. It also shows the limits of the calculation: it follows from the stated assumptions and does not establish that those assumptions describe a particular observed data set.
Worked Example: Calculating a Concentration for Simulation
Hypothetical inputs. Consider the one-compartment model above with an intravenous bolus dose of 100 mg, volume \(V=20\) L, and clearance \(CL=4\) L/h. Assume no further doses and calculate the model-predicted concentration at 5 hours.
First calculate the elimination rate constant:
Then substitute the dose, volume, rate constant, and time into the concentration equation:
A simulation engine such as mrgsolve can calculate model-predicted values under specified inputs of this kind. The result, approximately 1.839 mg/L at 5 hours, is conditional on the model and the supplied values. It is not a concentration observed in a participant, nor does it show that the parameters are supported by data.
Checking the Handoff and Diagnosing Problems
A practical workflow separates the question of whether estimation succeeded from the question of whether simulation was set up correctly. A completed estimation run is not necessarily a satisfactory fit, and a simulation that returns numbers is not necessarily a valid representation of the intended scenario.
Decide whether the immediate task is to estimate parameters from observed data, simulate outcomes from specified values, or carry out both tasks in sequence.
Confirm that identifiers, doses, times, observations, units, model specification, and estimation settings agree with the intended analysis. Inspect run status rather than assuming that submitted work completed successfully.
Check parameter estimates, uncertainty, and relevant fit diagnostics. Investigate warnings, implausible estimates, or poor diagnostics before using estimates as if they were reliable.
Confirm that the simulation model uses the intended parameter meanings and units. Supply the dosing regimen and times needed to answer the simulation question.
Verify that outputs are finite, occur at the intended times, and are plausible under the supplied assumptions. Label results as simulated and record which model and parameter set generated them.
Unexpected output can point to different failures at different stages. Estimation warnings or implausible estimates may indicate data problems, an unsuitable model, or difficulties in the fitting procedure. Simulation outputs that are missing, non-finite, or inconsistent with the intended dose and time can indicate errors in model implementation, units, parameter transfer, or simulation inputs. A diagnostic value should be interpreted in context: no single successful run message establishes that every scientific assumption is adequate.
When comparing tools, the central question is therefore not simply “Which one is best?” NONMEM, Monolix, and nlmixr2 are alternatives for estimation workflows, with different interfaces and implementations. mrgsolve serves a different typical purpose: calculating model-based simulations. Selection among estimation environments depends on the analysis, methods, implementation needs, and team workflow. Selection of a simulation engine depends on the required simulation task and the model implementation. A comparison of estimates from different environments is meaningful only when the data, model, parameterization, and analysis choices are sufficiently aligned.
Worked Example: Translating an Estimate into a Simulation Input
Hypothetical setting. Suppose an estimation run reports \(CL=4.0\) L/h and \(V=20\) L for a model whose definitions match the one-compartment bolus model above. A team wants to simulate the concentration 5 hours after a 100 mg intravenous bolus with no additional doses.
The team first checks that the estimates use the same units and meanings as the simulation model. Under those conditions,
The calculated value is a prediction conditional on the estimated parameter values, their model, and the simulation assumptions. If the simulation model instead used volume in millilitres while the estimate remained in litres, or represented a different parameter definition, copying the numerical value without conversion could produce a misleading result. The handoff therefore requires a documented check, not just a successful software run.
Common Mistakes and Limitations
- Calling every model run an estimation. A simulation with fixed parameter values does not estimate those values from observations. State whether parameters were fitted or supplied.
- Treating the three estimation environments as identical. Similar goals do not guarantee identical implementations, methods, settings, or outputs. Record the choices made and interpret results accordingly.
- Transferring numbers without checking definitions and units. A parameter value is meaningful only with its definition and units. Confirm both before reusing an estimate in another implementation.
- Equating successful computation with model adequacy. A run can complete and produce results even when the model is scientifically unsuitable or the data do not support precise estimation. Review diagnostics and uncertainty.
- Reporting simulated output as observed evidence. Simulations are conditional calculations under stated inputs and assumptions. They are not additional observed data.
The main limitation of this role-based distinction is that actual projects may connect several tools or use additional software around them. The distinction remains useful: identify where parameter estimation occurs, where simulation occurs, and which data, model version, settings, and parameter values support each result. Keeping those roles explicit makes a workflow easier to review and reproduce.
Check Your Understanding
Answer each question, then compare with the brief solutions.
- A team has observed concentration data and wants population parameter estimates. Which tools among the four are typical choices for the estimation task?
- A model and parameter set are already specified, and the team wants predicted concentrations under a new dosing schedule. What is mrgsolve’s role?
- For the illustrative bolus model, \(CL=6\) L/h and \(V=30\) L. What is \(k\), including its units?
- Why does a completed simulation not establish that its parameter values are supported by observed data?
- Name two checks needed before transferring estimates from an estimation environment into a simulation model.
Solutions. (1) NONMEM, Monolix, and nlmixr2 are typical population-model estimation environments. (2) mrgsolve calculates simulated outcomes from the specified model, parameters, and dosing inputs; it is not estimating the parameters from those observations. (3) \(k=CL/V=(6\ \mathrm{L/h})/(30\ \mathrm{L})=0.200\ \mathrm{h}^{-1}\). (4) Simulation calculates outcomes conditional on supplied inputs; it does not infer parameter support from data. (5) Check that parameter definitions and units match, and verify that the model assumptions and dosing inputs represent the intended simulation.