Pharsight®
Phoenix® 1.4
Phoenix® WinNonlin™ 6.4
Release Notes
August 2014
For complete information regarding Phoenix WinNonlin, see also the
Release Notes for:

Phoenix® Framework

Phoenix® Data Tools and Plots
Phoenix® WinNonlin™ 6.4 Release Notes
Contents
Contents
Certara® Contact Information ..............................................................................................3
What’s New .........................................................................................................................4
Bioequivalence/LinMix .................................................................................................. 4
Issues Corrected ...................................................................................................................6
Bioequivalence................................................................................................................ 6
LinMix ............................................................................................................................ 6
Migration ........................................................................................................................ 7
NCA ................................................................................................................................ 8
WNL Classic Modeling .................................................................................................. 9
Known Issues .....................................................................................................................11
Bioequivalence.............................................................................................................. 11
Licensing ....................................................................................................................... 12
LinMix .......................................................................................................................... 13
NCA .............................................................................................................................. 14
NPS ............................................................................................................................... 17
WinNonlin Classic Modeling ....................................................................................... 17
WinNonlin® 5.x to Phoenix® Transition ............................................................................21
Data – Append .............................................................................................................. 21
Data – Data Wizard Column Properties ....................................................................... 21
Data – Data Wizard Column Transformation ............................................................... 21
Data – Data Wizard Filter ............................................................................................. 22
Data – Pivot .................................................................................................................. 23
Data – Stacker ............................................................................................................... 23
Framework – Charting .................................................................................................. 23
Framework – Data ........................................................................................................ 24
Framework – File I/O ................................................................................................... 24
Framework – File I/O - Legacy WinNonlin ................................................................. 24
Framework – Grids ....................................................................................................... 25
Framework – Printing ................................................................................................... 25
Framework – User Interface ......................................................................................... 25
IVIVC ........................................................................................................................... 25
IVIVC – Convolution ................................................................................................... 27
IVIVC – IVIVC Workflow ........................................................................................... 27
IVIVC – Levy Plot ........................................................................................................ 27
IVIVC – WN-LR .......................................................................................................... 27
Migration ...................................................................................................................... 27
NLME – Engines .......................................................................................................... 29
PKS – Study .................................................................................................................. 29
Tools – Bioequivalence ................................................................................................ 30
Tools – BQL ................................................................................................................. 30
Tools – Crossover ......................................................................................................... 30
Revision 0
Page 2 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Certara® Contact Information
Tools – Deconvolution.................................................................................................. 30
Tools – Descriptive Stats .............................................................................................. 31
Tools – LinMix ............................................................................................................. 32
Tools – NCA ................................................................................................................. 32
Tools – NONMEM ....................................................................................................... 34
Tools – Nonparametric Superposition .......................................................................... 34
Tools – WinNonlin Classic Modeling .......................................................................... 35
Certara® Contact Information
Technical support
Consult the product documentation to address questions. If further assistance is
needed, contact Certara technical support through e-mail, our web site, phone, fax, or
mail.
E-mail:
[email protected] (fastest response time)
Web:
http://www.certara.com/support
Phone:
1-919-852-4620
Fax:
1-919-859-6871
Mail:
Pharsight Corporation
5520 Dillard Dr., Suite 260
Cary, North Carolina 27518
For the most efficient service, e-mail a complete description of the problem, including
copies of the input data, and a copy of the project file or template file.
Customer feedback
Submit requests for product enhancements and defect corrections through e-mail, fax,
or through Certara’s customer support web site:
E-mail:
[email protected]
Web:
http://www.certara.com/support
Fax:
1-919-859-6871
User Forum
Get tips and discuss Pharsight products with other users at
www.pharsight.com/extranet.
Revision 0
Page 3 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
What’s New
What’s New
Bioequivalence/LinMix
Westlake confidence intervals have been removed from the Average
Bioequivalence output worksheet and the Core Output (QC 157): The Westlake
confidence intervals have become obsolete in the Bioequivalence industry and have
been removed from the Average Bioequivalence output worksheet and the Core
Output. (Note: The Anderson-Hauck test is planned to be removed in the next
version; please contact Support with any concerns.)
Tests for equal variances for parallel designs and for 2x2 crossover have been
added (QC 3343): For the default parallel and 2x2 crossover models, some tests in
Bioequivalence, such as the two one-sided t-tests, rely on the assumption that the
observations for the group receiving the test formulation and the group receiving the
reference formulation come from distributions that have equal variances, in order for
the test statistics to follow a t-distribution. Two tests have been added to
Bioequivalence that verify whether the assumption of equal variances is valid. The
Levene test is done for a parallel design that uses the default model (formulation
variable with intercept included). The Pitman-Morgan test is done for a 2-period, 2sequence, 2-formulation crossover design that uses either Variance Components or all
fixed-effects model. (For replicated crossover designs, the default model in
Bioequivalence already adjusts for unequal variances by using Satterthwaite Degrees
of Freedom and by grouping on the formulation in the repeated model.)
The results of the Levene test and Pitman-Morgan test are given in the Average
Bioequivalence output worksheet and at the end of the Core Status output. Both tests
verify the null hypothesis that the true variances for the two formulations are equal, by
using the sample data to compute an F-distributed test statistic. A p-value of less than
0.05 indicates a rejection of the null hypothesis (and acceptance that the variances are
unequal) at the 5% level of significance. Information has been added to the Phoenix
WinNonlin User’s Guide to show how to adjust the model if unequal variances are
indicated by the tests.
In additive models, Bioequivalence now includes confidence intervals in terms of
differences, not just as percent of the reference (QC 8087): For the no-transform
case, Bioequivalence will now give the confidence intervals as both percentages and
the actual (non-transformed) values, on the Average Bioequivalence output worksheet
and in the Core Output.
For fixed effects models, an “old-fashioned ANOVA table” is now provided in
LinMix/Bioequivalence output, that includes SS and MS terms (QC 9181): The
Revision 0
Page 4 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
What’s New
LinMix/Bioequivalence objects now create additional Partial SS and Sequential SS
output worksheets with SS and MS terms for models with all fixed effects.
A newer method for evaluating power (Power of Two One-Sided t-Tests) has
been added (QC 9383): The Power of the Two One-Sided t-Tests procedure is now
computed for Average Bioequivalence. It is estimated using a non-central t
distribution. (The Power in previous versions of Phoenix is the power of the 80/20
Rule and has been renamed to make this distinction.)
The t-values associated with the Two One-Sided t-Tests are now reported (QC
10540): t-values have been added to the workbook output and text output. They
appear in the Average Bioequivalence output worksheet and are called t1_TOST and
t2_TOST. The t-values also appear in the “Two One-Sided T-tests” section of the text
output as t1 and t2.
The error term for the F-tests in LinMix/Bioequivalence in fixed effects models
can now be specified (QC 11573): New Test Numerator and Test Denominator
fields are available in the user interface to specify an additional test of hypothesis in
the case of a model with only fixed effects. In this case, the default error term
(denominator) is the residual error, so an alternate test can be requested by entering the
fixed effects model terms to use for the numerator and denominator of the F-test.
The intrasubject and intersubject CVs for 2x2 crossover default model are now
included with log 10-transformed data (QC 12474, 12637): Previously,
intersubject and intrasubject CV were given only for the 2x2 crossover default model
with ln-transformed data. Now, the CVs are also included for this model with log 10transformed data.
The default model for non-replicated crossover can now be all fixed effects, as in
the EU guidance (QC 12530): New functionality is available to use a preferences
setting, under Edit > Preferences, to set the default Bioequivalence model to
Subject(Sequence)+Formulation+Period, with no random effects, in the case of nonreplicated crossover study.
The Power column has been renamed to Power_80_20 to indicate it is for the
80/20 rule (QC 12535): The Power column on the Average Bioequivalence output
workbook has been renamed to clarify what type of power it is and to avoid confusion
with a new type of power that has been added, power of the two one-sided t-tests. The
text output has also been changed to indicate that the power is for the 80/20 rule.
However, power for the 80/20 rule may be removed in future versions; please contact
Support with any concerns about this.
Revision 0
Page 5 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Issues Corrected
Issues Corrected
Bioequivalence
Bioequivalence now supports input with large number of columns and/or long
column names (QC 4477/CRM 40768): Previously, an error could occur for data
with very many columns or long column names. Bioequivalence can now handle
wider data.
Results no longer become out-of-date when the “General Options” tab is selected
and no changes have been made (QC 10776).
EMA states to round CI’s to two decimal places before testing whether the value
is between 80.00 and 125.00 (QC 11515): Since regulatory agencies differ in their
rules for rounding, the statement about whether average bioequivalence is shown or
not shown has been removed from the text output. The user should use and interpret
the bioequivalence results in conjunction with applicable regulatory guidelines.
Loss of accuracy in CI's, when using the options for Already ln-transformed or
Already log10-transformed, was due to testing error (QC 11781): This defect was
mistakenly reported in the Phoenix 1.3 Release Notes as a Known Issue, due to an
error during testing. This defect did not actually occur in Phoenix 1.3.
Power calculation now uses a more accurate t-inverse routine (QC 12173): A
slightly more accurate t-inverse routine is now used to improve the accuracy of
Power_80_20. The improvement occurs about the fourth or fifth decimal place.
SS and MS are now included in the output only under appropriate circumstances
(QC 12608, 13275): If a user had replicated data but changed the Bioequivalence
model to the default non-replicated crossover model, SS and MS output were
incorrectly generated. This also occurred if a Repeated model was added to the
default non-replicated crossover model.
A warning is now issued when the Residual DF option fails due to 0 DF and
Satterthwaite is used (QC 13100): If the selected DF method is Residual, but the
Residual DF is computed to be 0, then the Residual DF method cannot be used and the
method will be automatically changed to Satterthwaite. A warning is now given
when this occurs and it is recorded in the Core Output and in the Warnings and Errors
output.
LinMix
LinMix now supports input with large number of columns and/or long column
names (QC 4477/CRM 40768): Previously, an error could occur for data with very
many columns or long column names. LinMix can now handle wider data.
Revision 0
Page 6 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Issues Corrected
In Linear Mixed Effects (and Bioequivalence), results no longer become out-ofdate if the “Least Squares Means” tab or “General Options” tab is selected and
no changes have been made (QC 10776).
Running AutoRegressive type on random effects no longer generates an error
(QC 13251): If a nonlinear variance structure (FA0, AR, ARH, or CSH) is used for a
random effect, and a linear variance structure (VC, CS, UN, TOEP, or Identity (no
specification)) is used for the repeated effect, LinMix execution now continues
without error.
LinMix object no longer hangs when a variance is estimated to be negative (QC
13494): An issue was identified in LinMix (Linear Mixed Effects Modeling) where
the LinMix object would run indefinitely. It occurred when a variance was estimated
to be negative, which indicated that the selected model was a very poor fit to the data
in any case. This issue has been fixed so that the hang does not occur and a warning
message is given about the negative variance component.
Migration
Initial estimates no longer become corrupted when loading PMO, WSP, and
legacy WNL scenarios with profiles (QC 12543): When loading legacy files with
extension .PMO or .WSP (containing .PMO files) as well as legacy PKS scenarios
containing PK/PD models, the initial parameter estimates within the WinNonlin
Classical PK/PD models could become corrupt if entire profiles were excluded. This
defect affected both PKS and non-PKS users and has been corrected.
Tau values are now loaded from PKS scenarios containing Steady-State NCA
models that were created with WinNonlin and contain Tau information (QC
12544, 12552): This defect only affected PKS users.
Dosing data and units are now successfully loaded from PKS scenarios, created
with WinNonlin 5.x or earlier, where the source of the data is not the PKS study
data (QC 12545, 12575): This defect only affected PKS users.
PKS scenarios created before WinNonlin 5.0 now load model sort keys (QC
12557): WinNonlin 5.0 started storing the model sort information in scenarios
whereas, prior to that time, it relied on the sort key information stored with the
workbook settings. Migration only looks for the scenario information. This defect
only affected PKS users with scenarios created prior WinNonlin 5.0.
WinNonlin 5.x IVIVC scenarios do not recreate the IVIVC object in Phoenix
(QC 12580): Although all the output from the IVIVC run from WinNonlin 5.x is
loaded, the IVIVC object is not re-created. This defect is applicable to only PKS users
because .ivc files loaded locally display the IVIVC workflow (referred to as the
IVIVIC Wizard in WinNonlin).
Revision 0
Page 7 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Issues Corrected
Urine/Volume are no longer switched when loading NCA urine scenario from
PKS (QC 12583): When a legacy WNL 5.x PKS scenario with an NCA urine model
was loaded in Phoenix 1.3, the Concentration and Volume column mappings were
switched, i.e, the Concentration was mapped to Volume and vice versa. In addition,
the incorrect mappings caused the column units to be invalid for the type of column,
so the units appeared with curly brackets to indicate invalid units
PKS scenarios containing PK model 9 that use a dosing worksheet where
duration is specified, now map the duration of infusion when loaded into Phoenix
(QC 12601): Loading a .pmo file or a PKS scenario containing a PK model 9, where
the duration was specified in WinNonlin using a dosing worksheet, now maps the
EndTime_Cal column.
NCA
Conversions of mole to gram and gram to mole are now possible in the internal
dosing worksheet (QC 10808).
Column order in Final Parameters Pivoted now matches the order of parameters
in Final Parameters (QC 10826): The order of parameters between the Final
Parameters and Final Parameters Pivoted worksheets will now always match, with the
exception that blank columns on the Final Parameters Pivoted worksheet will still be
removed.
Sparse Sampling models now handle numeric Time and ID values that are in a
column declared to have data type Text (QC 12016/CRM 136999).
Clicking Slopes Selector when a Sort column contains a single quote (’) no longer
throws an unhandled error (QC 12022/CRM 137036).
Preferred units are now carried over in NCA model from WinNonlin 5.x
scenarios (QC 12029): When loading a WinNonlin 5.x scenario from PKS, the NCA
object now imports the previously selected preferred units. This defect only affected
PKS users.
Slopes settings and other profile dependent settings are now loaded correctly in
Phoenix WinNonlin 6.4 from NCA objects that contain WinNonlin 5.x exclusions
of full profiles in PKS scenarios and .PMO files (QC 12030): This defect affected
both PKS and non-PKS users.
Exporting as .xpt no longer requires shortening variable names for parameters
not being exported (QC 12174/CRM 138184): Only the columns included in the
export are checked for validity before enabling the OK button.
NCA urine models no longer have missing time values in the Summary table due
to rounding in midpoint calculations (QC 12467): A midpoint in the Summary
Revision 0
Page 8 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Issues Corrected
table that matches to 14 significant digits with the original input data is now treated as
the same data point as the input data point.
Sort variables in a Merge Worksheets object, where the column names in the
Observation and Dosing worksheets have different cases, are now mapped (QC
12610): When loading a .pmo file or PKS scenario containing a steady state NCA
model, where dosing was specified using a dosing worksheet, are now mapped
correctly even when the variable names in the Observation and Dosing worksheets
have different names, including different cases.
Steady state calculations can now be performed when the dose amount is 0 (QC
13523/CRM 143620): A dose of 0 was causing the Tau values to not be read as input,
which then caused the steady-state analysis to not be performed.
NCA no longer fails if it is unable to delete the temp folder it created during
execution (QC 13761): In some unreproducible cases, temporary files created during
an NCA execution were not able to be deleted. This has been fixed so that NCA will
not be left in a state where it cannot be re-executed.
Re-executing an NCA object after using the Slopes option on legacy WinNonlin
data with Exclusions no longer throws an unhandled error (QC 13980).
WNL Classic Modeling
Profile dependent settings (e.g., dosing, initial estimates) are now loaded correctly
in Phoenix WinNonlin 6.4 from WNL Classic Modeling objects that contain
WinNonlin 5.x exclusions of full profiles in PKS scenarios and .PMO files (QC
12030): This defect affected both PKS and non-PKS users.
In WNL Classic Modeling, selecting the Engine Settings tab (with no changes) no
longer causes the results to become out-of-date (QC 12046).
Stripping dose can now be entered for WNL5 Classic PKPD models (QC
12063/CRM 137337): The stripping dose can now be entered for these models in
new projects. However, when loading pre-existing projects from Phoenix 1.3 or
earlier, it will be necessary to toggle to a different model number and then back to get
the Stripping Dose setup to appear.
PKS scenarios created in WinNonlin 5.x that have an NCA object, but do not
have Therapeutic Response defined, now import successfully (QC 12377): This
defect only affected PKS users.
Numeric values stored as text in WinNonlin no longer cause incorrect profile
dependent settings to load in Legacy WinNonlin models (QC 12510): This defect
only affected non-PKS users, as one cannot store numbers as text via WinNonlin in
Revision 0
Page 9 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Issues Corrected
PKS. This defect has been corrected, with the exception of the following rare
situation, which might still cause problems:
Phoenix does not support the case where some numbers are stored as text and
some are stored as numbers within the same column. Therefore, mixed
representations within a column will not be handled properly. For example, Text
1 and numeric 1 will be two profiles in WinNonlin but one in Phoenix. If the
loaded model in Phoenix appears to have different sorting than expected, the user
should review the settings as they might not have loaded properly.
Model source is now correctly mapped when it is not the first worksheet in the
workbook and a preceding worksheet contains exclusions (QC 12514): This
defect only affected non-PKS users and has been corrected.
Original version of WinNonlin source file is now added to the Documents folder
to facilitate understanding of how the data were migrated (QC 12621): Users can
now compare the migration output with the original file, which has red highlighted
exclusions, to gain a clearer understanding of how the data were processed.
Changing the mapped Concentration/Y variable after execution no longer causes
the output graphs to not display the observed value (QC 12718/CRM 140711,
143518): If an existing project has missing plots, remapping the Concentration/Y
variable and re-executing will fix the plot.
WNL ASCII models are now correctly saved for a specific sequence of mapping
the ASCII model from a file in the Code folder to an internal text object, saving,
and reloading (QC 13437): Importing an ASCII model in the Code folder, saving,
mapping to an internal text object in Classic Modeling, saving, closing, and reloading
in that specific sequence would result in the ASCII text not displaying in Classic
Modeling. In Phoenix 1.4, the object is saved properly and the text is retained when
the project is re-opened.
Importing a PWO dataset, PKS study, or scenario now also places an Excel file
containing a copy of the dataset into the Documents folder (QC 13968): The
annotations for “Missing” and excluded data persist in the Excel file, which provides a
clear picture of what the dataset, study, or scenario looked like without opening it in
WNL 5.x or PKS, respectively.
Renaming or moving a PWO file that is associated with a PMO file no longer
causes the dosing data to become corrupted (QC 13979).
Revision 0
Page 10 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
Known Issues
Bioequivalence
Unmapping weight variable as Regressor does not remove it as weight variable
(QC 5032): After mapping a Regressor in the Bioequivalence object and using it as a
Weight Variable, remapping it to None does not remove the variable as the Weight
Variable. To remove the Weight Variable, drag it back to the Regressor box.
With multiple bioequivalence objects in the workflow, an error in one object’s
Fixed Effects model causes all other objects’ FE models to be invalidated (QC
6152): In a workflow with multiple Bioequivalence objects, an error in one object’s
Fixed Effects model, which causes the model to be invalidated, will cause all other
Bioequivalence objects’ Fixed Effects models to be invalidated. The same issue
occurs for Variance Structure models.
Bioequivalence object - output data not updated with new formulation (QC
7723): After a bioequivalence object has been executed, if the Treatment column is
changed and the object re-executed, the results will still show the name of the original
treatment column.
Table using Bioequivalence output as source is not updated correctly when the
Bioequivalence object is re-executed (QC 7724): When re-executing a
Bioequivalence object, new instances of the Ratio output worksheets are created,
rather than simply updating the existing instances. If another object, such as a table, is
linked to the original worksheets, after re-execution of the Bioequivalence object, the
downstream object will need to be re-linked to the new result worksheets.
In a Bioequivalence Object, the model specification is reset to default if an
additional dependent variable is mapped (QC 9541): In a Bioequivalence Object,
the model specification is reset to default if an additional dependent variable is
mapped.
In a Bioequivalence Object, copy/paste, move-to-new-workflow, using a template,
and map source will reset the model in Bioequivalence to the default model (QC
9641): In a Bioequivalence Object, copy/paste, move-to-new-workflow, using a
template, and map source will reset the model in Bioequivalence to the default model.
NCA, WNL Classic, Bioequivalence, and LinMix Core Status output exported as
RTF does not have formatting like WNL ASCII output did (QC 10357): When
Core Status output is exported as an RTF file, the file when opened defaults to Sans
Serif, a non-uniform font size. To align the columns in the output, and make the
output the same as the WNL 5 defaults, change the font to Courier New 9 pt.
Revision 0
Page 11 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
Changing Reference Formulation should mark output as out-of-date (QC 11035):
Changing the reference formulation for Bioequivalence should mark the object as outof-date (red), but this does not happen in the current version.
Execution error encountered if there are apostrophes in the mapped Sort column
(QC 12051): Apostrophes cannot be used in data columns that will be used as Sort
variables in LinMix or Bioequivalence.
Bioequivalence is not marked out-of-date when changing any of the options on
the Options tab (QC 12137): If any of the following options are changed, the
Bioequivalence object is not marked out-of-date: Confidence Level, Percent of
Reference to Detect, Anderson-Hauck Lower Limit, Anderson-Hauck Upper Limit.
Population/Individual Bioequivalence incorrectly fails to execute due to less than
two sequences with incomplete design (QC 12788/CRM 140939): If this message
is erroneously displayed, “Fewer than two sequences had complete design. Program
terminating,” an attempted workaround is to first use the Sort tool on the data, to sort
in this order: Sequence, then Subject, then Period.
Changing a column name after setting up Bioequivalence leaves the object in a
state where it cannot be re-executed (QC 13010): If the name of a classification
variable is changed, the prior column name still appears in the Classification Variables
field and cannot be removed, and this causes the execution to fail. The workaround is
to finalize the column names before sending data to the Bioequivalence or LinMix
objects.
Bioequivalence and LinMix objects with default replicated model is marked outof-date by just clicking on the Variance tab (QC 13471): LinMix and
Bioequivalence objects become out of date when the Variance Structure tab is selected
and the model being used is the default replicated model.
Bioequivalence quits early due to over-specified model, but SAS runs to
completion without any errors or warnings (QC 14000/CRM 146145): When the
Bioequivalence object generates an error message about the model being overspecified, it will end, whereas some tests could still be computed. The workaround is
generally to try another variance structure, so that the model is not over-specified.
Licensing
If using the WinNonlin license found during installation, an asterisk appears
after WinNonlin in the product name (QC 7341): If Phoenix is using an older
WinNonlin license; an asterisk will appear after the product name on both the splash
screen and the application’s title bar.
Revision 0
Page 12 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
LinMix
Linear Mixed Effects has unhandled error when using very long string values
(QC 4880/CRM 138864, WNL QC 2478): If long strings are used as input data in
LinMix, for example, more than 25 characters in a name, an unhandled error will
occur in the LinMix core, and no output will be generated. However, the Phoenix
framework will remain stable and work can be continued. The workaround is to
substitute shorter names.
In Linear Mixed Effects, only the first row of title is imported with .lml (QC
6187): In LinMix and Bioequivalence, when importing a legacy WinNonlin LML
file, only the first row of the title will be imported.
In Linear Mixed Effects, .lml files load some .pwo files as Workbook instead of
retaining name (QC 6260): When importing a legacy Linear Mixed Effects file
(*.lml) that references a Pharsight WinNonlin Workbook Object data file (*.pwo), the
name of the Workbook can be set to the generic name Workbook as seen in the
Phoenix Object Browser.
Initial Variance Parameters button does not generate initial values for some
Random Types (QC 6503): Depending on the data, model and variance type selected
(for example, Auto-regressive, Compound Symmetry, etc.), Phoenix might not be able
to create the Initial Variance Parameters when clicking the Generate button on the
Options tab of Setup. Attempting to execute the workflow can present additional
information regarding the problem as noted in the Text Output file “Warnings and
Errors.”
After changes in the Fixed Effects model, warning that LSM is not set displays
although LSM has been set (QC 6679): When using the Linear Mixed Effects
operational object and setting one or more model terms to calculate Least Squares
Means; subsequent changes to the Fixed Effects model can disable the Settings frame
for the Least Squares Means. To re-enable the Settings frame, drag a model term from
the Least Squares Means list box to the Fixed Effects Model Classifiable Terms list
box and then back again.
In Linear Mixed Effects, the Initial Variance parameters are not enabled when
loading certain LML files (QC 6837): Depending on the Fixed Effects model and
selected Random Effects, the ability to generate initial variance parameters on the
General Options tab of the Linear Mixed Effects operational object might not be
available. If the source of the workflow is from a legacy WinNonlin LinMix file
(*.lml), a workaround is to use WinNonlin to create an *.lml file that already has the
random effects information included. Importing this updated file will allow Phoenix
to generate initial variance parameters as expected.
Linear Mixed Effects has unhandled error when a sort variable has Missing data
(QC 7611): If a sort variable has missing data, an unhandled error will occur in the
Revision 0
Page 13 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
LinMix core, and no output will be generated. However, the Phoenix framework will
remain stable and work can be continued. The workaround is to substitute a value for
the blank cells, such as the string Missing.
Regressor box is grayed out for Random model in Phoenix but not in WNL 5.x
(QC 7842): A regressor cannot be used as a random effect in LinMix or
Bioequivalence. This was allowed in WNL 5.x.
Changing “Fixed Effects Confidence level” should make output out of date (QC
11036): Changing the Fixed Effects Confidence level for LinMix should mark the
object as out-of-date (red), but this does not happen in the current version.
First save after running Linear Mixed Effects results in out-of-date output (QC
11725): In a new project that has not been saved, if a LinMix object has been run and
results are up-to-date, saving will flag them as out-of-date. This only happens on the
first save. The workaround is to re-execute the LinMix object and save again, or save
prior to executing LinMix since subsequent saves will work not flag LinMix as out-ofdate.
LinMix quits early due to over-specified model, but SAS runs to completion
without any errors or warnings (QC 14000): When the Linear Mixed Effects object
generates an error message about the model being over-specified, it will end, whereas
some tests could still be computed. The workaround is generally to try another
variance structure, so that the model is not over-specified.
NCA
No units are carried through the NCA calculations when all concentrations are 0
(QC 4718/CRM 49088, WNL QC 2042): When running non-compartmental
analyses for a profile where all concentrations for a subject are 0, a warning message
is displayed that units might be wrong, Cmax is set to 0 (which is correct), and all
other parameters are reported as missing (which is also correct). All results (whether 0
or missing) are contained in the non-transposed final parameters sheet, but all units are
missing.
NCA Plots tab shows two identical entries for enabling or disabling the plot
Observed Y and Predicted Y vs X (QC 7753): On the Plots tab of the NCA object,
there are two identical entries for selecting whether or not to create the Observed Y
and Predicted Y vs X plot. The second entry has no function and can be ignored.
Check or deselect the first plot in the list to configure whether or not that plot gets
generated.
Exclusions in NCA Slopes typed as 1,2,3,4 become the number 1234 and might
not exclude the desired data (QC 8047): When running an NCA model, if
exclusions are typed as several numbers separated by a comma (e.g., 60,90), when the
model is executed, the exclusions output will show both 60 and 90 were excluded but
Revision 0
Page 14 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
the Core Status output and summary table will not show 90 as having been excluded.
Users should avoid using commas to separate exclusions, instead semicolons should
be used or the selections should be made visually from the plots (which automatically
separate exclusions with semicolons). Note that importing legacy files will separate
exclusions using semicolons and this problem will be avoided. In addition, 1,2,3,4 in
a text column becomes the number 1234 if the column is converted to numeric.
NCA results: one or more graphs have a mismatched lattice page condition (QC
9702/CRM 145998): In rare cases, NCA result plots fail to render with the error
message, “one or more graphs have a mismatched lattice page condition.” The exact
conditions that cause this issue are not known, but it only seems to happen in models
with carry along columns mapped. The problem can be worked around by unmapping
any carry along columns, executing NCA, remapping carry along columns, and reexecuting.
In NCA PD model 220, carry-alongs cause the Slope column to be blank. It
normally contains “Slope1” and “Slope2” (QC 10008): Certain carry-alongs can
cause duplicate column names in the output, which causes the Slope column to be
blank for model 220. The workaround is to remove carry-alongs until the Slope
column is filled.
NCA only shows three and a half lines of title in the plot, whereas WinNonlin 5.x
showed 5 lines (QC 10213): The title for an NCA plot is cut off after three and a half
lines.
Slopes Selector for NCA objects does not refresh correctly (QC 10407): The
Slopes Selector tab under Setup does not refresh correctly. It can show as a blank
screen, a small chart, or a chart from a previous setting. Clicking on another tab under
Setup, such as Dosing, and then back to Slopes Selector will fix the problem.
Incorrect NCA calculations Tmax, Cmax, AUC, on Japanese OS when loading
older projects (QC 10610): When loading Phoenix 1.0 or 1.1 projects with NaN in
the results, re-execution of the source executables is required to get the new results.
NCA Plasma model with RNT as carry-along creates duplicated rows of negative
time points in the NCA Summary output (QC 10616): Duplicate time points per
profile where only one of the duplicates has a valid time value will result in duplicate
rows in the summary table matching the duplicate rows on the input.
Loaded 6.0 NCA projects, or 6.1 NCA projects first created with 6.0, fail to
generate plots upon execution (QC 10728): The error message “One or more graphs
have a mismatched error condition” can occur. The workaround is to use the Reset
Existing Plots button on the Plots tab and re-execute.
Revision 0
Page 15 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
Sparse Sampling, Urine: Incorrect header in “Individual by Time” worksheet,
says Conc but presents rates (QC 10933): The Individuals by Time worksheet
should have the column header Rate instead of Time.
Mismatched curly braces in output unit for NCA urine model with preferred
units specified (QC 11469): For Urine models, if the input unit is not a valid unit, the
results may have a Vol_UR with unmatched {} brackets. This does not affect the
results other than the units produced for Vol_UR.
Clicking F7 to execute an NCA object, Phoenix closed down completely without
warning (QC 11805/CRM 136264): On very rare occasions, we have received
reports that executing a project may cause a shutdown of Phoenix without warning.
The reasons for this are presently unclear but users are advised that saving of a project
at regular intervals is a good working practice. If you do encounter this, please supply
logs and the contents of the scratch repository to support to allow further investigation.
NCA Slopes Selector issue with time data that has more than 14 significant digits
– point appears selected for time range but is not used (QC 12034): Computer
accuracy is limited to about 14 significant digits. This can cause two unique numbers
with more than 14 significant digits to be treated as the same number in the Slopes
Select, e.g., 240.333333333333 and 240.333333333334. Furthermore, the point
representing a number, such as 240.333333333333, is selectable in the Slopes Selector
and can show as the End Time for a user-specified range, but still not be used in the
slope calculation.
One workaround is to paste the numbers from the Data into the Slopes grid. Another
possibility is, prior to NCA, to round the time data so it has 14 significant digits or
fewer (use a custom transformation in the Data Wizard with a formula such as
round(time,10)) or roundsig(time,14)).
Dosing Used output does not match the Settings in the Core Output in a case
where Dose = 0 (QC 12184): Currently there is no known workaround for this issue.
For user-specified time range in NCA, Lambda_Z_Lower and Lambda_Z_Upper
in the output are off by 1e-14 (QC 13582): This is similar to defect 12034 – see the
workarounds given for 12034 above.
NCA Slope setting is not imported for profiles if one or more sort keys are
null/missing/excluded (QC 14019): If a an NCA model created in WinNonlin 5.x
has null, excluded or missing values for profile identifiers, the associated slope
information will not be imported. The internal sources in WinNonlin 6.x do not
support null profile identifiers, which the imported source data is converted to.
Unhandled error when selecting Slopes for profiles with null sort keys, also null
sort keys missing from other Setup grids (QC 14020): Errors can occur if variables
that contain null/blank values are used as sort variables in an NCA object. It is
Revision 0
Page 16 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
recommended that only non-missing variables that uniquely identify profiles are used
as sorts and others be used as carry-along variables. The problems occur when one or
more sort variables are used, and the data contains all blank values for one or more
levels of the sort variables. In other words, the sort variables define a set of unique
combinations of the values of the sort variables, and if the data values are all blank for
one or more of those unique combinations, even if this is the case for only one of the
sort variables, then the problems will occur. Clicking on points on the Slopes Selector
plots for the sort levels with all blanks will cause an unhandled error, and the project
should then be closed and reopened. Furthermore, the slopes cannot be specified
through the Slopes grid because the sort levels with all blanks will be missing from the
Slopes grid. The sort levels with all blanks will also be missing if internal worksheets
are used for the Dosing, Partial Areas, and Therapeutic Response grids, so those
settings also cannot be specified for the sort levels with all blanks via internal
worksheets.
The workaround for the defect is to use a transformation to set the blanks to a
character. For example, the user can use the Data Wizard to add a Transformation,
select the type Custom, and enter the formula, if(isNUll(x), ".", x). Map x to
the sort column with blanks and execute. This will change the blanks to a period
without changing other data values. The result of the Data Wizard can then be sent to
NCA.
These problems with Slopes Selector and Slopes grid also occur in the IVIVC tools,
Loo-Riegelman, and Wagner-Nelson. WNL Classic Modeling and Phoenix Modeling
do not have any issues with specifying settings for sort levels with all blanks.
NPS
NPS and NCA Best-Fit lambdaZ calculations differ (QC 14394): In a case where
input data was given to significant precision (eight significant digits or more), the Best
Fit algorithms in NCA and in NPS (Nonparametric Superposition) were not generating
exactly the same lambdaZ values, although the results were very similar.
WinNonlin Classic Modeling
User model fails to run for case where columns have unequal number of rows
(QC 4332, WNL QC 533): WinNonlin ASCII model will fail to run for case where
columns have unequal number of rows from PK to PD data.
ASCII model does not allow selection of the model number as it did in WinNonlin
5.3. ASCII model LIB files will only allow access to the first model found in the
text file (QC 5478): Phoenix allows a user to import ASCII models from .LIB files
into the Code sections of Phoenix projects. Note however that if such a .LIB file has
more than one model specified as was the case in the ASCII models supplied with
Revision 0
Page 17 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
WinNonlin (PK1.LIB, PK2.LIB, etc.), using such a Code file in Phoenix will only
allow access to the first model found in the file.
To work around the problem, it is suggested to split the ASCII models into .LIB files
that include only a single model each and import those files for subsequent modeling
in Phoenix. Note that this only affects workflows whereby the LIB file is imported by
itself into Phoenix; when the LIB file is referenced as part of an imported CMD or
PMO file, the proper model is loaded.
Inconsistent behavior is possible when using external worksheets for PK
modeling operational object (QC 7122): When using a PK operational object,
external worksheets for stripping dose, units and initial estimates can be accessed in
different ways. The differences will occur if there is more than 1 row of information
on these external worksheets that correspond to one or more individual profiles of data
of the Main input worksheet.
In such cases, the stripping dose for PK models will be determined as the first value
found on that external worksheet whereas the units and initial parameters will be based
on the last row found on those external worksheets (for any given profile). To avoid
any confusion stemming from these differences it is suggested that external
worksheets maintain a one-to-one row-based correspondence to the Main input
profiles whenever possible.
Parameters in results worksheets from PK Modeling can appear with the name
of MISSING (QC 7145/CRM 135508): When using the WinNonlin 5.x Classic
Modeling PK operational object with a very large number of doses, the names of
primary and secondary parameters can appear as the string MISSING rather than the
actual name. Decreasing the number of administered doses is the only known
workaround when this problem is experienced.
Executing a PK Model object can lock up the system (QC 7148): In extremely rare
instances, the nonlinear modeling core computational engine can get into an infinite
loop during the minimization process. This infinite looping will cause Phoenix to
hang and the application must be shutdown using Task Manager. The problem
typically occurs when the parameter space in which the program is working within is
very flat.
To work around the problem, it is first suggested that the user change the minimization
algorithm found on the Engine Settings tab to Nelder-Mead and retry the problem. If
this fails to correct the problem, varying the initial estimates and/or using bounds on
the parameters can allow processing to complete as expected.
Change E0 parameter name to Imax in models 103 and 107 (QC 7407): In PD
models 103 and 107, the E0 parameter (effect at 0) is equivalent to Imax, the
maximum inhibition due to drug.
Revision 0
Page 18 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
No warning if no stripping dose is provided in simulation (QC 7550): Phoenix
incorrectly requires a stripping dose in order to perform simulation in the PK Model
object. If the dose is not specified, the model will fail to fit.
ASCII models with parameter Keo will not load properly (QC 8530):
Workaround is to rename the parameter in the ASCII model to ke0 or some other
value, and then it will not be impacted by the import. The import changes Keo to Ke0
to handle legacy models.
ASCII model constants in model conflict with Constants parameters (QC 8669):
PK models using a legacy ASCII model where the number of constants (NCON) and
the constants (CONS) are defined within the model code should not have the Constant
setup grid mapped to a source or an internal worksheet filled.
Predicted sheet column for X is called TIME when mapped variable is not TIME
(QC 8680): When running a PK Model, and the source data contains a Time column,
the plot results will use this column for the Predicted data, regardless of whether or not
that column was selected as the time variable for the model.
For instance, if the source data contains both a Time and a Relative_Nominal_Time
column, and you use Relative_Nominal_Time when setting up the model, the plots
will show the Observed results along the correct scale, but will incorrectly use the
Time column for the Predicted results. To work around this problem, use a Filter
object to exclude the Time column before mapping the data to the PK Model object.
For WNL Classic Modeling objects, the tab key skips some controls and the tab
order is incorrect (QC 8911): Some tab operations do not proceed in expected order
of navigation.
Initial Estimates grid for Dissolution models does not accept new initial values
after changing Fixed/Estimated (QC 9741): For the WinNonlin Generated Initial
Parameter Values option with Dissolution models, to avoid getting pop-up warnings
that “WinNonlin will determine initial estimate” when using the Initial Estimates
internal worksheet setup, the user should delete the initial values before changing the
dropdown from Fixed to Estimated, and should change the dropdown from Estimated
to Fixed before entering the initial estimate.
Once the dropdown is changed from Fixed to Estimated, the user will not be able to
delete the initial value entered. However, it will not be used, and WinNonlin will
estimate the initial value as requested.
Performance issue with ASCII model: messages show hundreds of rows of
constants that do not show in the project (QC 9869): There is an infrequent
problem with ASCII models where, during execution or save, the performance is slow
due to hundreds of rows of constants (CONS) being scanned, even though they do not
Revision 0
Page 19 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
Known Issues
appear in the project. This also causes the size of the saved project to be very large.
This defect does not affect the results.
Dissolution models do not allow for setting preferred units (QC 10065):
Dissolution models do not support preferred units.
For NCA and Classic Modeling, users must tab off of Units entry field for entry
to take effect (QC 10314): For NCA and Classic Modeling, users must tab off of
Units entry field for entry to take effect.
Phoenix version and build number missing in the Core Output for WNL Classic
Modeling (QC 11886): The Phoenix version and build number, e.g., 6.4.0.768, are
missing from the top of the WNL Classic Modeling Core Output. However, the Core
Version date is given.
Execution error encountered for WNL Classic Models having apostrophe values
in the mapped Sort column (QC 12062): Apostrophes cannot be used in data
columns that will be used as Sort variables in WNL Classic Modeling.
WNL Classic Modeling output plot of observed and predicted data is missing the
observed data (QC 13947): The WNL Classic Modeling object in pre-existing
projects may sometimes load in Phoenix 1.4 with the observed data missing from the
“Observed Y and Predicted Y vs X” plot. If this occurs, unmap any data that is
mapped in the Setup (i.e., map to None), remap the data, and re-execute the object.
This should correct the issue.
History worksheet needs more detail when Missing and Excluded values are
deleted from PWO datasets (QC 13969): When importing a legacy WinNonlin
PWO into Phoenix, excluded values are removed from the worksheet. If an entire row
has been excluded, it will be placed in an excluded rows worksheet. A history of
exclusions/missing values performed in the original PWO worksheet is appended to
the History of the imported Workbook, as it was in the WinNonlin version that created
the workbook. In addition, an Excel copy of the imported PWO file is placed in the
Documents folder, grouped under xls.
Error loading legacy scenario with PK model 13 (QC 14028): Phoenix WinNonlin
6.x cannot load a WinNonlin 5.x scenario that was created with a PK Model 13
mapped to non-PKS study data, where the user entered the dosing information via the
WinNonlin 5.x dosing dialog. An “unable to load model” message will be displayed.
Some Legacy WNL scenarios are out-of-date after loading into Phoenix (QC
14050): If a WinNonlin 5.x scenario, workspace or model has missing values in the
sources for analysis object, these missing values are cleared out of the source at the
very last step of importing into Phoenix. Consequently, these analysis objects will
load as out-of-date and will require execution to bring them up to date.
Revision 0
Page 20 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
“Missing” values are imported from legacy WNL scenarios, but are deleted when
workflow is re-executed (QC 14051): Related to QC 14050, where missing values
are removed from source worksheets in final step of importing WinNonlin 5.x
scenarios. As part of the loading of WinNonlin 5.x scenarios, analysis object are
executed. Since an execution is not done after clearing missing values from sources,
some out of data analysis objects will have the missing value text until re-execution.
WinNonlin® 5.x to Phoenix® Transition
The following section provides information for the WinNonlin user transitioning to
Phoenix. The items below identify differences that exist between WinNonlin 5.x and
Phoenix WinNonlin.
Data – Append
Append does not perform like SQL UNION (QC 7328): The new data object
Append Worksheet pulls data sets together that do not have row associations, that is,
different studies. It requires, at a minimum, two data set sources and can append as
many as 100. It appends based on similar column headers name and column units.
Data – Data Wizard Column Properties
Data Wizard Column Properties - users can rename columns without filter for
special characters (QC 3195, 4966, 6477): The data object Column Properties no
longer accepts special characters when columns are renamed. The only characters
allowed are letters (az), numbers (0-9), and the underscore symbol (_). Molecular
weight can now be used in the Column Properties data object. The Column Properties
data object can be used to specify or reset the sort order for worksheets.
Data – Data Wizard Column Transformation
The Data Wizard Column Transformation object can handle multiple
transformations in one object (QC 3090, 3176): The data object Column
Transformation combines and replaces the capabilities of Tools>Transform and Add
Equation and Transform within the Multi-Transform dialog in WinNonlin 5.2.x. The
Column Transformation object has a custom type of transformation that corresponds
to the same functions as the Multi-Transform dialog’s Add Equation option.
Additionally, the following functions have been added:

