Functions for checking that the model outputs on disk match the md5 hashes
stored in bbi_config.json at run time. In other words, checking that the
model and data files have not changed since the model was last run. See
Details section for what specific files are checked.
check_up_to_date(.bbi_object, ...)
# S3 method for bbi_nonmem_model
check_up_to_date(.bbi_object, ...)
# S3 method for bbi_nonmem_summary
check_up_to_date(.bbi_object, ...)the object to check. Could be
a bbi_{.model_type}_model object,
a bbi_{.model_type}_summary object,
or a bbi_log_df tibble.
Arguments passed through (currently none).
The returned value is invisible because a message is printed alerting the user of the specific files that have changed, if any. This facilitates calling the function for this side effect without explicitly handling the returned value.
bbi_model method invisibly returns a logical vector of length 2. The
first element (named "model") refers to the model files mentioned in Details.
The second element (named "data") refers to the data files mentioned in Details.
For both elements, they will be TRUE if nothing has changed, FALSE if
anything has changed. Note: if no file exists at the specified path,
FALSE will be returned because that is technically a "change." The file
used to exist and now it does not.
bbi_log_df method invisibly returns a named list of lists, with one
element for each row in the input tibble, with the name corresponding to the
value in the run column for that row. Each element of the list will contain
the two-element list returned from the bbi_model method (described above)
for the relevant model.
There is no add_up_to_date() function because if you would like to add
these columns to a bbi_log_df tibble you can use add_config(), which
contains model_has_changed and data_has_changed columns. Please note:
these contain the opposite boolean values (check_up_to_date() returns
TRUE if up to date, *_has_changed returns TRUE if changed).
Different files are checked depending on what type of model is being checked.
For NONMEM models
The model file (control stream)
The data file (referenced in $DATA within the control stream)