You appear to still be having issues loading the Java library from RStudio on OS X. Have you tried
sudo ln -f -s $(/usr/libexec/java_home)/jre/lib/server/libjvm.dylib /usr/local/lib as per
To narrow it down, you could try loading the libraries in the R console to see if RStudio is in fact the issue.
Hi.
Thanks for the advice. I’ve just tried running the sudo command in terminal but still facing the same error when running library(Achilles) in R-Studio. I’ve also tried loading the libraries in R console but get the same error message.
I’m not sure if this is an issue: I was unable to run sudo comments unless I logged out from the current user and logged in as root user on Mac. But as root user I do notice that my .bash profile is completely blank, whereas when I am logged in as the original user, my JAVA_HOME is set to:
export JAVA_HOME=/usr/libexec/java_home -v 1.8
Further when I type ‘java -version’ into the terminal, the version reflected is different from when I am using the other account
root user:
java 10.0.2 2018-07-17
Java™ SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot™ 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
original user:
java version “1.8.0_91”
Java™ SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot™ 64-Bit Server VM (build 25.91-b14, mixed mode)
I think @t_abdul_basser is on the right path.
When you run ‘library(rJava)’ does it load properly?
Try:
remove.packages(rJava)
(close R studio)
sudo ln -f -s $(/usr/libexec/java_home)/jre/lib/server/libjvm.dylib /usr/local/lib
install.packages(“rJava”, dependencies = TRUE, type=“source”)
Thanks @rtmill and @t_abdul_basser for the helpful and fast replies
Sorry for the late response. The thing is, I’m having trouble running the sudo commands, as mac terminal won’t accept my password even though I’m pretty sure I keyed in the correct admin password. argh. Let me figure this password thing out and I’ll let you know if I make any progress!
By the way, would it be possible to run Altas without running Achilles?
We have set up WebAPI and Atlas, and also have the CDM tables in our postgresql database, but the data sources are not showing on Atlas.
Please advise if possible. Thanks!
Attached screenshots showing the current status
This is after startup tomcat and type http://localhost:8080/WebAPI/Source/Sources in browser
This is after installing atlas and viewing the jobs (http://localhost:8080/Atlas/#/jobs) and config (http://localhost:8080/Atlas/#/configure) panels:
These are the schema set up in postgresql: webapi (69 tables) and cdm (39 tables). There is also another empty schema called results which is located in the same database as cdm, understand it will be populated once we get achilles working
These are our source and source and source_daimon tables:
Thank you
You can run atlas without running Achilles. Atlas lets you view Achilles results within the Atlas ‘Data Sources’ module, but you can do other tings besides browse Achilles results in Atlas!
That looks like you’ve set up WebAPI enough that you could do vocabulary searches (there is a source with a ‘vocabulary’ daimon set up). You gave a screeesnot of the ‘cdm’ schema, but I do not know if you have an ‘ohdsi’ schema set up in your CDM database (‘ohdsi’ is the name you gave to your results schema). You should create the result schema tables using the WebAPI’s ddl service:
http://localhost:8080/WebAPI/ddl/results?dialect=postgresql&schema=ohdsi
Due to the vast number of RDBMS platforms out there that we support for doing analytics, we do not automatically maintain the results schema. You’ll have to deploy these tables manually, and, if there are schema changes later, perform your own migrations to keep the data intact.
Once you deploy the tables to your ohdsi schema, you can generate cohorts, and do more interesting things like perform an incidence rate analysis.
Thanks, @ Chris Knoll. I think we may have configured the source and source daimons incorrectly. This was what we typed for the WebAPI SOURCE and SOURE_DAIMON Inserts:
INSERT INTO webapi.source (source_id, source_name, source_key, source_connection, source_dialect) VALUES (1, 'My Cdm', 'MY_CDM', 'jdbc:postgresql://127.0.0.1:5433/OHDSI?user=ohdsi_admin_user&password=admin1', 'postgresql');
INSERT INTO webapi.source (source_id, source_name, source_key, source_connection, source_dialect) VALUES (2, 'Default vocabulary', 'vocab', 'jdbc:postgresql://127.0.0.1:5433/OHDSI?user=ohdsi_admin_user&password=admin1', 'postgresql');
INSERT INTO webapi.source_daimon (source_daimon_id, source_id, daimon_type, table_qualifier, priority) VALUES (1,1,0, 'cdm', 0);
INSERT INTO webapi.source_daimon (source_daimon_id, source_id, daimon_type, table_qualifier, priority) VALUES (2,1,1, 'cdm', 0);
INSERT INTO webapi.source_daimon (source_daimon_id, source_id, daimon_type, table_qualifier, priority) VALUES (3,1,2, 'ohdsi', 0);
INSERT INTO webapi.source_daimon (source_daimon_id, source_id, daimon_type, table_qualifier, priority) VALUES (4,2,1, 'cdm', 1);
Instead of ‘OHDSI’, the database should be ‘CDM’ ?
Also, is there a difference between the results schema created by webapi ddl service and the results schema created by achilles?
Our current structure is as follows
CDM database:
-cdm schema
-results schema (for Achilles)
OHDSI database:
-webapi schema
We don’t have an ‘ohdsi’ schema set up in our CDM database
if we create the ohdsi schema from webapi ddl service, under which database should we keep it and can any user create the tables? Sorry for the multiple questions, and thanks all so much!
Hui Xing
Hi, Hui Xing,
if the name of your CDM database is ‘CDM’ then your connection string in your SOURCE table should be:
INSERT INTO webapi.source (source_id, source_name, source_key, source_connection, source_dialect) VALUES (1, 'My Cdm', 'MY_CDM', 'jdbc:postgresql://127.0.0.1:5433/CDM?user=ohdsi_admin_user&password=admin1', 'postgresql');
You really need to keep the database for WebAPI completely separate from your CDM databases. It looks like you’re using authentication for your CDM from your WebAPI database, which is valid, but can be confusing…you can specify in your SOURCE record a cdm-specfic user/password that has rights to read your cdm schema and write to your results schema.
If your results schema is called ‘results’ then your insert into source_daimon is also incorrect, and it should be:
INSERT INTO webapi.source_daimon (source_daimon_id, source_id, daimon_type, table_qualifier, priority) VALUES (3,1,2, 'results', 0);
The point of the SOURCE table is to store how to connect to your CDM database
If you see an OHDSI value in your connection string but that is not the name of your CDM database, you have an error.
The point of SOURCE_DAIMON is to store the names of your schemas. If you see an ‘ohdsi’ value in your source daimon table_qualifier, but you don’t have an ‘ohdsi’ schema in your cdm database, then you have an error.
Yes, there are differences. When you run Achilles, it will create an ‘achilles_results’ and ‘achilles_results_dist’ in the specified schema. If you want Atlas/WebAPI to read those tables, then you should set the results schema name in your Achilles call to write to the same schema as the cdm results schema.
I recognize this is confusing: now we are talking about an Achilles results schema? Achilles is something that can be run completely stand-alone. You don’t need WebAPI to run achilles, you don’t need a results schema created based on localhost/WebAPI/ddl/reults since achilles creates their own tables. However, if you do want to browse Achilles results in Atlas, then you will need to put the achilles table into the CDM’s results schema, because that is where Atlas/WebAPI is going to look for the achilles_results and achilles_results_dist tables. You can do that directly in achilles by specifying the ‘resultsSchema’ parameter as your cdm’s results schema. But this will only create achilles-oriented tables, In order for WebAPI to work on the CDM, you need to create the tables in the results schema from localhost/WebAPI/ddl/results.
Ah, i get it, the source and source daimon tables should point to the database where our cdm and results schemas reside, and the username and passwords refer to the user that has the rights to read/write the cdm and results schema, not the ohdsi_admin_user if they are different
Ok, in the end we created a results schema called ‘ohdsi’ under our CDM database, using the ddl from localhost/WebAPI/ddl/reults. For WebApi to read the achilles results In our achilles call we should specify the results schema as ‘ohdsi’, is that correct?
We have changed our connection string and managed to get the vocaulary loading in webapi:
However, the profile is still loading after one hour of waiting. Would this be due to the configuration is still incorrect 
, or some other reason?
Thank you,
Hui Xing
You got it!
You got it again! Tho, I would have called the schema ‘results’ because ‘ohdsi’ doesn’t really convey what the schema is for, but, it’s just a name, if it is working for you, great. just don’t confuse the ‘ohdsi’ schema that is your results schema with your WebAPI schema (which I think you called webapi)
Congrats! That means your webAPI is looking at the source table to figure out where to find the vocabulary tables, and performing the search. You should also be able to generate cohorts.
Well, in your browser, open up your console (control-shift-i in chrome) and see if you didn’t get some sort of error. Possibly it is a query error. But what it looks like you are doing is trying to pull up a profile for person_id = ‘12’. Does person_id 12 exist in your data?
I’m sorry the error handling isn’t more clear there. You shoudln’t need to wait an hour for a profile to load, it should only take 20-30 seconds depending on the volume of data.
managed to install rJava by following the instructions here:
It turns out that sudo on mac dosent work with blank passwords
Thanks
1 Like
Thanks for letting us know. This will help other Mac users! 
Hi, I get similar error, while I was installed ggplot2, after an update of it;
could you please help me?
thanks in advance
library(“ggplot2”)
Error in dyn.load(file, DLLpath = DLLpath, …) :
unable to load shared object ‘/Library/Frameworks/R.framework/Versions/3.2/Resources/library/rlang/libs/rlang.so’:
dlopen(/Library/Frameworks/R.framework/Versions/3.2/Resources/library/rlang/libs/rlang.so, 6): Library not loaded: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libR.dylib
Referenced from: /Library/Frameworks/R.framework/Versions/3.2/Resources/library/rlang/libs/rlang.so
Reason: Incompatible library version: rlang.so requires version 3.5.0 or later, but libR.dylib provides version 3.2.0
In addition: Warning message:
package ‘ggplot2’ was built under R version 3.5.2
Error: package or namespace load failed for ‘ggplot2’
Hi,
It looks like you installed a new version of R (3.5) on top of a previous version (3.2).
reference: https://community.rstudio.com/t/every-libraries-failed-to-load-after-upgrading-r-to-3-6-0/29736/21
If you’ve recently updated your R version, it will look for your installed libraries in a new directory, e.g., R/x86_pc_linux-gnu-library/3.6 (where previously you used, e.g., R version 3.4). On Windows platforms, there is a hand function to move all your installed libraries over to the new directory. For MacOS and Linux platforms, many libraries need to be compiled from source.
Try updating your packages with
update.packages(repos='http://cran.rstudio.com/', ask=FALSE, checkBuilt=TRUE)
Thanks very much for your amazing quick replay;
very useful;
I’ve checked my current version which is 3.2;
unfortunately from this directory : Library/frameworks/R.frameworks/versions/
I could see only 2 folder , label 3.2 and current;
Do you have any Idea I could uninstall the 3.5 , which actually “shadow” the 3.2
thanks again
Afraid I don’t know how to uninstall the 3.5, have you tried to update the R packages under 3.5?
update.packages(repos=‘http://cran.rstudio.com/’, ask=FALSE, checkBuilt=TRUE)
you can also change the version of R that RStudio uses back to 3.2