The capability to reorder columns.

Two additional pre-defined arithmetic formulas: (x-y)/y and (x-y)/y*100
Revision 0
Page 21 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition

The capability to specify a fix point as the baseline time for baseline
transformations. In previous versions this fix point was always time 0.

The capability to select a minimum per group starting time point for baseline
transformations.

Baseline transformations no longer require a numeric time and also now accept
date and time formats as the starting time point. However, the transformations
continue to require that the time column has information in every cell. When
using date and time formats the user has the option to output the numeric time
column used for this calculation in the Transformed Time Column. This can aid
in the calculation of relative times for pharmacokinetic analyses when the time
of dose is recorded and is the first chronological time entry within the
combination of sorts. The date and time formats accepted are listed in the
Phoenix User’s Guide.

Custom transforms, or equations, no longer use cell position to perform
transformations. Instead, any variable typed within an equation can be mapped,
or associated with an existing column header. If a different data set with the
same column names is then selected as the input, Phoenix automaps the
columns. Otherwise, if the column names are different the user can map them
manually. This allows for generalized transformations that can be used across
different data sets.

Custom transforms have a new isnull operator to detect cells that are blank. For
example, the function if (isnull(conc), 0, conc), where conc is mapped
to a concentration column, returns 0 for blank concentration cells or the
concentration value if the cell is not blank.

