aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-08Try to figure out while vdiffr failsJohannes Ranke1-4/+4
2020-12-08mixed.mmkin and test coverageJohannes Ranke24-88/+10487
2020-12-07Updates after inline 0.3.17 has been releasedJohannes Ranke2-2/+2
2020-12-07Possibility to use saemix transformations in some casesJohannes Ranke1-45/+127
Namely for SFO, DFOP, SFO-SFO and DFOP-SFO
2020-12-07Attempt to be more failsafe in saemix runsJohannes Ranke1-2/+8
2020-12-03Small doc improvementJohannes Ranke1-2/+2
2020-12-02Possibility to specify random effects structuresJohannes Ranke4-40/+33
The default is pdDiag again, as we often have a small number of datasets in degradation kinetics.
2020-11-30Complete rebuild of static docs of dev versionJohannes Ranke120-2656/+957
2020-11-30Log-Cholesky parameterisation as default in nlme.mmkinJohannes Ranke9-58/+86
2020-11-27Update static docsJohannes Ranke4-6/+7
2020-11-27Merge branch 'saving_compiled_code'Johannes Ranke7-67/+137
2020-11-27Closes #11Johannes Ranke1-0/+2
2020-11-27Improved way to have persistent DLLs for mkinmodJohannes Ranke7-51/+67
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.
2020-11-24Support storing mkinmod compiled code as CFunc objectsJohannes Ranke8-66/+120
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
2020-11-20export create_deg_funcJohannes Ranke2-0/+2
2020-11-19Update tests, improve CAKE_export testJohannes Ranke4-24/+25
2020-11-19Depend on parallel, doc improvementsJohannes Ranke144-1572/+3637
By depending on parallel instead of importing it, functions to set up and stop a cluster are always available when mkin is loaded. The use of multicore processing in mmkin on Windows is now documented in the help file, which brings mkin closer to a version 1.0 #9.
2020-11-13More work on f_time_norm_focusJohannes Ranke4-11/+22
2020-11-13Fixes for f_time_norm_focus, still very fragile...Johannes Ranke4-18/+49
2020-11-13Annotation of the fixJohannes Ranke1-1/+1
2020-11-13Fixed plotting of non-analytical solutions in saemJohannes Ranke3-22/+26
2020-11-12Model names in lrtest.mmkin, fix for print.mmkinJohannes Ranke2-2/+5
Fix the display of warnings and errors in print.mmkin, the matrix was erroneously transposed.
2020-11-12Update test outputJohannes Ranke1-1/+2
2020-11-12Use preprocessed data for 2,4-D, update docsJohannes Ranke5-40/+44
2020-11-12mkindsg class to hold groups of datasetsJohannes Ranke27-41/+585
- D24_2014 dataset on aerobic soil degradation of 2,4-D from the EU assessment as mkindsg object with metadata - f_time_norm_focus() to do time-step normalisation using the FOCUS method - focus_soil_moisture data with default moisture contents at pF1, pF 2 and pF 2.5 for USDA soil types from FOCUS GW guidance - Dataset generation scripts in inst/dataset_generation - Depend on R >= 2.15.1 in order to facilitate the use of utils::globalVariables()
2020-11-11Update static docsJohannes Ranke7-269/+306
2020-11-11Fix example code that was broken by use_of_ff = "max"Johannes Ranke1-6/+10
which is now the default
2020-11-11Fix docs and passing of dot arguments for saemJohannes Ranke1-6/+2
2020-11-11Rename saemix file, option to suppress saemix messagesJohannes Ranke1-4/+10
2020-11-11Skip vdiffr tests on travis as they are not robustJohannes Ranke7-13/+17
As can be seen in the miniscule change seen on R-devel in the reference plot updated with this commit
2020-11-11Check on r-devel, address NOTEJohannes Ranke2-6/+17
2020-11-11Add print and plot calls to the saem example codeJohannes Ranke14-65/+112
2020-11-10Digits for summary methods, print.saem.mmkinJohannes Ranke12-82/+137
2020-11-09I do not have a parms.nlme.mmkin methodJohannes Ranke1-2/+1
2020-11-09saemix.mmkin and nlme.mmkin inherit from mixed.mmkinJohannes Ranke25-213/+450
With a plot method. The class mixed.mmkin is currently only a virtual class created to unify the plotting method.
2020-11-09Merge plot methods for nlme.mmkin and saem.mmkinJohannes Ranke19-359/+694
This avoids code duplication
2020-11-09Add plot method for saem.mmkin objectsJohannes Ranke14-15/+637
2020-11-09object$mmkin_orig -> object$mmkinJohannes Ranke3-12/+10
2020-11-09Fix std in summary.nlme.mmkin(..., data = TRUE)Johannes Ranke1-1/+5
2020-11-09Remove outdated doc pageJohannes Ranke1-1202/+0
2020-11-09Doc improvementsJohannes Ranke4-6/+9
2020-11-09Some work on example code, pkgdown updateJohannes Ranke14-212/+451
2020-11-09Custom analytical solutions for saemixJohannes Ranke6-70/+183
Currently SFO-SFO and DFOP-SFO. Speed increase factor about 60
2020-11-08The call to saemix.predict fails with DFOP-SFOJohannes Ranke4-6/+6
2020-11-08Update static docsJohannes Ranke7-24/+482
2020-11-08Improve saem method, add summaryJohannes Ranke13-82/+459
Also make the endpoints function work for saem objects.
2020-11-07Update static docs for dev versionJohannes Ranke9-121/+450
2020-11-07Create saem generic for fitting saemix modelsJohannes Ranke10-123/+103
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.
2020-11-07Make deSolve predictions within saemix robustJohannes Ranke4-39/+63
Also, exclude the saemix function when loading saemix in the example code, to prevent overriding our generic
2020-11-06Make saemix an S3 generic in this packageJohannes Ranke3-59/+113
This commit also defined saemix.mmkin for mmkin row objects. This works fine, but if we set the class of the returned object to c("saemix.mmkin", "saemix"), it is not an S4 class any more which make it impossible to use saemix functions on it.

Contact - Imprint