You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(28) |
Nov
(87) |
Dec
(16) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(109) |
Feb
(107) |
Mar
(117) |
Apr
(5) |
May
(156) |
Jun
(83) |
Jul
(86) |
Aug
(25) |
Sep
(17) |
Oct
(14) |
Nov
(82) |
Dec
(50) |
2004 |
Jan
(14) |
Feb
(75) |
Mar
(110) |
Apr
(83) |
May
(20) |
Jun
(36) |
Jul
(12) |
Aug
(37) |
Sep
(9) |
Oct
(11) |
Nov
(52) |
Dec
(68) |
2005 |
Jan
(46) |
Feb
(94) |
Mar
(68) |
Apr
(55) |
May
(67) |
Jun
(65) |
Jul
(67) |
Aug
(96) |
Sep
(79) |
Oct
(46) |
Nov
(24) |
Dec
(64) |
2006 |
Jan
(39) |
Feb
(31) |
Mar
(48) |
Apr
(58) |
May
(31) |
Jun
(57) |
Jul
(29) |
Aug
(40) |
Sep
(22) |
Oct
(31) |
Nov
(44) |
Dec
(51) |
2007 |
Jan
(103) |
Feb
(172) |
Mar
(59) |
Apr
(41) |
May
(33) |
Jun
(50) |
Jul
(60) |
Aug
(51) |
Sep
(21) |
Oct
(40) |
Nov
(89) |
Dec
(39) |
2008 |
Jan
(28) |
Feb
(20) |
Mar
(19) |
Apr
(29) |
May
(29) |
Jun
(24) |
Jul
(32) |
Aug
(16) |
Sep
(35) |
Oct
(23) |
Nov
(17) |
Dec
(19) |
2009 |
Jan
(4) |
Feb
(23) |
Mar
(16) |
Apr
(16) |
May
(38) |
Jun
(54) |
Jul
(18) |
Aug
(40) |
Sep
(58) |
Oct
(6) |
Nov
(8) |
Dec
(29) |
2010 |
Jan
(40) |
Feb
(40) |
Mar
(63) |
Apr
(95) |
May
(136) |
Jun
(58) |
Jul
(91) |
Aug
(55) |
Sep
(77) |
Oct
(52) |
Nov
(85) |
Dec
(37) |
2011 |
Jan
(22) |
Feb
(46) |
Mar
(73) |
Apr
(138) |
May
(75) |
Jun
(35) |
Jul
(41) |
Aug
(13) |
Sep
(13) |
Oct
(11) |
Nov
(21) |
Dec
(5) |
2012 |
Jan
(13) |
Feb
(34) |
Mar
(59) |
Apr
(4) |
May
(13) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
2013 |
Jan
(18) |
Feb
(28) |
Mar
(19) |
Apr
(42) |
May
(43) |
Jun
(41) |
Jul
(41) |
Aug
(31) |
Sep
(6) |
Oct
(2) |
Nov
(2) |
Dec
(70) |
2014 |
Jan
(55) |
Feb
(98) |
Mar
(44) |
Apr
(40) |
May
(15) |
Jun
(18) |
Jul
(20) |
Aug
(1) |
Sep
(13) |
Oct
(3) |
Nov
(37) |
Dec
(85) |
2015 |
Jan
(16) |
Feb
(12) |
Mar
(16) |
Apr
(13) |
May
(16) |
Jun
(3) |
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(2) |
2016 |
Jan
(12) |
Feb
(1) |
Mar
(9) |
Apr
(13) |
May
(4) |
Jun
(5) |
Jul
|
Aug
|
Sep
(10) |
Oct
(11) |
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
(8) |
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(1) |
2018 |
Jan
(6) |
Feb
(6) |
Mar
(3) |
Apr
(9) |
May
(3) |
Jun
|
Jul
|
Aug
(3) |
Sep
(8) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2020 |
Jan
(22) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Joe C. <jwc...@lb...> - 2023-05-12 16:08:49
|
Hi Scott, For those of us in institutionalized settings, running a custom compilation of postgres might be a hurdle. They tend not to like custom builds of privileged code. I think we might want to talk about other issues where chado is showing its age. Chromosomes are getting bigger and it’s only a matter of time before fmin and fmax need to be larger than 2G. (I’m looking at a pine tree outside my window now.) We’re running a big db - the current size is 11T - and I’ve needed to promote some counters to bigints. We can call it okiichado. I’ve wondered whether it makes sense to store residues in chunks in a dimension table rather than as a column in the feature table. I realize that internally postgres breaks things up and stores it differently than the main records. But what are the access patterns that we really use? For most features (mRNAs, peptides,…) we will want to grab the whole thing. But for chromosomes don’t we normally just want a substring? Would storing things in chunks make that more efficient? We’d need a function call to be able to access a substring so that makes it more complicated. (Right now we’re a hybrid of storing residues for some things accessed often in the feature table and chunked for the bigger things in a dimension table.) > On May 11, 2023, at 9:54 PM, Scott Cain <sc...@sc...> wrote: > > I was kind of remembering that you wrote about this. I wonder if we could/should compile our own Postgres server to bump up that limit. At first blush, that sounds like a terrible idea but I could be convinced. > >> On May 11, 2023, at 4:14 PM, Joe Carlson <jwc...@lb...> wrote: >> >> Hello, >> >> I cannot be done. Even though the documentation for a TEXT type in postgresql says it is ‘variable unlimited length', there is an internal limitation of the size of an allocated buffer. It’s in the documentation for the character data type https://www.postgresql.org/docs/current/datatype-character.html: <https://www.postgresql.org/docs/current/datatype-character.html:> I really _should_ learn to proofread. I meant to say ‘It cannot be done…' Joe >> >>> In any case, the longest possible character string that can be stored is about 1 GB. >> >> >> I recently ran into this problem myself and tried various ways around the limit by storing chunks and trying to concatenate with plpgsql functions, but that did not work. (https://www.postgresql.org/message-id/80025ECD-44A6-454F-A4F9-784474B84952%40lbl.gov <https://www.postgresql.org/message-id/800...@lb...>). >> >> You need to store residues as chunked pieces in a separate table and rely on your middleware code to split pieces on injest and concatenate on output. >> >> Joe Carlson >> >>> On May 9, 2023, at 10:22 AM, Cheng, Chun-Huai via Gmod-schema <gmo...@li... <mailto:gmo...@li...>> wrote: >>> >>> Hi, >>> >>> We have a big genome with large chromosomes that each of them is greater than 1G bp. We're having trouble loading them into the 'feature' table. We've tried the Tripal FASTA loader and a custom script, but both failed with some error (in Postgres v12 log: ERROR: invalid memory alloc request size 1161290884). Is there any way we can load the sequences for the genome into Chado? >>> >>> Here's some length information about the genome: >>> >>> chr1 1853204363 >>> chr2 1709916750 >>> chr3 1527935595 >>> chr4 1588398909 >>> chr5 1297479159 >>> chr6 1379031673 >>> >>> >>> Thank you very much for your help, >>> >>> Chun-Huai Cheng >>> _______________________________________________ >>> Gmod-schema mailing list >>> Gmo...@li... <mailto:Gmo...@li...> >>> https://lists.sourceforge.net/lists/listinfo/gmod-schema <https://lists.sourceforge.net/lists/listinfo/gmod-schema> >> _______________________________________________ >> Gmod-schema mailing list >> Gmo...@li... >> https://lists.sourceforge.net/lists/listinfo/gmod-schema |
From: Cheng, Chun-H. <chu...@ws...> - 2023-05-12 16:04:56
|
Thank you both for answering my questions. I don't mind using the GMOD version of Postgres if it's well maintained. Or at least should we urge the Postgres developers to bump that limit in the future release? Chun-Huai ________________________________ From: Scott Cain <sc...@sc...> Sent: Thursday, May 11, 2023 9:54 PM To: Joe Carlson <jwc...@lb...> Cc: Cheng, Chun-Huai <chu...@ws...>; gmo...@li... <gmo...@li...> Subject: Re: [Gmod-schema] Loading chromosome sequences greater than 1G bp long. [EXTERNAL EMAIL] I was kind of remembering that you wrote about this. I wonder if we could/should compile our own Postgres server to bump up that limit. At first blush, that sounds like a terrible idea but I could be convinced. On May 11, 2023, at 4:14 PM, Joe Carlson <jwc...@lb...> wrote: Hello, I cannot be done. Even though the documentation for a TEXT type in postgresql says it is ‘variable unlimited length', there is an internal limitation of the size of an allocated buffer. It’s in the documentation for the character data type https://www.postgresql.org/docs/current/datatype-character.html:<https://urldefense.com/v3/__https://www.postgresql.org/docs/current/datatype-character.html:__;!!JmPEgBY0HMszNaDT!r6EhVZuJU69Aj_RlYei7ShU_fjjwROeYApefHMo6TG3Hczdk1aP0_uYvPhCLfdMhFAMsNrqhpke6KF8kD5N0eg$> In any case, the longest possible character string that can be stored is about 1 GB. I recently ran into this problem myself and tried various ways around the limit by storing chunks and trying to concatenate with plpgsql functions, but that did not work. (https://www.postgresql.org/message-id/80025ECD-44A6-454F-A4F9-784474B84952%40lbl.gov<https://urldefense.com/v3/__https://www.postgresql.org/message-id/800...@lb...__;!!JmPEgBY0HMszNaDT!r6EhVZuJU69Aj_RlYei7ShU_fjjwROeYApefHMo6TG3Hczdk1aP0_uYvPhCLfdMhFAMsNrqhpke6KF9HEvjIzQ$>). You need to store residues as chunked pieces in a separate table and rely on your middleware code to split pieces on injest and concatenate on output. Joe Carlson On May 9, 2023, at 10:22 AM, Cheng, Chun-Huai via Gmod-schema <gmo...@li...<mailto:gmo...@li...>> wrote: Hi, We have a big genome with large chromosomes that each of them is greater than 1G bp. We're having trouble loading them into the 'feature' table. We've tried the Tripal FASTA loader and a custom script, but both failed with some error (in Postgres v12 log: ERROR: invalid memory alloc request size 1161290884). Is there any way we can load the sequences for the genome into Chado? Here's some length information about the genome: chr1 1853204363 chr2 1709916750 chr3 1527935595 chr4 1588398909 chr5 1297479159 chr6 1379031673 Thank you very much for your help, Chun-Huai Cheng _______________________________________________ Gmod-schema mailing list Gmo...@li...<mailto:Gmo...@li...> https://lists.sourceforge.net/lists/listinfo/gmod-schema<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gmod-schema__;!!JmPEgBY0HMszNaDT!r6EhVZuJU69Aj_RlYei7ShU_fjjwROeYApefHMo6TG3Hczdk1aP0_uYvPhCLfdMhFAMsNrqhpke6KF-P204wlg$> _______________________________________________ Gmod-schema mailing list Gmo...@li... https://lists.sourceforge.net/lists/listinfo/gmod-schema<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gmod-schema__;!!JmPEgBY0HMszNaDT!r6EhVZuJU69Aj_RlYei7ShU_fjjwROeYApefHMo6TG3Hczdk1aP0_uYvPhCLfdMhFAMsNrqhpke6KF-P204wlg$> |
From: Scott C. <sc...@sc...> - 2023-05-12 05:19:49
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">I was kind of remembering that you wrote about this. I wonder if we could/should compile our own Postgres server to bump up that limit. At first blush, that sounds like a terrible idea but I could be convinced. </div><div dir="ltr"><br><blockquote type="cite">On May 11, 2023, at 4:14 PM, Joe Carlson <jwc...@lb...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8">Hello,<div class=""><br class=""></div><div class="">I cannot be done. Even though the documentation for a TEXT type in postgresql says it is ‘variable unlimited length', there is an internal limitation of the size of an allocated buffer. It’s in the documentation for the character data type <a href="https://www.postgresql.org/docs/current/datatype-character.html:" class="">https://www.postgresql.org/docs/current/datatype-character.html:</a></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: "Open Sans", sans-serif; font-size: 14.4px; font-variant-ligatures: normal; orphans: 2; widows: 2; text-decoration-thickness: initial;" class="">In any case, the longest possible character string that can be stored is about 1 GB.</span></blockquote></div><div class=""><br class=""></div><div class="">I recently ran into this problem myself and tried various ways around the limit by storing chunks and trying to concatenate with plpgsql functions, but that did not work. (<a href="https://www.postgresql.org/message-id/800...@lb..." class="">https://www.postgresql.org/message-id/80025ECD-44A6-454F-A4F9-784474B84952%40lbl.gov</a>).</div><div class=""><br class=""></div><div class="">You need to store residues as chunked pieces in a separate table and rely on your middleware code to split pieces on injest and concatenate on output.</div><div class=""><br class=""></div><div class="">Joe Carlson<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 9, 2023, at 10:22 AM, Cheng, Chun-Huai via Gmod-schema <<a href="mailto:gmo...@li..." class="">gmo...@li...</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="elementToProof ContentPasted0" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Hi,<div class=""><br class="ContentPasted0"></div><div class="ContentPasted0">We have a big genome with large chromosomes that each of them is greater than 1G bp. We're having trouble loading them into the 'feature' table. We've tried the Tripal FASTA loader and a custom script, but both failed with some error (in Postgres v12 log: ERROR: invalid memory alloc request size 1161290884). Is there any way we can load the sequences for the genome into Chado?</div><div class=""><br class="ContentPasted0"></div><div class="ContentPasted0">Here's some length information about the genome:</div><div class="ContentPasted0"><br class=""></div><div class="ContentPasted0">chr1 1853204363</div><div class="ContentPasted0">chr2 1709916750</div><div class="ContentPasted0">chr3 1527935595</div><div class="ContentPasted0">chr4 1588398909</div><div class="ContentPasted0">chr5 1297479159</div><div class="ContentPasted0">chr6 1379031673</div><div class=""><br class="ContentPasted0"></div><div class=""><br class="ContentPasted0"></div><div class="ContentPasted0">Thank you very much for your help,</div><br class=""></div><div class="elementToProof" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class=""><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;" class="">Chun-Huai Cheng</span><br class=""></div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Gmod-schema mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:Gmo...@li..." style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Gmo...@li...</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://lists.sourceforge.net/lists/listinfo/gmod-schema" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.sourceforge.net/lists/listinfo/gmod-schema</a></div></blockquote></div><br class=""></div><span>_______________________________________________</span><br><span>Gmod-schema mailing list</span><br><span>Gmo...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/gmod-schema</span><br></div></blockquote></body></html> |
From: Joe C. <jwc...@lb...> - 2023-05-11 23:14:33
|
Hello, I cannot be done. Even though the documentation for a TEXT type in postgresql says it is ‘variable unlimited length', there is an internal limitation of the size of an allocated buffer. It’s in the documentation for the character data type https://www.postgresql.org/docs/current/datatype-character.html: > In any case, the longest possible character string that can be stored is about 1 GB. I recently ran into this problem myself and tried various ways around the limit by storing chunks and trying to concatenate with plpgsql functions, but that did not work. (https://www.postgresql.org/message-id/80025ECD-44A6-454F-A4F9-784474B84952%40lbl.gov <https://www.postgresql.org/message-id/800...@lb...>). You need to store residues as chunked pieces in a separate table and rely on your middleware code to split pieces on injest and concatenate on output. Joe Carlson > On May 9, 2023, at 10:22 AM, Cheng, Chun-Huai via Gmod-schema <gmo...@li...> wrote: > > Hi, > > We have a big genome with large chromosomes that each of them is greater than 1G bp. We're having trouble loading them into the 'feature' table. We've tried the Tripal FASTA loader and a custom script, but both failed with some error (in Postgres v12 log: ERROR: invalid memory alloc request size 1161290884). Is there any way we can load the sequences for the genome into Chado? > > Here's some length information about the genome: > > chr1 1853204363 > chr2 1709916750 > chr3 1527935595 > chr4 1588398909 > chr5 1297479159 > chr6 1379031673 > > > Thank you very much for your help, > > Chun-Huai Cheng > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... <mailto:Gmo...@li...> > https://lists.sourceforge.net/lists/listinfo/gmod-schema <https://lists.sourceforge.net/lists/listinfo/gmod-schema> |
From: Cheng, Chun-H. <chu...@ws...> - 2023-05-09 17:44:42
|
Hi, We have a big genome with large chromosomes that each of them is greater than 1G bp. We're having trouble loading them into the 'feature' table. We've tried the Tripal FASTA loader and a custom script, but both failed with some error (in Postgres v12 log: ERROR: invalid memory alloc request size 1161290884). Is there any way we can load the sequences for the genome into Chado? Here's some length information about the genome: chr1 1853204363 chr2 1709916750 chr3 1527935595 chr4 1588398909 chr5 1297479159 chr6 1379031673 Thank you very much for your help, Chun-Huai Cheng |
From: Scott C. <sc...@sc...> - 2023-04-14 16:41:39
|
Highlights - Submit <https://www.open-bio.org/events/bosc-2023/submit/> your 1-2 page abstract by April 20 (by the end of the day anywhere in the world). (Sorry, no extensions.) - You can request registration fee assistance right on the submission form! - We have two exciting Keynote Speakers <https://www.open-bio.org/events/bosc-2023/bosc-2023-keynotes/> lined up! - We are planning a Panel Discussion about Open and Ethical Data Sharing! - BOSC and Bio-Ontologies <https://www.bio-ontologies.org.uk/ismb-annual-meeting/2023-meeting> will join forces for a joint session on July 24 or 25. - We welcome our first sponsors <https://www.open-bio.org/events/sponsors/> (more coming soon): GigaScience <https://academic.oup.com/gigascience>, GeneVia <https://geneviatechnologies.com/>, and Software Sustainability Institute <https://www.software.ac.uk/>! Keynote speakers [image: Sara El-Gebali] Sara El-Gebali <https://www.open-bio.org/events/bosc-2023/bosc-2023-keynotes/> (SciLifeLab-DataCentre-Sweden): “A New Odyssey: Pioneering the Future of Scientific Progress Through Open Collaboration.” Joseph M. Yracheta <https://www.open-bio.org/events/bosc-2023/bosc-2023-keynotes/> (Native BioData Consortium): “The Dissonance between Scientific Altruism & Capitalist Extraction: The Zero Trust and Federated Data Sovereignty Solution Abstract submission We encourage you to submit abstracts <https://www.open-bio.org/events/bosc-2023/submit/> (due April 20 – sorry, no extensions) on any topic relevant to open source bioinformatics or open science (see topic list below). After review, some abstracts will be selected for lightning talks, longer talks, or posters. A second “late poster” round of submissions will end May 18. Abstract submission is via ISMB’s EasyChair (linked from our submission page <https://www.open-bio.org/events/bosc-2023/submit/>). Note that ISMB requires a short (200-word) text-only abstract for all submissions (talk or poster), plus a “long abstract” (PDF, 2 pages max) if you want to be considered for a talk. About BOSC Since 2000, the Bioinformatics Open Source Conference <https://www.open-bio.org/events/bosc-2021/about/> has provided a forum for developers and users to interact and share research results and ideas in open source bioinformatics and open science. As usual, BOSC 2023 <https://www.open-bio.org/events/bosc-2023/> will include keynote talks, longer and shorter (lightning) talks from submitted abstracts, posters, Birds of a Feather, and more! Like last year, BOSC and Bio-Ontologies <https://www.bio-ontologies.org.uk/ismb-annual-meeting/2023-meeting> will join forces for a joint session. BOSC topics include (but are not limited to): - Open Science and Reproducible Research - Open Biomedical Data - Citizen/Participatory Science - Standards and Interoperability - Data Science - Workflows - Open Approaches to Translational Bioinformatics - Open Science for Global Health - Developer Tools and Libraries - Inclusion, Outreach and Training - Bioinformatics Open Source Project Reports (about new or existing projects) - Open and interoperable ontologies (joint session with Bio-Ontologies) Registration fee assistance We realize that the cost of ISMB may be prohibitive for some. If you are submitting an abstract to BOSC and would have difficulty covering the cost of registration, you can request to be considered for a registration fee waiver right on the abstract submission form (your request will not be seen by reviewers). Fee waivers are made possible by our sponsors <https://www.open-bio.org/events/sponsors/>. Sponsors We welcome the first Silver sponsors <https://www.open-bio.org/events/sponsors/> of BOSC 2023! If you’re interested in becoming a sponsor, let us know! [image: Gigascience] <https://academic.oup.com/gigascience> <https://geneviatechnologies.com/> <https://www.software.ac.uk/> ------------------------------ Key Dates - April 20, 2023: Deadline for submitting talk/poster abstracts <https://www.open-bio.org/events/bosc-2023/submit/> - May 11: Talk/poster acceptance notifications - May 18: Late poster submission deadline - May 25: Late poster acceptance notifications - July 24-25: BOSC 2023 <https://www.open-bio.org/events/bosc-2023/> (part of ISMB/ECCB 2023 in Lyon, France, and online) - CollaborationFest <https://www.open-bio.org/events/bosc-2023/obf-bosc-collaborationfest-2023/> (CoFest) – July 22-23 (Lyon, France, and online) Join our community! - BOSC announcements mailing list: <http://lists.open-bio.org/mailman/listinfo/bosc-announce> https://groups.google.com/forum/#!forum/bosc-announce - Slack: https://join.slack.com/t/obf-bosc/shared_invite/zt-n5ur1gsj-z2C~69_4lYTFPg5tbWA8Ew - Twitter: @OBF_BOSC <https://twitter.com/OBF_BOSC>, #BOSC2023 - Mastodon: https://genomic.social/@BOSC - Website: <https://www.open-bio.org/wiki/BOSC_2019> https://www.open-bio.org/events/bosc/ ------------------------------ We look forward to reading your abstract and seeing you (in person or virtually) at BOSC 2023! Sincerely, BOSC 2023 Organizing Committee (Nomi Harris, Karsten Hokamp, Hervé Ménager, Monica Munoz-Torres, Deepak Unni, Jason Williams, Chris Fields, Jessica Maia, Radhika Khetani) -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Project Manager (http://gmod.org/) 216-392-3087 WormBase Developer (http://wormbase.org/) Alliance of Genome Resources Group Leader (http://alliancegenome.org/) VirusSeq Project Manager (https://virusseq-dataportal.ca/) Human Cancer Models Initiative Project Manager ( https://hcmi-searchable-catalog.nci.nih.gov/) |
From: Joe C. <jwc...@lb...> - 2023-03-29 21:38:56
|
Well, today we broke the limit with a chromosome longer than 1 Gbase and I tried to insert it into a chado record. Yes, the postgresql text field is unlimited in length, but there is a max of 1 Gbyte in a string buffer that is used for operations. So I cannot populate that field. I’m curious if anyone else has run into this issue before and what they’ve done about it. It seems that the thing to do is to separate the residues field from the feature table and divide residues into hunks of a more manageable size. The next milestone is when we break the 2G limit and need to make fmin and fmax in the featureloc table bigints. That, however, will be an easier fix. Joe (by the way, there is some info on large chado tables here https://www.mcgeeandco.com/products/chado-large-table-lamp <https://www.mcgeeandco.com/products/chado-large-table-lamp>) |
From: Scott C. <sc...@sc...> - 2022-08-19 03:34:19
|
Hi Jie Jin, Sorry about that; when gmod.org gets hammered by web crawlers, sometimes mysql goes down and I have to manually restart it. It should be back now. Please let us know if you have any questions we can help you with! Scott On Thu, Aug 18, 2022 at 8:05 PM Jie Jin <hel...@gm...> wrote: > Hello, > > I am looking for documentation of Chado. I found > https://chado.readthedocs.io/, there many useful information on this > site. > > But there are still many useful links pointed to http://gmod.org/, and > http://gmod.org/ is down. > > Is the downtime of gmod.org temporally? Will it come back sometime? > > Where can I find the full documentation including the wiki on gmod.org? > > 谢谢 > 金杰 (Jie Jin) > > > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Project Manager (http://gmod.org/) 216-392-3087 WormBase Developer (http://wormbase.org/) Alliance of Genome Resources Group Leader (http://alliancegenome.org/) VirusSeq Project Manager (https://virusseq-dataportal.ca/) Human Cancer Models Initiative Project Manager ( https://hcmi-searchable-catalog.nci.nih.gov/) |
From: Jie J. <hel...@gm...> - 2022-08-15 14:32:48
|
Hello, I am looking for documentation of Chado. I found https://chado.readthedocs.io/, there many useful information on this site. But there are still many useful links pointed to http://gmod.org/, and http://gmod.org/ is down. Is the downtime of gmod.org temporally? Will it come back sometime? Where can I find the full documentation including the wiki on gmod.org? 谢谢 金杰 (Jie Jin) |
From: Scott C. <sc...@sc...> - 2022-03-23 04:53:56
|
BOSC 2022 dates: July 13-14, as part of ISMB 2022 Location: Madison, WI, USA, and virtual Website: <https://www.open-bio.org/wiki/BOSC_2019> https://www.open-bio.org/events/bosc/ BOSC announcements mailing list: <http://lists.open-bio.org/mailman/listinfo/bosc-announce> https://groups.google.com/forum/#!forum/bosc-announce Slack channel: https://join.slack.com/t/obf-bosc/shared_invite/zt-n5ur1gsj-z2C~69_4lYTFPg5tbWA8Ew Twitter: @OBF_BOSC <https://twitter.com/OBF_BOSC>, #BOSC2022 Key Dates - April 21, 2022: Deadline for submitting talk/poster abstracts <https://www.open-bio.org/events/bosc-2022/submit/> - May 12: Talk/poster acceptance notifications - May 19: Late poster (and Late-Breaking Lightning Talk) submission deadline - May 26: Late poster / LBLT acceptance notifications - July 13-14: BOSC 2022 <https://www.open-bio.org/events/bosc-2022/> - July 15-16: CollaborationFest (CoFest) About BOSC The Bioinformatics Open Source Conference promotes and facilitates the open source development of bioinformatics tools and open science. Since 2000, BOSC has provided a forum for developers and users to interact and share research results and ideas in open source bioinformatics and open science. BOSC’s broad spectrum of topics includes practical techniques for solving bioinformatics problems; software development practices; standards and ontologies; approaches that promote open science and sharing of data, results and software; and ways to grow open source communities while promoting diversity within them. As usual, BOSC will include keynote talks, longer and shorter (lightning) talks from submitted abstracts, posters, Birds of a Feather, and more! New this year: Joint session with Bio-Ontologies <https://www.open-bio.org/2022/03/03/bosc-and-bio-ontologies-joint-session/> ! We are excited to announce that BOSC and Bio-Ontologies <https://www.bio-ontologies.org.uk/ismb-annual-meeting> will join forces for part of a day at ISMB 2022. The joint session will feature keynote speaker Melissa Haendel as well as talks chosen from abstracts submitted to BOSC or Bio-Ontologies. Keynote Speakers <https://open-bio.org/events/bosc-2022/bosc-2022-keynotes> Melissa Haendel is the Chief Research Informatics Officer at University of Colorado Anschutz Medical Campus, and Director of the Center for Data to Health (CD2H). With expertise in molecular genetics and developmental biology as well as translational informatics, Dr. Haendel focuses on open science and data integration to improve rare-disease diagnosis and mechanism discovery. She is a leader in ontologies and standards for data sharing. Lior Pachter is the Bren professor of computational biology at Caltech. He is a Fellow of the International Society of Computational Biology <https://www.iscb.org/iscb-fellows> and has been awarded a National Science Foundation CAREER award, a Sloan Research Fellowship His research interests span the mathematical and biological sciences, including algorithms, combinatorics, comparative genomics, algebraic statistics, molecular biology and evolution. Dr. Pachter is known as a vociferous advocate of open and accountable science. A third keynote speaker will be announced soon! Abstract submission We encourage you to submit abstracts <https://www.open-bio.org/events/bosc-2022/submit/> (due April 21 – sorry, no extensions) on any topic relevant to open source bioinformatics or open science. After review, some abstracts will be selected for lightning talks, longer talks, or posters. Abstracts that are not chosen for talks will automatically be considered for posters. Abstract submission will be via ISMB’s EasyChair. Note that ISMB/ECCB requires a short (200-word) text-only abstract for all submissions (talk or poster), plus a “long abstract” (PDF, 2 pages max) if you want to be considered for a talk. A second, later round of submissions will end May 19. Abstracts submitted in the late round will be considered only for posters and a limited number of “late-breaking lightning talk” slots; they are not eligible for longer talks. Registration fee assistance We realize that the cost of ISMB may be prohibitive for some. If you are submitting an abstract to BOSC and would have difficulty covering the cost of registration, you can request a registration fee waiver right on the abstract submission form (which will not be seen by reviewers). Those who are not submitting abstracts can apply for an OBF Event Fellowship <https://www.open-bio.org/event-awards/> (deadline April 1, 2022). BOSC topics include (but are not limited to): - Ontologies: Open Source Tools and Approaches (new this year – joint session with Bio-Ontologies COSI <http://www.bio-ontologies.org.uk/>) - Open Science and Reproducible Research - Open Biomedical Data - Citizen/Participatory Science - Standards and Interoperability - Data Science - Workflows - Open Approaches to Translational Bioinformatics - Open Science for Global Health - Developer Tools and Libraries - Inclusion, Outreach and Training - Bioinformatics Open Source Project Reports (about new or existing projects) - Open and interoperable ontologies (joint session with Bio-Ontologies <https://www.open-bio.org/2022/03/03/bosc-and-bio-ontologies-joint-session/> ) We look forward to reading your abstract and seeing you (in person or virtually) at BOSC 2022! Sincerely, BOSC 2022 Organizing Committee: Nomi Harris, Karsten Hokamp, Hervé Ménager, Monica Munoz-Torres, Deepak Unni, Nicole Vasilevsky, Jason Williams -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Project Manager (http://gmod.org/) 216-392-3087 WormBase Developer (http://wormbase.org/) Alliance of Genome Resources Group Leader (http://alliancegenome.org/) VirusSeq Project Manager (https://virusseq-dataportal.ca/) |
From: Ficklin, S. P. <ste...@ws...> - 2022-01-19 01:41:20
|
Dear Tripal and GMOD Community, Every Monday, Tripal developers meet via GatherTown, similar to a mini codefest. Anyone is welcome. Sometimes we have an agenda and sometimes we don't, but we get together to chat about code for anything Tripal related. Folks who want help with their Tripal sites are also welcome to drop in. On the first Monday of every month, starting in February, we are going to focus on Chado issues that we have, including submitting and reviewing pull requests made to the Chado GitHub repository. Members of the broader GMOD community are welcome to join us. You can meet with us on GatherTown by joining the Tripal Slack workspace (https://tripal.info/join/slack) which has a #chado channel. On the Tripal Slack you can request the GatherTown link. Alternatively, email me directly and I will send the link to you. If you would like to be involved in these discussions, please join us! Stephen Ficklin Tripal PMC Member |
From: Scott C. <sc...@sc...> - 2021-08-31 20:02:14
|
Hello all, A few years ago, Valentin created an issue and pull request for a natural diversity fact table (nd_fact) for collecting data/facts (climate data, temperature, etc) about observed conditions associated with natural diversity collections. Currently, there is a nd_geolocation table for identifying where a collection occurred, the nd_fact table would expand the ability to describe the conditions around the collection. Since this seems like a good idea to me but the issue has been sitting idle for a while, I'd like to get some feedback on the change. This change is a sort of "medium sized" change, since it's really a new sort of table. If you have the inclination, please take a look at https://github.com/GMOD/Chado/issues/107 and let me know what you think. Thanks, Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Meg S. <me...@gm...> - 2021-08-20 00:40:21
|
Dear Researchers, Breeders, Database Providers, Funders, Editors, Students, Software Engineers, and other Scientists, *Do you want easy access to better quality data?* We are THRILLED to announce that AgBioData (https://www.agbiodata.org/) has received a three-year NSF RCN award to expand our community committed to improving quality and access to agricultural data. New activities will include organizing workshops, establishing new working groups, and developing FAIR curriculum for scientists. We are expanding the consortium and welcome new members, especially students, post-docs, big-data scientists, funding agency scientists and members of the scientific publishing community interested in solving common FAIR data issues. *We invite all of you to an important kickoff All-Hands Meeting on Sept 1st* at 10 am PDT (find your local time - https://bit.ly/389VeJA). At this meeting you will hear about our RCN objectives, the benefits of joining AgBioData, and how YOU can make a difference in the biological data environment for years to come. *Please pre-register* for this meeting at https://iastate.zoom.us/meeting/register/tJcld-iqqD4vE9awJKcFGnmHwxtCNc_a7UJM *We are also hiring a scientist to coordinate AgBioData activities*, outreach and curriculum development. Please help us publicize this opportunity! Applications should be submitted by August 31 to https://phoenix-bioinformatics.hirehive.com/job/83452/scientific-program-coordinator-newark?source=TAIR . Thank you! The AgBioData Steering Committee: Monica Poelchau, Sook Jung, Ethy Cannon, Jacqueline Campbell, Lisa Harper, Leonore Reiser, Marcela Tello-Ruiz, Laurel Cooper, Eva Hula, Meg Staton, and Darwin Campbell *About AgBioData:* https://www.agbiodata.org *AgBioData RCN*: https://www.nsf.gov/awardsearch/showAward?AWD_ID=2126334 -- Margaret Staton Associate Professor Department of Entomology and Plant Pathology Office: 154 PBB Mail: 370 PBB, 2505 EJ Chapman Drive Knoxville, TN 37996-4560 she/her/hers 864-506-4515 Mobile mst...@ut... *Advanced Out of Office Notice* *October 11-15, 2021* |
From: Scott C. <sc...@sc...> - 2021-07-27 21:01:52
|
Hi, Here's a reminder that "today" (that is, tomorrow morning for me) there is a Birds of a Feather meeting to discuss GMOD topics at ISMB/BOSC, including JBrowse but other GMOD topics as well. The BoF starts at 15:20 UTC (7:20 PDT, 10:20 EDT) on July 28. If you are attending ISMB, please feel free to drop in and chat about good stuff you're doing or want to do: https://ismbeccb2021.showcare.io/sessions/28-3-bof/ Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Scott C. <sc...@sc...> - 2021-07-21 17:46:31
|
Hello, If you are attending BOSC or any other ISCM meeting next week, please feel free to come to the GMOD/JBrowse Birds of a Feather on Wednesday, July 28 from 15:20 to 16:20 UTC (yes, that is 7:20 AM west coast US time). Several GMOD folks will be there; you can talk about new developments with JBrowse 2 or discuss any of several other GMOD components. https://www.iscb.org/ismbeccb2021-program/bof#bof4 The meeting will take place in the Research Exchange Forum, which hopefully will make sense when attending the meeting! :-) See you all next week! Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Scott C. <sc...@sc...> - 2021-05-04 21:15:50
|
Don't forget to get your abstracts in for BOSC! ---------- Forwarded message --------- From: BOSC, the Bioinformatics Open Source Conference < bos...@gm...> Date: Tue, May 4, 2021 at 1:50 PM Subject: [bosc-announce] Reminder: BOSC abstract deadline is May 6! To: <bos...@go...> <https://www.open-bio.org/events/bosc/> The BOSC 2021 abstract submission <https://www.open-bio.org/events/bosc-2021/submit/> deadline is May 6th; see our announcement <https://www.open-bio.org/2021/03/24/join-us-at-bosc-2021/> for more info. This year’s BOSC is a track of ISMB/ECCB 2021 online <https://www.iscb.org/ismbeccb2021/>. What time on May 6th is the deadline? The official ISMB/ECCB deadline is 11:59pm EDT on May 6 (which is 03:59 UTC on May 7), but we convinced them to let us keep submissions for BOSC open until 11:59pm Hawaii time (which is six hours later, 09:59 UTC on May 7). We are unfortunately unable to grant any additional extensions. Late Poster deadline is June 3. If you can’t make the May 6th submission deadline, we encourage you to submit for a Late Poster (deadline June 3). As space permits, we will choose a few Late Poster submissions for Late-Breaking Lightning Talks. Fee assistance. Just check a box on the abstract submission form to request registration fee assistance! Join us on Slack! Our BOSC Slack workspace <https://join.slack.com/t/obf-bosc/shared_invite/zt-n5ur1gsj-z2C~69_4lYTFPg5tbWA8Ew> is open to the community! Follow us on Twitter! @OBF_BOSC <http://twitter.com/OBF_BOSC>, #BOSC2021 -- You received this message because you are subscribed to the Google Groups "bosc-announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to bos...@go.... To view this discussion on the web visit https://groups.google.com/d/msgid/bosc-announce/CAK27n1fyqV9KP1pR%2BOdYh%3D5rW%2BGdah-KQPJajCUxMMKXgqADZQ%40mail.gmail.com <https://groups.google.com/d/msgid/bosc-announce/CAK27n1fyqV9KP1pR%2BOdYh%3D5rW%2BGdah-KQPJajCUxMMKXgqADZQ%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Ficklin, S. P. <ste...@ws...> - 2020-12-01 23:48:31
|
Dear Tripal, Chado and GMOD communities. We will be hosting our yearly Tripal Codefest (Hackathon) Jan 11-15. Due to Covid-19, the Codefest will be held virtually via GatherTown (https://gather.town/) . Anyone interested in Tripal development (core or extensions) is welcome to attend. We also welcome those interested in Chado development, those interested in Tripal integration or any other GMOD tools. Please register and learn more by visiting http://tripal.info/events/codefest_2021 [cid:578172fc-b79c-4a23-b83d-1605d4acc6a8] |
From: Menolin S. <sha...@gm...> - 2020-09-02 05:02:49
|
Hi, I had loaded some organisms into the chado database. I had assumed loading the organisms would automatically create an organism_dbxref table for the organisms entered. However, the organism_dbxref table is empty. How can I link organisms to dbxref_id? I need these ids in order to be able to enter the stock information. Thank you, Menolin |
From: Menolin S. <sha...@gm...> - 2020-08-27 22:32:33
|
Hi, I have questions regarding loading the chado modules: 1. Which modules have a prebuilt script for loading data onto the chado schema? (I could figure out scripts for loading ontologies and gff3 files only so far) 2. Do I need to write my own script for loading the phenotype and other modules? Thank you very much for your help. Thank you, Menolin |
From: Menolin S. <me...@ud...> - 2020-08-27 22:29:10
|
Hi, I have questions regarding loading the chado modules: 1. Which modules have a prebuilt script for loading data onto the chado schema? (I could figure out scripts for loading ontologies and gff3 files only so far) 2. Do I need to write my own script for loading the phenotype and other modules? Thank you very much for your help. Thank you, Menolin -- Menolin Sharma |
From: Scott C. <sc...@sc...> - 2020-07-01 17:32:59
|
Hi Lucas, Just to clarify, when you did your migration, are you talking about a database dump and then reload into a new version of postgresql? And what were the nature of the changes: I assume relationships were maintained, just that the primary keys themselves changed. Also, what was the nature of the breakage to your site? How were primary keys being used that resulted in the breakage? I'm pretty sure you can specify that primary keys be included in dumps and when reloading from a dump that the primary keys be either used or not, but I imagine there's a command line flag for that (I don't recall--I haven't done that sort of thing in a long time). Hopefully, there is a way to make this process work for you. Scott On Wed, Jul 1, 2020 at 10:17 AM Lucas Fioletti-Nieder < luc...@cr...> wrote: > Hello, > > We work on a huge database about the Ascidie. Our database is based on > Chado structure but when we done the last migration, every primary key > are changed and I don't understand why. > We meet difficulties because our website is not worked because we wrote > explicitly our primary key inside our code. > > Could you bring me light. > > Thanks for you request. > > Nieder-Fioletti Lucas. > CRBM-CNRS. > > > > _______________________________________________ > Gmod-schema mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-schema > -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Lucas Fioletti-N. <luc...@cr...> - 2020-07-01 10:38:16
|
Hello, We work on a huge database about the Ascidie. Our database is based on Chado structure but when we done the last migration, every primary key are changed and I don't understand why. We meet difficulties because our website is not worked because we wrote explicitly our primary key inside our code. Could you bring me light. Thanks for you request. Nieder-Fioletti Lucas. CRBM-CNRS. |
From: Scott C. <sc...@sc...> - 2020-06-26 01:46:44
|
Hi All, Sorry to disturb the crickets :-) This issue came up in the Chado github repo recently: https://github.com/GMOD/Chado/issues/114 Basically, the frange schema is a bit of a hassle to support. This schema houses the featuregroup table and these functions: groupoverlaps groupcontains groupinside groupidentical groupoverlaps _fill_featuregroup fill_featuregroup We are wondering if anybody uses this schema in any applications. We were thinking of moving it to the public schema (which would be a "large" change for Chado, requiring approval from 6 reviewers before it got accepted). Anybody? Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Scott C. <sc...@sc...> - 2020-02-21 02:16:32
|
Hello, I am very pleased to announce that GMOD in conjunction with Reactome, Galaxy and OICR/WormBase, together forming Open Genome Informatics, has been accepted for the Google Summer of Code. If you or someone you know might be a student interested in participating in GSoC, please take a look at http://gmod.org/wiki/GSOC_Project_Ideas_2020 where there are proposed projects that cover a fair number of technologies. Official proposals from students will be due in mid March (more on that later). But WAIT! There's more: if you might be interested in being a mentor and working with a student this summer, it's not too late! You can add new project ideas to the page above (contact me if you need an account), or you can even volunteer to add yourself to one of the existing ideas as a potential mentor. Please feel free to forward this to other mailing lists or people who might be interested. We are already an eclectic, dispersed group, so everyone is welcome. Thanks, Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research |
From: Andriamiharimamy R. <mir...@ya...> - 2020-02-13 08:56:16
|
Hi all, It seems like i can’t use chado gmod_bulk_load inside a bash script even. Can someone enlighten me on that ? Thank you for in advance Miharimamy > > I get the following when I execute this command : > > > > $ chado-1.31/load/bin/gmod_bulk_load_gff3.pl --organism "acinetobacter" --gfffile acinetobacter/GCF_000018445.1/GCF_000018445.1_ASM1844v1_genomic.gff.sorted –fastafile acinetobacter/GCF_000018445.1/GCF_000018445.1_ASM1844v1_genomic.fna --dbname chado --dbuser chadousr --dbpass <password> > > > > > > DBD::Pg::st fetchrow_array failed: no statement executing at /usr/local/share/perl5/Bio/GMOD/DB/Adapter.pm line 1209, <GEN0> line 2. > > "acinetobacter" organism not found in the database at /home/bee/chado-1.31/load/bin/gmod_bulk_load_gff3.pl line 749, <GEN0> line 2. > > > > Abnormal termination, trying to clean up... > > > > Trying to remove the run lock (so that --remove_lock won't be needed)... > > Exiting... > > > > The same command gives executed in my current shell gives me : > > > > Unable to find srcfeature NC_010611.1 in the database. > > Perhaps you need to rerun your data load with the '--recreate_cache' option. at /usr/local/share/perl5/Bio/GMOD/DB/Adapter.pm line 4605, <GEN0> line 2. > > Bio::GMOD::DB::Adapter::src_second_chance('Bio::GMOD::DB::Adapter=HASH(0x2a9b0f8)', 'Bio::SeqFeature::Annotated=HASH(0x2cfae70)') called at chado-1.31/load/bin/gmod_bulk_load_gff3.pl line 851 > > > > Abnormal termination, trying to clean up... > > > > Attempting to clean up the loader temp table (so that --recreate_cache > > won't be needed)... > > Trying to remove the run lock (so that --remove_lock won't be needed)... > > Exiting... |