Ability to add new columns adjacent to the x column used in all non-custom
transformations.
Data – Data Wizard Filter
Enable column filtering to obtain intersections for data exclusion or inclusion for Built
In and Custom filters (QC 3110): The Filter Worksheet object combines and replaces
the capabilities of Data > Exclude and Data > Include for both Selection and Criteria
as well as Edit > Replace in previous WinNonlin versions. In addition, it adds the
capability to write custom filters with more than one condition and to exclude columns
from the resulting data set.
There are three filtering options:

Built in replaces Data > Exclude > Criteria, Data > Include > Criteria and
Edit>Replace.

Selection (exclude) replaces Data>Exclude>Selection. However, it works
slightly different as exclusions are no longer highlighted red but they are
Revision 0
Page 22 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
removed from the resulting worksheet. A separate worksheet of exclusions is
provided.

Custom (include) is a filtering option that allows the use of custom filters. For
example a filter with more than one condition (for example, NOT time = 0 and
NOT Conc = 0; this would exclude any row that is not 0 time and not
concentration 0)
There is no replacement for Data > Include > Selection because one can simply
delete the excluded selection or use custom filters with the same result.
Several rules (with either filtering options) are allowed within one filtering object.
These rules can be edited, deleted, and reordered. The output from a filtering object
consists of three worksheets: the resulting worksheet, a worksheet of row exclusions,
and a worksheet of cell exclusions.
Data – Pivot
Pivot Worksheet object transposes worksheet values (QC 6030/CRM 63727): The
Pivot Worksheet object transposes values stored in columns into rows, which means it
can take long and skinny data sets and flatten them out. For example, data sets that
have a column to identify analyte but only a single concentration column can be
pivoted to have concentration columns for each analyte. The Pivot Worksheet object
has the inverse functionality of the Stacker object, and handles units differently.
Data – Stacker
Stacker object allows users to “stack” data in a worksheet column (QC 7579):
The Stacker object reduces the number of columns in a data set by creating a single
value column and adding columns to identify the type of variable and, if applicable,
the units. The Stacker object can take a flatten data set and make it long and skinny.
For example, if a data set of variable estimates has a column for each variable, such as
NCA final parameters pivoted, it can be stacked and used as input for initial estimates.
The Stacker object has the inverse functionality of the Pivot Worksheet object, and
handles units differently.
Framework – Charting
Not all tick label formatting options available in WinNonlin 5.2.1 are available in
Phoenix (QC 2150): The format of tick mark labels on plots in Phoenix cannot be
conditioned on the tick value. Font typeface, size, color, and numerical format may
still be specified and will be applied to all tick mark labels on the selected plot axis.
Histogram –WinNonlin 5.x can group in a histogram; Phoenix cannot (QC 3753):
In previous versions of WinNonlin, it was possible to group data in the same
Revision 0
Page 23 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
histogram plot, such as a series grouped by subject. Phoenix no longer has this ability,
instead creating different histogram plots for each subject.
Framework – Data
Default number of output decimal places is different than WinNonlin 5.x (QC
3477): Default levels of precision found in Phoenix output can differ from those seen
in WinNonlin 5. WinNonlin 5 used fixed formats for output, and Phoenix defaults to
G8 format.
Grids do not have a specific Missing format and legacy WinNonlin missing cells
are imported as blank (QC 5612): Phoenix WinNonlin grids no longer have a
specific Missing format and it imports legacy WinNonlin missing cells as blank.
WinNonlin is now capable of excluding any character or blank data from the
appropriate operational objects. For example, a column with a mix of numbers and
characters is assigned a data type of text, but if used in plotting/modeling numeric
values are used.
Framework – File I/O
Formulas are not retained in import of .pwo, only the value is imported (QC
2242): Formulas are not retained in import of .pwo, only the value is imported. Note:
This Release Note entry was included in the Known Issues section of the Phoenix 1.1
Release Notes, but this is not an issue that will be fixed; this is as designed for
Phoenix WinNonlin and will remain different from WinNonlin 5.x.
Users can export Excel files that are imported as a binary documents as Excel
files (QC 6832): If an Excel file is imported into the Documents folder in the Object
Browser, then the file can be exported as a regular Excel file. Previously, the Excel
file could not be exported.
Framework – File I/O - Legacy WinNonlin
Loading legacy WinNonlin files or workspaces that include very large data sets
can take longer in Phoenix (QC 7737): By default, WinNonlin stores its data sets in
PWO files that are based on a 3rd party ActiveX (OCX) grid control developed for use
with older Visual Basic programs. Phoenix must provide a “layer” into the legacy
OCX control to import these older files, so the data extraction phase of reading legacy
PWO files can take a significantly longer time in Phoenix when compared to
WinNonlin. Once the data is imported into Phoenix and saved as a Phoenix project
file, the workspace loads at normal speeds.
When a WinNonlin 5.x workspace is loaded into Phoenix, descriptive stats
mappings do not match and parameter names are changed (QC 7745, 8369): Due
to changes in parameter names from WinNonlin 5.x to Phoenix 6.x, some mappings
Revision 0
Page 24 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
involving the changed parameter names do not persist when they are migrated to
WinNonlin 6.x and must be mapped manually in Phoenix. Examples of this are
workspaces containing descriptive statistics or PD models.
Framework – Grids
Excel-style drag applies formula to other cells (QC 375): Grids in Phoenix cannot
accept user-entered formulas. Instead, users can right-click a worksheet in the Object
Browser and select to edit the worksheet in Excel. To save the work done in Excel,
close Excel and save the worksheet. Select Yes when Phoenix asks if you wish to
apply changes. A second prompt asks users if they wish to save the Excel formulas.
See the User’s Guide for differences with Office 2007.
If you select yes every time that you edit in Excel from Phoenix, the formulas are
saved, but no edits can be performed in Phoenix. The worksheet is read-only if it is
edited in Excel.
If you select not to save the Excel formulas, then only the values are transferred to the
worksheet in Phoenix and it is editable. Note that to apply changes performed in
Excel, the user cannot change the default name of the Excel sheet.
Framework – Printing
Print All works differently in Phoenix (QC 5569): The Print All feature includes
the object name and date in worksheet headers. Worksheet footers default to the page
number. Users can edit these defaults by selecting Page Setup in the File menu,
which allows users to edit fields in worksheet headers and footers. The fields can be
used in place of text:
&P
&O
&D
&T
-
Page number
Object name
Date
Time
If a table has no data, a blank page with a header and footer is printed.
Framework – User Interface
Hot keys in Phoenix are different than those in WinNonlin 5.2.1 (QC 6908): Hot
keys within Phoenix have different assignments or are not present in the same dialog
boxes as they were in WinNonlin 5.2.1.
IVIVC
Numerical differences in IVIVC between WinNonlin 5.3 and Phoenix (QC
10525): There will be some cases where the numerical output from Phoenix 1.3 will
Revision 0
Page 25 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
differ from the output in WinNonlin 5.3. The causes and conditions are outlined
below.
1. Interpolation bug in WinNonlin 5.3:
The interpolation algorithm in WinNonlin will place a zero concentration at the
first time point. If the In Vivo data does not contain a concentration at time 0,
then the Predicted Validation and Predicted Target Calculation will be
incorrect. This can be seen in the Summary table of the Val PK NCA out
workbook. The profile will have a concentration of 0 inserted at time 0, and
one at the first observed time point. This can occur even if concentrations of 0
exist at time zero when validating against the means using GeoMean, as the
Descriptive Statistics tool will return NULL if all values are 0. Below is a
sample snapshot of the differences in NCA output from two identical projects:
WNL Predicted:
PHX Predicted
These differences will affect the outcomes on Validation Errors. Depending on
the data, it may or may not be significant.
2. Prediction Workflow Fix:
WinNonlin always uses the individual subjects to calculate the Predicted
Parameters in the Prediction Tab, regardless of the In Vivo Data Options.
Phoenix uses the validation selection on the In Vivo Data Options. If Generate
mean profiles (validate against individuals’ profiles) is selected, WinNonlin
will perform the prediction using the individual subjects, whereas Phoenix will
use the mean for each profile, just like the validation tab/step.
3. Deconvolution:
The Deconvolution output precision has increased. This has been demonstrated
to affect the results, but not always. Validation against WinNonlin in this case
would involve using the new VPDeconv.exe executable from Phoenix with
WinNonlin. This will resolve output differences in this case.
4. TCutOff:
Revision 0
Page 26 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
A Correlation Model with one function and Tcutoff had errors with times in
predicted output in WinNonlin. It resulted in the times no longer increasing.
This has been fixed in Phoenix. This would affect the case where only one
internal formulation was selected. Depending on the situation, the output may
be different, but not always.
IVIVC – Convolution
Error with time-varying carry-alongs in Convolution (QC 2598): Carry-alongs in
convolution now use logic similar to PK and NCA for carry-alongs. If the carry-along
value is not the same across a profile it is NOT included in the convolution output.
This is different from WinNonlin 5.2 that just used the first value of the carry-along
for the entire profile.
IVIVC – IVIVC Workflow
Target formulation does not consistently appear in Validation Errors and
sometimes appears with missing name (QC 9818): Target Formulation is located in
Phoenix on the Prediction Tab and not in the Validation Errors table as was seen in
WinNonlin 5.3.
IVIVC – Levy Plot
Levy: difference from WinNonlin 5.3, need to have {0} in the UI field to have
formulations appear in legend (QC 9695): In WinNonlin 5.3 the legend label
textbox displayed as %Abs vs %Diss {0} for Levy Plots. Newly created Levy Plots
will display %Abs vs %Diss {Form}. This will not update older projects.
IVIVC – WN-LR
Exclude Cmax/Tmax from lambdaZ range in Wagner-Nelson and LooRiegelman -IVIVC (QC 7613): In Wagner-Nelson and Loo-Riegelman, as with
NCA and Nonparametric Superposition, the Cmax point will now be excluded from
the best-fit Lambda-Z computation, due to a general agreement of the PK community.
This is a change from WinNonlin 5.3 and previous versions. If the user wishes to
include the Cmax point, they can still do so by using a user-supplied Lambda-Z range.
Migration
In example file SparseSamplingChaioYeh.pmo, Tau is mapped but Steady State
is not selected when the file is imported into Phoenix (QC 7509): Phoenix creates
a dosing sheet from the data in the PMO file which contains the dosing interval (tau).
Because the PMO does not contain a flag for steady state, tau is missing in both the
original PMO file and in the NCA object. If the Lambda Z range is selected in
Phoenix, the results are identical to the results in WinNonlin 5.x.
Revision 0
Page 27 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
Error loading workspace file (.wsp) when dosing is not on first worksheet (QC
10329): Several issues have been fixed when loading workspace and PKS Scenarios
into Phoenix. There are still some situations where the migration of workspaces or
PKS scenarios might not import as expected. These situations are:

