OHDSI Home | Forums | Wiki | Github

Error when executing ATLAS PLE package

Hello,

We are currently stuck trying to execute a PLE study package (ATLAS) and cannot figure out what to change for the study to run correctly. The study fails on generating positive controls, but even when this line is commented out the package still will not run and has the error message “Only 0’s may be mixed with negative subscripts”. Is anyone able to see if they understand better what the issue is?

Thank you very much.

Thread:  3
Message:  only 0's may be mixed with negative subscripts
Level:  FATAL
Time:  2022-09-16 16:52:54

Stack trace:
4: .handleSimpleError(function (e) 
{
ParallelLogger::logFatal(conditionMe
3: which(population$endDate[idx] >= population$startDate[idx + 1] & population
2: createStudyPopulation(restrictToCommonPeriod = FALSE, removeDuplicateSubjec
1: do.call("createStudyPopulation", args)


Thread:  1
Message:  only 0's may be mixed with negative subscripts
Level:  FATAL
Time:  2022-09-16 16:52:54

Stack trace:
4: .handleSimpleError(function (e) 
{
ParallelLogger::logFatal(conditionMe
3: which(population$endDate[idx] >= population$startDate[idx + 1] & population
2: createStudyPopulation(restrictToCommonPeriod = FALSE, removeDuplicateSubjec
1: do.call("createStudyPopulation", args)


Thread:  2
Message:  only 0's may be mixed with negative subscripts
Level:  FATAL
Time:  2022-09-16 16:52:54

Stack trace:
4: .handleSimpleError(function (e) 
{
ParallelLogger::logFatal(conditionMe
3: which(population$endDate[idx] >= population$startDate[idx + 1] & population
2: createStudyPopulation(restrictToCommonPeriod = FALSE, removeDuplicateSubjec
1: do.call("createStudyPopulation", args)


Thread: Main
Message:  Error in ParallelLogger::clusterApply(cluster, objectsToCreate, createStudyPopObject) :    Error(s) when calling function 'fun', see earlier messages for details 
Level:  FATAL
Time:  2022-09-16 16:52:55

Stack trace:
5: stop(message)
4: ParallelLogger::clusterApply(cluster, objectsToCreate, createStudyPopObject)
3: CohortMethod.R#60: CohortMethod::runCmAnalyses(connectionDetails = connectionDetai
2: Main.R#123: runCohortMethod(connectionDetails = connectionDetails, cdmDatabaseSche
1: execute(connectionDetails = connectionDetails, cdmDatabaseSchema = cdmDatabaseSche

R version:
R version 4.0.4 (2021-02-15)

Platform:
x86_64-pc-linux-gnu

Attached base packages:
- stats
- graphics
- grDevices
- datasets
- utils
- methods
- base

Other attached packages:
- EHDENCOVIDUseCase2 (0.0.1)
- DatabaseConnector (3.0.0)

After looking into the error message, it seems that this error can arise in R when inclusion/exclusion criteria in a subset overlap.

I’m wondering if then this error could come from having overlapping inclusion and exclusion criteria in the cohort definition? In this study, we didn’t expect these two criteria to overlap, but I will update this thread if removing criteria 1 here resolves the issue.

The error message points to this line of code, where apparently idx contains negative values. This is a bit odd, since we know

idx <- 1:(nrow(population) - 1) (this line)

and

nrow(population) > 1 (this line)

Could you share the log file? It would be good to know under which of the specified analyses the problem occurs.

Also, could you confirm your CDM conforms exactly to the specifications (e.g. no fields that should be DATE are in fact VARCHAR)?

Unrelated to this error message, you should specify concepts to exclude from the propensity model as described here.

Hi, yes, the log file is attached below. Thank you for your help!

I will check with the data centre about the CDM specifications, but they have run other OHDSI studies before so I would assume it meets them.

log_positive_controls_FALSE.pdf (219.4 KB)

Unfortunately, ATLAS still uses a very old study package skeleton, making it hard for me to debug this problem. As a first step, would you mind regenerating the study package using Hydra instead of ATLAS? Please see the instructions here. This might already solve your problem.

Thank you for your advice. I have now tried hydrating the package and returning to the data center. Unfortunately, they do still experience another error that generated the error message “obect ‘user’ not found”. I have attached the log file below.

Additionally, these errors occur after turning off the synthesizePositiveControls command. When synthesizePositiveControls=true, there is a different error (also attached below)

logR_synthesizePositiveControls_False-28-9.pdf (750.4 KB)

log_synthesizePositiveControls_True.pdf (43.5 KB)

The ‘user’ not found error is actually pretty simple. It has to do with the fact that the connection details don’t keep the actual credentials in memory, rather it keeps the method to get to the credentials. This is done for security reasons, so your credentials aren’t stored in memory without encryption. So probably your code looks something like this:

user <- "abcde"
connectionDetails <- createConnectionDetails(... user = user ...)

But then when CohortMethod spins up separate threads, each thread being a separate R session, the user variable does not exist.

In general it is highly recommended to not keep credentials in your code, but instead use something like keyring. You only once (per computer) do

keyring::key_set_with_value("user", password = "abcde")

(the password argument is simply the thing that will be stored in your system’s encrypted credential manager)
and then in your code you can do

connectionDetails <- createConnectionDetails(... user = keyring::key_get("user")...)

This not only removes your credentials from your code (which improves security), it also avoids the ‘user object not found’ error.

I typically do this for the user, password, and server name.

Thank you for all your helpful responses–now we are facing a non-technical but content error in the study. I apologize for the amount of questions, but could you also look at this new error? Earlier, before specifying exposures to avoid for propensity matching, we had the issue:

Error in createPs(stopOnError = TRUE, excludeCovariateIds = list(), prior = list( :
High correlation between covariate(s) and treatment detected. Perhaps you forgot to exclude part of the exposure definition from the covariates?
In addition: There were 50 or more warnings (use warnings() to see the first

50)

We believed this warning was because we had not yet included covariates, but after following advice on the forum and selecting OHDSI standard covariates plus specifying concepts to exclude, the error persists. For the concept sets to exclude, we have combined the concept sets for the two drugs in each comparison (ie a comparison between aspirin and heparin has a concept set to exclude that consists of the concept set for aspirin plus the concept set for heparin.)

Based on the book of OHDSI, I believed that was the correct method, but it doesn’t seem to be working. Do you have any ideas? Thank you again for your help throughout.

Standard OHDSI covariates selected for each analysis:

log_positive_controls_FALSE.pdf (378.5 KB)

https://atlas-demo.ohdsi.org/#/estimation/cca/587

The error message is saying these drugs tend to be co-prescribed much more frequently with the target exposure relative to the comparator exposure (or the other way around, the message doesn’t specify):

  • midazolam
  • fentanyl
  • Phenylpiperidine

Because of that, the propensity model is highly predictive, and no estimates can be produced. I’m unsure why this would be the case. Neither remdesivir nor tocilizumab is typically co-prescribed with these drugs, right? All three drugs are typically used during and right after surgery. Maybe within the inclusion criteria used in this study either remdesivir or tocilizumab is used almost entirely in a surgery setting?

Thank you for the interpretation! I’m having trouble interpreting the error message, is this high correlation just within the Remdesivir and Tocilizumab comparison? In that case, why wouldn’t it then produce results for the other comparisons?

Then, assuming these drugs are commonly co-prescribed for COVID-19 treatment, would it then be reasonable to also exclude them from the propensity score analysis?

You could remove them from the propensity score, but then the question becomes: what effect are you estimating? Is the COVID treatment you’re interested in, or the drugs that are often co-prescribed?

t