OHDSI Home | Forums | Wiki | Github

CohortMethod user group

@schuemie
Issue cleared! Thank you so much. :slight_smile:

+I have a question. I get the error below. I checked

Error in ff(initdata = initdata, length = length, levels = levels, ordered = ordered,  : 
  unable to open

I checked options("fftempdir") and it was
"E:/USER/DPJE001/rcode/temp". I could see list of files saved in that path.
I wonder why those files are unable to open.
Thank you always.

@JUNGEUN_PARK
Iā€™m not sure this can solve your problem, but I usually specify temporary directory for ff before executing the OHDSI package.

options(fftempdir = ā€œc:/FFtempā€)

Agreed, it is probably best to just define the fftemp folder yourself.

Maybe some background will help:

ff is a package for keeping objects that are too big to fit in memory. It does this through ā€˜memory-mappingā€™: part of the data is kept in memory, and part is written to a temporary file on the disk. To the user, it looks as if the object is entirely in memory, and your operating system swaps out what is on the disk with what is in memory as needed.

That means that every time you open an ff object, it needs to create a temp file. It does this in the fftempdir. As long as the ff object is open, the file is locked and you cannot change it with any other program.

If you restart R but keep your workspace, things get a bit tricky. Maybe the temp file was cleaned up (deleted), but you still have an R object that points to it, so that could be one reason you get this message. Another reason for trouble could of course be if thereā€™s no space left in the fftempdir, but youā€™ve already ruled that out.

I find it helps to once in a while just close down all instances of R, and delete your workspace (called ā€œ.Rdataā€). And specify your fftempdir as Chan mentioned.

I found out that running createDrugComparatorOutcomes() with patricular sets of (targetID, comparatorID, outcomeIDs) was throwing ff() : unable to open error.

It seems like some ff files are not created for these sets or the ff files are named somewhat different from the other setsā€™ and I have no clues for the reason.
I checked the list below and all seemed just fine.
1.cohortMethodData and getAttritionTable()
2. the ā€œschemaā€.ā€œtableā€ of those outcomes in oracle.
3. cohort definition and reports of the sets in the atlas

Iā€™ll try some different ways but please let me know if you have any ideas about it :slight_smile:

Thank you. Iā€™m working on it!

I have a question about population-level estimation. For some studies, running runanalysis(), the summary of the result values (rr etc) come out all naā€™. Is there any way I could get real values other than na? I searched for the reason but coulndā€™t really fine answer tor this question.

Thank you very much! :slight_smile:

NA values are usually because thereā€™s no one with the outcome left in the study population. How many people are there in your cohorts? How many have the outcome?

@schuemie
Thank you.
Itā€™s interesting. Iā€™ve just run the exact same study for third time to answer your question and now it says rr as 1 with CI (0.04,25.3), pvalue as 1.
and attritionDiagarm says thereā€™s only two people left so that was why!

Statistically this value isnā€™t really worth to be used, is it?

The result can vary across the attempts (or less consistent), if there isnā€™t sufficient number of patients in the cohorts.
Yes, this value doesnā€™t mean that there is significant association.

Sovled the issue! Thank you always :slight_smile:

Hello,
thereā€™s a strange thing happening in my institute.
Some cohort Ids generated in table ā€œCOHORTā€(with Atlas, usually) disappear from time to time with no reasons.
Canā€™t rule out a possibiltiy that someone might just drop the rows from the table but I wonder if it ever happens to any institute or when it happens.
Hope I get any hints or clues to solve it. Thank you!

If you can set up logging/auditing on your DB, you might be able to track down what is causing the delete.

1 Like

CohortMethod v3.1.0 has just been released!

The most important change is that the addExposureDaysToStart and addExposureDaysToEnd arguments of the createStudyPopulation function have been deprecated (meaning you can still use them, but if you do you get a warning). Instead, you should use the new arguments called startAnchor and endAnchor.

So where previously you might have:

studyPop <- createStudyPopulation(cohortMethodData = cohortMethodData,
                                  outcomeId = 3,
                                  riskWindowStart = 0,
                                  addExposureDaysToStart = FALSE,
                                  riskWindowEnd = 30,
                                  addExposureDaysToEnd = TRUE)

you will now have:

studyPop <- createStudyPopulation(cohortMethodData = cohortMethodData,
                                  outcomeId = 3,
                                  riskWindowStart = 0,
                                  startAnchor = "cohort start",
                                  riskWindowEnd = 30,
                                  endAnchor = "cohort end")

The new interface is more in line with the ATLAS Estimation tool, and is expected to be less confusing.

All old code should still run with the new interface.

Hi @schuemie ,
I am doing a study following the Cohort Method Single Studies vignette, and I was exploring the effects of limiting the covariates on my Outcome Model. I have the concept IDs for the covariates of interest.
I was wondering if there is a way to get covariates IDs from concept IDs, and if I have to generate the cohortMethodData object first or not. I would like to be able to limit the covariates at the covSettings level, but maybe it is easier to do it when calling fitOutcomeModel.

Also, is there a way to access the covariate ref object from the Andromeda CohortMethodData object, to tweak the grepCovariateNames for it to work again ?

Thank you!

t