If a multi-transform contains a filter>Include statement, the meaning of include
in Phoenix will not be the same as WinNonlin 5.x and although it will load that
operation will not be doing what it did in WinNonlin 5.x. In WinNonlin one
would need to exclude to then include something previously excluded. In
Phoenix include is the opposite to exclude and only that inclusion happens.

If a transform operation is done on blank cells it might display different results.
We believe they are more accurate in Phoenix but the user should be aware of
this. In WinNonlin a missing cell divided by 0 resulted in a 0, in Phoenix it
results in a blank.

In WinNonlin if one uses the REMOVE within MT but does NOT check Row
matching criteria the tool still removes the full row matching that criteria, in
Phoenix (correctly) only the cell affected will be removed. Recommendation to
WinNonlin users to always check row matching criteria in MT if that is what is
desired.

Graphics that are not automatically generated by an object are not loaded as part
of the workflow but the WinNonlin 5.x image is imported.

Problems might also be encountered if a column was assigned a name before it
had any values created. When this type of multi-transform worksheet in a
workspace is imported in Phoenix the first rule does nothing because that
column does not exist. If the first rule is moved to the third then it works
correctly.
Phoenix fails to load base scenarios created outside of WinNonlin (QC 11959): If
a scenario is created outside of WinNonlin, and flagged as a WinNonlin scenario, it
will not load. It will not have the study snap shot that WinNonlin saves, which is used
to identify columns used in the scenario study workbook. A workaround is to load the
scenario into WinNonlin and save it, then load the saved scenario in Phoenix.
NCA Slope Settings: Slope # is not imported correctly from PMO files (QC
14310): In NCA 220 models, there are 2 slope calculations, which are identified as
Slope 1 and Slope 2. When legacy WinNonlin files are imported and the Lambda Z
Calculation Method is set to Best Fit, the slope settings for Slope 1 will be imported
twice and slope settings for Slope 2 will not be imported. As a result, the regression
method for Slope 2 will default to Linear. To correct this issue, the user can manually
edit the Slope settings and replace the duplicate values for Slope 1 with Slope 2 and
specify the desired regression method to be used.
Revision 0
Page 28 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
NLME – Engines
Variance inflation factors (VIFs) are all reported as zero for simulation with very
basic model and data (QC 8184): To obtain simulation VIFs using a Phoenix Model
requires a different set up than doing simulations using WinNonlin Classical Models.
To obtain VIFs from simulations using a Phoenix Model, one needs to map a
concentration column such as Y.
PKS – Study
Multiple worksheet studies are created differently in Phoenix than they were in
WinNonlin 5.x (QC 3788): A multiple worksheet study can be created by merging
worksheets using Phoenix’s Merge Worksheets object or by using the Append/Update
feature in the PKS plug-in for Phoenix. This is different from the Create Study option
in WinNonlin 5.x, and allows a greater degree of control over study creation.
Create study option in Phoenix is different than what was used in WinNonlin
(QC 4760, WNL QC 2235): The Phoenix Create Study mapping interface differs
from WinNonlin 5.x in that attributes for Dose are not displayed in the same way, and
Treatment Code is now known as Treatment.
Study Creation in Phoenix does not allow creation of Study, excluding missing
Time data as WinNonlin 5.x did (QC 6562): Phoenix performs a validation of any
data used to create a Study. This validation does not allow a Study to be created that
includes excluded time data. In WinNonlin 5.x, during Study creation the user could
ignore this data, but Phoenix does not allow this to occur.
When clicking on the Load Properties button during study creation, a study
should default to an XML type (QC 7233): A new file type, .map, has been
instituted for Study Properties in Phoenix. The prior XML file format is obsolete and
cannot be used in Phoenix because it does not contain the applicable data. As the new
format contains different data, the user is not able to save Phoenix properties as an
XML file.
User should not be required to create Study View to use study data in Phoenix
WinNonlin (QC 7756): The Phoenix/PKS workflow has been altered to add
additional granularity and refinement. To this end, Scenarios are based on Study
Views which are customizable views on the Study data present in PKS. These Study
Views can be combined, allowing the user to include and exclude data to be used as
the base for the Scenario. This workflow is extremely powerful and eminently
repeatable as these views are static so that other users can precisely replicate the
activities of their colleagues.
Revision 0
Page 29 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
Tools – Bioequivalence
Confidence level (options) for Pop/Ind defaults to 95 in WinNonlin but to 90 in
Phoenix (QC 4994): The confidence level for Population/Individual Bioequivalence
defaulted to 95 in prior versions of WinNonlin but defaults to 90 in Phoenix.
Bioequivalence and Linear Mixed Effects objects in Phoenix produce different
output than in WinNonlin (QC 7415, 7416, 7474): Bioequivalence tests that use the
banded unstructured random type produces different Final Variance Parameter values.
Also, bioequivalence tests using the compound symmetry random type produces
different results. If a bioequivalence test case with modified random effects and
banded variance structure produces different results.
In Phoenix, the data is sent to the LinMix and Bioequivalence engines in the same
order as it is given in the input dataset. WinNonlin 5.x preprocessed data by sorting,
and did not unsort the data before sending to these engines. For very unstable
problems such as nonconvergent models or models that produce severe errors, the
results in Phoenix can be different than in WinNonlin 5.x.
Tools – BQL
Users cannot apply multiple rule sets at the same time in Phoenix, and BQL
substitutions do not generate verification errors when formulas contain strings
other than LLOQ (QC 6548, 6780): The new data object replaces the capabilities of
Tools > Status Codes (i.e., BQL) in previous WinNonlin versions. Any variable
mapped as a Status Code or LLOQ column are now printed in the output by default.
Users can also select to print the original concentration column in the output. The
BQL object can only accept one rule per object, but BQL objects can be copied to add
multiple rules.
Phoenix cannot import or export BQL RUL files (QC 6799): BQL rules are now
saved as PHXRULESET files instead of RUL files. RUL files cannot be imported or
exported in Phoenix, but BQL files can be.
Tools – Crossover
Crossover with blank cells producing different behavior in WinNonlin and
Phoenix (QC 7490): When executing a Crossover study in Phoenix that contains
blank data cells, users will not encounter an error as with previous versions of
WinNonlin. Phoenix will complete the operation and display certain items of output.
Tools – Deconvolution
Phoenix results have more precision than WinNonlin results, which only carry
five decimal places (QC 2355): The output from the Deconvolution object is uses
Revision 0
Page 30 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
more decimal places than WinNonlin. This results in slightly different numbers in the
results.
Difference from WNL5.x -does not have exponential terms in output (QC 7672):
Deconvolution output does not include the exponential terms that were used, as
previous versions of WinNonlin did. The values will be saved with the project, or can
be saved using Dependencies.
Tools – Descriptive Stats
In Descriptive Stats and Tables, there are additional options for confidence
intervals based on the number of standard deviations (QC 826): Some additional
statistics can now be computed when using the Descriptive Stats operational object.
In the options tab the option to compute confidence intervals (CIs) and their associated
percentages (X=1 to 99%) now generates additional CIs:

