OHDSI Home | Forums | Wiki | Github

Initial Setup required for CICRCE and CALYPSO

Hello All,

As some of you may know me and @Suranga are working on importing OpenMRS data into CDM format. We have populated Person, Provider, Obsersvation_perion, Visit_occurrence, Condition_occurrence tables.
We are able to get results for Achilles using R as per instructions given at https://github.com/OHDSI/Achilles.

Is there any such instructions for generating analytical data specific using those tables for CIRCE/CALYPSO to work?

We tried accessing CIRCE/CALYPSO using OLYMPUS but got this in our log:

ERROR qtp1208571359-17 org.apache.velocity - - ResourceManager : unable to find resource ‘templates/common/common_template.html.vm’ in any resource loader.
ERROR qtp1208571359-21 org.apache.velocity - - ResourceManager : unable to find resource ‘templates/common/common_template.html.vm’ in any resource loader.

You can ignore the common_template error. Circe, as it does not support various locations of WebAPI (remote vs local), currently requires you run your local Olympus WebAPI. Do you have the WebAPI running via Olympus? If so, can you include your startup log.
I’m guessing you see a blank screen for Circe? This usually happens when it can’t connect to a WebAPI.

Hello @alfranke,

I haven’t tried using the WebAPI, But, I tried it now you were right there are some issues with connecting to our LocalWeb API - The log is here - http://pastebin.com/E1MdUxWD.

I am not sure what might have gone wrong - I am attaching the screenshots of the error displayed in OLYMPUS and also my local web API config

@maurya, can you include the entire log of Olympus startup and WebAPI launch? The log you included only has part of the exception and doesn’t seem to indicate root problem. Typically, when I see the “hibernate.dialect not set”, that usually means there is a problem with the connection to the database.

FYI, you can add the following property to the java process to auto start the local WebAPI (after config has been persisted). -Dolympus.webapi.launch.enabled=true
So, if you add this property, start Olympus, and attach the log, I may be able to provide more assistance.

@alfranke,

I have tried including the argument ,here is the log - http://pastebin.com/fS4T6uVC , but it didn’t launch the Local WEBAPI , when I tried to launch it manually, it gave this log - http://pastebin.com/g7cMaCF8

Hi there,

@alfranke, thanks for helping us with this. But um, also, isn’t there an alternative R method to do the same without using olympus? With Achillies, we could generate the json files using R code, and upload them to our own http server. Is Olympus the only route available for Circe and Calypso?

@Suranga , looks like a bad password or user. Olympus is intended to be a convenience (simply way to run OHDSI apps). It also adds a basic layer of security in front of the apps. As you mentioned, you can install/configure your own web server for Circe, Calypso, etc.

2015-08-28 15:20:22.002 WARN qtp647768661-19 org.hibernate.engine.jdbc.internal.JdbcServicesImpl -  - HHH000342: Could not obtain connection to query metadata : FATAL: password authentication failed f
or user "root"

@Suranga, Achilles is the only one of the current web-based applications with R code. The rest require running WebAPI. This can be implemented manually (GitHub) and Circe and Calypso can be downloaded and run directly against this instance.

FWIW, at present, Olympus applications are a couple versions behind those on GitHub due to the switch to a new WebAPI branch called multi-homed. We hope to have a multi-homed version of a Olympus out soon so everyone can enjoy the latest versions of the applications without having to build WebAPI manually.

Jon

you are correct, the username was wrong The username was postgres for this database instead of the root I’ve been using. But it gave a new error now - http://pastebin.com/6vSpwQ6r does this look familiar?

Doesn’t look like it can find the database vocabularyv5.

2015-09-01 01:27:30.693 WARN qtp651770080-17 org.hibernate.engine.jdbc.internal.JdbcServicesImpl -  - HHH000342: Could not obtain connection to query metadata : FATAL: database "vocabularyv5" does not
 exist

Thank you @alfranke for your patience going through the error logs. I didn’t have an idea that Service Name was database name (I did give the proper database name for CDM Database Name). But thanks to you there are no connection errors anymore.

But it gave rise to some new flyway error about cohort_definition table already
existing . I looked through this post Olympus configuration questions/problems and it was suggested that the table be deleted and let flyway create it. I went ahead and did that but, it gave rise to a new flyway error - http://pastebin.com/DXYjSNNU. I am not sure about how to resolve this.

Thanks for all the help @alfranke

UPDATE: tried removing COHORT table in response to previous error now am receiving cohort_definition does not exist error -http://pastebin.com/J0yMJuJs

Does it exist? Could it be that you deleted it again, as well as cohort, when you ran into the latest “cohort already exists” error? Flyway keeps track of migrations applied, and if you deleted cohort_definition after it had applied the “create cohort_definition” script, then that would explain the error.

You might consider creating a new schema for WebAPI and separate that schema from the “CDM schema”. There is a known conflict between naming conventions between WebAPI and CDM with regards to cohort and cohort_definition.

The scripts are here in case you haven’t referenced them:

2015-09-02 01:03:55.484 INFO qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Current version of schema "public": 1.0.0.3.2
2015-09-02 01:03:55.484 WARN qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - outOfOrder mode is active. Migration of schema "public" may not be reproducible.
2015-09-02 01:03:55.485 INFO qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Migrating schema "public" to version 1.0.0.4
2015-09-02 01:03:55.592 INFO qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Migrating schema "public" to version 1.0.0.4.1
2015-09-02 01:03:55.594 INFO qtp965307475-44 org.flywaydb.core.internal.dbsupport.JdbcTemplate -  - DB: table "heracles_heel_results" does not exist, skipping
2015-09-02 01:03:55.607 INFO qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Migrating schema "public" to version 1.0.0.4.3
2015-09-02 01:03:55.628 INFO qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Migrating schema "public" to version 1.0.0.5
2015-09-02 01:03:55.638 ERROR qtp965307475-44 org.flywaydb.core.internal.command.DbMigrate -  - Migration of schema "public" to version 1.0.0.5 failed! Changes successfully rolled back.

1.0.0.5 references the cohort definition table so if it was deleted by hand, most likely this is the error.

It would probably be simplest to move your CDM tables out to their own schema, and have the OHDSI tables created in the default schema (public).

-Chris

I need to thank @alfranke for helping me out a lot regarding the setup. I am able to start CIRCE and CALYPSO

Future Reference: The results(tables generated) should be the default schema in postgres (can be checked through “show search_path”) which is public by default. And the CDM schema should be different schema in the same database.

If the results(tables generated) is not the default schema then WebAPI cannot access it and it will throw a ResultSet Extraction Exception. I would request to remove this dependency in future releases if possible. Wouldn’t have found out without @alfranke and @Chris_Knoll 's help.

t