Age | Commit message (Collapse) | Author | Files | Lines |
|
I got crashes under some circumstances when using symbols stored in the
mkinmod object. One such circumstance was the use of a moved DLL in
combination with parallel computing on a cluster. As I cannot exactly
define at the moment when this happens, it is better to make this
an opt in.
|
|
|
|
|
|
with the custom lsoda call, avoiding repeated getNativeSymbolInfo calls.
It's just that we should not be calling foreign functions from different
packages, because the may change without notice. Using
getNativeSymbolInfo for "call_lsoda" avoids the CRAN note, and a similar
call could probably be used for "unlock_solver", avoiding the NOTE in
checks for cran, but we should not do this in a CRAN package.
|
|
The hope was to be more successful in saemix fits, but I did not notice
an improvement (e.g. for a failing likelihood calculation with importance
sampling, where the error message suggested to increase maxsteps).
|
|
Thanks to Tomas Kalibera for his analysis of the problem on the
r-package-devel mailing list and for the suggestion on how to
fix it. See the current benchmark vignette for the new data
on mkin 1.1.1 with R 4.2.1, with unprecedented performance.
|
|
I threw out mclapply as it did not play well with the linear algebra
routines used in the saemix code. Most of the change is actually
indentation in the code creating the model function. But there
is an important fix in mkinpredict which I had broken.
|
|
|
|
Depends on inline >= 0.16.2 (including the bug fixes from
eddelbuettel/inline#18), which provides 'moveDLL' to store the DLL for a
compiled function in a safe place in case the argument 'dll_dir' is
specified in the call to 'mkinmod'.
Huge thanks to Dirk @eddelbuettel for his review and support
for the work on the inline package.
|
|
With automatic reloading in mkinfit and mkinpredict in case the
DLL is not loaded and the original DLL path has been cleaned up.
Depends on jranke/inline@974bdea04fcedfafaab231e6f359c88270b56cb9
See inline#13
|
|
The reasons for this decision were
- Creating an saemix generic in the saemix package caused problems with
roxygen, because functions like saemix.plot.xy were documented in
their help files as S3 methods, although explicitly exported with
@export
- Creating an saemix generic in this package is possible, but would
make it necessary to load samix with exclude = "saemix" in order to
avoid overwriting the generic when loading saemix.
- The return object of such an saemix generic in this package cannot
be an S3 class with class attribute c("saemix.mmkin", "SaemixObject")
similar to nlme.mmkin, as saemix returns an S4 class.
- Extending the S4 class SaemixObject using simple inheritance to
a class SaemixMmkinObject with additional slots did not work
as expected. When the initialize method was left untouched, it
prevented creation of an SaemixMmkinObject even if it was based
on an initialised SaemixObject, as the initialize method seems
to always be called by new(). This could potentially be circumvented
by a coerce method. If an alternative initialize method was
used, an SaemixMmkinObject could be created. However, the methods
written for SaemixObjects only worked in some instances, either
because they checked for the class, and not for class inheritance
(like compare.saemix), or because the initialize method was called
for some reason. Therefore, the idea of creating a derived S4 class
was abandoned.
- A side effect of this decision is that the introduction of the saem
generic opens the possibility to use the same generic also for other
backends like nlmixr with the SAEM algorithm.
|
|
Also, exclude the saemix function when loading saemix in the example
code, to prevent overriding our generic
|
|
|
|
|
|
also for deSolve and eigenvalue based solutions. This noticeably increases
performance for these methods, see test.log and benchmark vignette.
|
|
This increases performance up to a factor of five!
|
|
|
|
Still in preparation for analytical solutions of coupled models
|
|
Preparing for symbolic solutions for more than one compound
|
|
|
|
|
|
|
|
|
|
Also ignore test.R in the top level directory, as it is not meant to
be public
|
|
As it is unclear if and when ccSolve will be published on CRAN,
the generation, compilation and use of the C version of the
system of differential equations was developed for mkin, inspired and
guided by the code from the ccSolve package. Many thanks again to
Karline Soetaert for all of her work on this and other R packages.
Now all model types, including the Hockey-Stick model for the parent
compund and the IORE model for parent and/or metabolites can be compiled.
|
|
|
|
|
|
Tests all pass (Linux)
|
|
If the ccSolve package is available, and time is not in the right hand
side of the equations (i.e. if only SFO and SFORB models are used),
the differential equation model is compiled from auto-generated C code.
Currently, one test (FOCUS 2006 D SFO_SFO) fails
|
|
|
|
|
|
- Change the format of the workspace files of gmkin so they can be
distributed in the mkin package
- Add gmkin workspace datasets FOCUS_2006_gmkin and FOCUS_2006_Z_gmkin
- Restrict the unit test with the Schaefer data to parent and primary
metabolites as formation fraction and DT50 for A2 are higly correlated
and passing the test is platform dependent. For example, the test
fails in 1 out of 14 platforms on CRAN as of today
- Add Eurofins Regulatory AG copyright notices
- Import FME and deSolve instead of depending on them to have cleaner
startup
|
|
|
|
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@133 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|
|
predictions for complex models
- Improve default values for atol and set rtol default to 1e-10
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@49 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|
|
- Fixed the output format of mkinpredict to be uniform across solution types
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@33 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|
|
- Used these data in unit tests for parent only models
- Fixed SFORB data and calculation of formation fractions along the way
- Reintroduced the test for the Schaefer 2007 data
- Got rid of the mkinmod unit tests - they are too hard to maintain and the mkinfit
tests test the model definitions as well
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@32 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|
|
- Now the eigenvalue based solutions are nicely consistent with the deSolve solutions, if enough
output times are specified (100, sometimes more are needed, see test.R)
- Workaround for invilr not to produce NaN values so often
- Still a lot to do (see TODO)
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@30 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|
|
- The SFORB models with metabolites is broken (see TODO)
- Moved the vignette to the location recommended since R 2.14
- Added the missing documentation
- Commented out the schaefer_complex_case test, as this version of
mkin is not able to fit a model without sink and therefore
mkin estimated parameters are quite different
git-svn-id: svn+ssh://svn.r-forge.r-project.org/svnroot/kinfit/pkg/mkin@22 edb9625f-4e0d-4859-8d74-9fd3b1da38cb
|