CI X% Lower = the lower confidence interval that contains X% of the data.

CI X% Higher = the upper confidence interval that contains X% of the data.

CI GEO X% Lower = the lower confidence interval that contains X% of the
logs of the data, back-transformed to original scale.

CI GEO X% Upper = the upper confidence interval that contains X% of the logs
of the data, back-transformed to original scale.

CI X% Lower GEO Mean = the lower confidence interval that contains the
geometric mean with X% probability.

CI X% Upper GEO Mean = the upper confidence interval that contains the
geometric mean with X% probability.
An additional option allows users to enter the number of standard deviations (SD) and
the system generates the following:

Lower XSD = lower range determined by subtracting X standard deviations
from the mean.

Upper XSD = upper range determined by adding X standard deviations from the
mean.

GEO Lower XSD = lower range determined by adding or subtracting “x” log
standard deviations from the log-mean, back transformed to original scale.

GEO Upper XSD = lower range determined by adding or subtracting “x” log
standard deviations from the log-mean, back transformed to original scale.
Note that when SD=1, the Lower 1SD and Upper 1SD is also called the 68% Rule.
Revision 0
Page 31 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
The Descriptive Stats object displays header columns with the percent symbol (%) as
indicated above, however, this symbol is not allowed as a header name, so any
successive work done using the output data shows the symbol % as Percentage. For
example, CI 95% Lower is CI95PercentLower in the output. Header names can be
replaced in the Tables object.
Percent sign (%) in Results column is read or converted to “Percent” or the letter
P (QC 2245): If Phoenix processes a CI (Confidence Interval) value outside the valid
range of 1-99 then an error message is displayed. Using valid values does not reveal
this condition.
Tools – LinMix
Numerical differences between WinNonlin LinMix and Phoenix Linear Mixed
Effects (QC 7349): It has been noted that WinNonlin and Phoenix can potentially
generate different numerical results when running the same Linear Mixed Effects
model. The difference is caused by the order in which the rows of the data are
presented to the core modeling engine. A difference in the sort order of the input data
could cause a slight difference in results in either unstable models or large data sets.
Research has shown that WinNonlin can perform pre-sorting on the data that does not
occur in Phoenix in which case Phoenix is deemed the better solution. When such
differences are noted between the two applications, the user should verify that the
cause is based on a different order of input data as viewed on the Residuals output
worksheet
LinMix/Bioeq: WNL 5.x gave a warning for confidence level specified as <= 50.
Phoenix does not have the warning (QC 7845): In any LinMix or Bioequivalence
run, enter a confidence level that is 50 or less. In WNL 5.x, there will be a warning
for any value that is 50 or less, “The application has detected that the value you are
using for the Confidence Interval is very low. Please be aware that conclusions drawn
from the results of this analysis may be unreliable.” This warning was added in case
the user typed 0.95 instead of 95. The warning does not occur in Phoenix. For
LinMix, confidence level is on the Fixed Effects, Estimates, and LSM tabs. For
Bioeq, confidence level is on the Fixed Effects and Bioequivalence Options tabs.
In the Linear Mixed Effects Wizard, Transformation defaults to None in
Phoenix, and defaulted in WinNonlin to Ln(x) (QC 11714): In the Linear Mixed
Effects tool, the Fixed Effects Tab - Dependent Variables Transformation defaults to
None in Phoenix, WinNonlin defaulted to Ln(x).
Tools – NCA
Exclude Cmax/Tmax from Lambda Z range in the NCA object (QC 158, WNL
QC 287): In the NCA and Nonparametric Superposition objects, the Cmax point is
now excluded from the best-fit Lambda Z computation. This is a change from
Revision 0
Page 32 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
WinNonlin 5.x. If a user wants to include the Cmax point, he or she can still do so by
using a user supplied Lambda Z range.
Several NCA options are different in Phoenix (QC 3175, 4595, 4844, 5774, 7288,
7652 and WNL 1531, 2435): Improvements to the NCA module user interface
include an easy way to enter dosing and partial areas not depending on sorts. For
example, if the user wants the same dosing regimen for all profiles or a same partial
area only one entry is needed. In addition, settings for partial areas can now be
imported from a file containing start and stop times, number of partial areas desired
and partial area labels. A user can now create an input worksheet (using data tools or
pre-defined templates) containing the actual times to calculate partial areas. A new
option is to also group partial areas under a column label. If one profile is measured
from 0 to 24.1 and another is measured from 0 to 23.9 both of them can be
summarized under a column like AUC24 for easier post processing.
Several additional changes have been implemented to facilitate NCA selections:

