OHDSI Home | Forums | Wiki | Github

CohortMethod user group


(Jungeun Park) #62

@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.


(Seng Chan You) #63

@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”)


(Martijn Schuemie) #64

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.


(Jungeun Park) #65

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:


(Jungeun Park) #66

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:


(Martijn Schuemie) #67

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?


(Jungeun Park) #68

@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?


(Seng Chan You) #69

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.


(Jungeun Park) #70

Sovled the issue! Thank you always :slight_smile:


(Jungeun Park) #71

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!


(Chris Knoll) #72

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


(Martijn Schuemie) #73

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.


t