Hi Julian, Thank you! I didn't know that mysql command. That will be very useful. I have approximately 2.5 G in the umlsinterfaceindex database which contains the index for SNOMEDCT and MSH using the PAR/CHD relations.
I have not installed the 2013AB version and uncertain if there has been an increase in the number of concepts. It seems that there must be given such an increase in the size of the index. I do remember seeing emails about changes to SNOMEDCT but I did not look closely at them. I need to upgrade to the newer version so I will look at installing this sooner rather than later and send you the new numbers. I think using SNOMEDCT_US is okay -- the configuration file goes off of what sources are installed on the local machine. I do not hard code those anywhere. There must have been a name change in the sources for this version. I will start installing the new version and get back to you. Thanks! Bridget On Fri, Dec 27, 2013 at 9:52 AM, julian varghese <varghesejul...@gmail.com>wrote: > Hi Bridget, > I installed UMLS version 2013AB, and if I took the configuration as you > listed an error message crops up like > "SNOMEDCT is not listed in your umls view, so after having a look at the > table MRSAB I changed it to: > > SAB :: include SNOMEDCT_US > REL :: include PAR, CHD > > which works without any errors but takes a long time (running for 4 days > so far and still not terminated...) > Do you think this expression "SNOMEDCT_US" is ok to get the SnomedCT > vocabulary > (As mentioned, "SNOMEDCT" solely gives me the error...) ? > > >> The size is approximately 2.5 G > Does this refer to the umlsinterfaceindex database for the sole snomedct > configuration? > In my case there is explicitely a database called umlsinterfaceindex being > created)? > E.g. you can check the size of the databases easily via (just copy and > paste): > > SELECT table_schema databases, > Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB" > FROM information_schema.tables > GROUP BY table_schema; > > > Thanks, > Julian > > > 2013/12/27 Bridget McInnes <btmcin...@gmail.com> > >> Hi Julian, >> >> I have the UMLS version 2013AA installed. The index using the following >> configuration contains 13,520,173 rows. The size is approximately 2.5 G >> when I look specifically at the size of the tables for that configuration. >> I don't think that would be a direct comparison though. I have a number of >> index files created so I can only give what I think is the estimate -- >> total I am using 575G. >> >> Here is the configuration: >> SAB :: include SNOMEDCT >> REL :: include PAR, CHD >> >> Just in case this is different from yours. >> >> I do not remember how long it took exactly. I started it on a Friday and >> went away for the weekend. SNOMEDCT is the largest source so it normally >> takes a couple days to process all of the nodes to create the index. >> >> I hope this helps somewhat. Please let us know if you have additional >> questions! >> >> Best regards, >> >> Bridget >> >> >> On Fri, Dec 27, 2013 at 6:41 AM, julian varghese < >> varghesejul...@gmail.com> wrote: >> >>> Hi Bridget and Ted, >>> >>> my apologies if this question showed up before, I tried to add the >>> question >>> to the yahoo mailing group but I guess it did not work, so to make sure >>> I'm writing >>> this question directly to you: >>> >>> Having installed Umls-Similarity and the UMLS database from 2013 and >>> the latest version of umls similarity/interface on a Ubuntu System >>> (allocated memory 8gb,intel xeo 3 ghz). >>> The UMLS index for SnomedCT is being created (database: >>> umlsinterfaceindex). >>> To do that I listed "SNOMEDCT_US" in the SAB-source. >>> >>> >>> Can somebody tell me how large the umlsinterfaceindex database for >>> SnomedCT is or will be and how long it usually takes to have the >>> SnomedCT-index created? >>> >>> Right now I have installed only the important UMLS tables which are 11 >>> GB big, >>> but umlsinterfaceindex database ist getting larger and larger, it's now >>> at >>> 14 gb... just want to know whether this is normal, since the index is >>> getting bigger >>> than the database itself... >>> >>> Thanks, >>> Julian >>> >> >> >