New preview of Lambda Z ranges selected by WinNonlin (Best Fit) prior to
executing the run.

The Best Fit selection automatically excludes Cmax from any regression.

Users can exclude points from lambda_z regression in conjunction with Best Fit
option. For example a user might want to exclude points from Lambda Z
regression independently whether the Best Fit option is selected or not.

Points selected as exclusions are listed in Exclusion results worksheet.
The NCA object in Phoenix can now analyze profiles from different routes of
administration and/or at steady-state or not at steady-state in a single run. In the
dosing information tab, the user indicates the route of administration and the dosing
interval, such as tau, if at steady-state. In other words previous Models 200 to 202 and
Models 210 to 212 have been combined into two NCA models and the steady-state
check is no longer needed.
Only time-independent carry along variables such as demographics are now displayed
with the final parameters worksheets and summary table. Time- dependent carry
along variables, such as nominal times, are only displayed in the summary table at
each corresponding time point.
Renaming NCA parameters remains available but permanent precision formatting is
no longer available as part of the NCA object. In addition, parameter names and
precision cannot be specified by applying the file DefaultNCAParameterNames.map
in the installation folder. Instead Phoenix offers templates, which remember settings
that can be reapplied. PK parameters can be renamed and precision can be specified at
the time of table creation.
Revision 0
Page 33 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
Units of variables selected as Sort are not displayed in the output (QC 12507):
When doing an NCA analysis, if you select a variable as a Sort that has units, those
units are not shown in the results for that sort variable. To work around this issue in a
Phoenix template:
1.
Make a copy of the Sort column (e.g. Dose_Level), naming it slightly
differently (Dose_Level_1), by creating a custom Column Transformation, x =
Dose_Level.
2.
Add units to the new column (Dose_Level_1), by using Column Properties.
3.
Use Dose_Level as the Sort in the NCA run (needed to differentiate data) and
use the new column Dose_Level_1 as a Carryalong to get a column containing the
Sort units in the results.
Tools – NONMEM
Capability of Exporting NONMEM data sets (QC 3719): The option to export a
NONMEM data set is no longer available in Phoenix. Phoenix provides many data
management options that the user can use to build a NONMEM like data set without
having to select a PK model. In addition Phoenix Connect provides other options like
CDISC export.
Tools – Nonparametric Superposition
User interface for Nonparametric superposition should allow users to input dose
associated with data (QC 4450, WNL QC 819): For Nonparametric Superposition
analysis, in WinNonlin 5.2.1 it was assumed that the value entered for Initial Dose was
the value actually administered to the subjects during the trial. Phoenix has added the
ability to specify for each Sort key the actual value of the Administered Dose. If no
value is specified for Administered Dose, the NPS calculation assumes the Loading
Dose is the Administered Dose.
NPS needs change to exclude Cmax/Tmax from lambdaZ range (QC 6364): In
Nonparametric Superposition, as with NCA, the Cmax point will now be excluded
from the Best-Bit Lambda-Z computation, due to a general agreement of the PK
community. This is a change from previous versions of WinNonlin. If the user
wishes to include the Cmax point, they may still do so by using a user-supplied
Lambda-Z range. Note that because of this change, Chapter 6 of the Examples Guide
is written slightly differently than in previous WinNonlin versions, so that it uses a
user-specified range for the second NPS execution and yields different results for the
first subject.
Revision 0
Page 34 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
Tools – WinNonlin Classic Modeling
Reparameterization of Emax models (PD models) to use the parameterization in
textbooks (QC 682, WNL QC 776): Pharmacodynamic library Emax models used in
WinNonlin 5.x classic modeling have been re-parameterized. The parameterization of
Emax pharmacodynamic models now follows the most standard parameterization
where Emax is the maximum response due to drug and if there is a baseline response
(E0) then Emax is the maximum response from E0. Similarly for inhibitory models
the Imax would be the maximum effect (Imax) from baseline. The table below shows
the reparameterization correspondence between previous versions and Phoenix.
Model
(# of parameters affected)
101 (no changes)
102 (1 parameter)
103 (2 parameters)
104 (3 parameters)
105 (no changes)
106 (1 parameter)
107 (2 parameters)
108 (3 parameters)
Phoenix WinNonlin 6.0
Emax
EC50
Emax
EC50
E0
E0
IC50
Imax
IC50
E0
Emax
EC50
Gamma
Emax
EC50
E0
Gamma
E0
IC50
Gamma
Imax
IC50
E0
Gamma
WinNonlin Versions 5.x
or earlier
Emax
EC50
Emax – E0
EC50
E0
Emax
EC50
E0-Emax
EC50
Emax
Emax
EC50
Gamma
Emax – E0
EC50
E0
Gamma
Emax
EC50
Gamma
Emax – E0
EC50
Emax
Gamma
Unit builder does not warn user when units are changed (QC 6213): When using
the Units Builder dialog in Phoenix, if a different unit is entered from the one already
existing, there is no warning about the specification or conversion that takes place
when the user clicks the OK button, as there was in WinNonlin 5.2. As this is a silent
action, it is advised that the user be careful to review their settings in the Units Builder
dialog before clicking OK to ensure the proper changes will be effected.
Possible differences in standard errors, CV%, and confidence interval bounds of
final parameters between Phoenix and WinNonlin (QC 7358): In problems that
Revision 0
Page 35 of 36
August 2014
Phoenix® WinNonlin™ 6.4 Release Notes
WinNonlin® 5.x to Phoenix® Transition
are highly unstable causing very large standard errors, the output for these three sets of
values that provide insight into the ability to estimate the Final Parameters can be
different between the two applications. In such cases it has been found that the Final
Parameter estimates themselves still match as expected between Phoenix and
WinNonlin.
Dissolution -feature to Fix all FINFs is not available (different from WinNonlin
5.x) (QC 8973): For Dissolution models, the feature to Fix all FINFs is not available,
but users can copy/paste blocks of the Fixed/Estimated fields to expedite this process.
Revision 0
Page 36 of 36
August 2014