artifact_id;status_id;status_name;priority;submitter_id;submitter_name;assigned_to_id;assigned_to_name;open_date;close_date;last_modified_date;summary;details;"Resolution";"Operating System";"Severity";"Hardware";"Version";"Component";"URL" 1273;2;"Closed";5;1713;"Yurii Aulchenko";100;"Nobody";"2011-02-07 09:41";"2011-02-08 16:27";"2011-02-08 16:27";"GenABEL 1.6-5 does not compile";"From Kurt Hornik > Dear Kurt, > I have uploaded updated GenABEL_1.6-5 on CRAN ftp. Hope it will pass > all checks well! Thanks. Actually, I get g++-4.4 -I/home/Hornik/tmp/R/include -I/usr/local/include -DCOMPILE_WITH_R -fpic -g -O2 -Wall -pedantic -c iterator.cpp -o iterator.o iterator.cpp: In function ‘SEXPREC* iteratorGA(SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, SEXPREC*, ...)’: iterator.cpp:249: error: ‘va_start’ was not declared in this scope iterator.cpp:251: error: expected primary-expression before ‘)’ token iterator.cpp:251: error: ‘va_arg’ was not declared in this scope iterator.cpp:253: error: ‘va_end’ was not declared in this scope make: *** [iterator.o] Error 1 Can u pls fix? Yurii: I was able to reproduce this error when using R CMD check GenABEL under SUSE. Seems this is a 'bug' we have dealt with in DatABEL (initial submission of 0.9-2) ";"Fixed";"None";"blocker";"None";"v1.6-5";"GenABEL";"" 1130;2;"Closed";5;5001;"Lennart Karssen";5001;"Lennart Karssen";"2010-10-13 13:53";"2013-05-20 01:38";"2013-05-20 01:38";"The Cox regression module of ProbABEL crashes";"In the latest versions of ProbABEL, the Cox regression module doesn't work and crashes. A typical command line (for the X chromosome in this case) like this: pacoxph-0.1-9b -p AFGEI_inc_bmi.PHE --ngpreds 1 -i /storage/imputations/ERGO_X-chromosome_2009/ERGO_X_imputed_probabel.mlinfo -d /storage/imputations/ERGO_X-chromosome_2009/ERGO_X_imputed_probabel.dose.fvi -m /storage/imputations/ERGO_X-chromosome_2009/ERGO_X_imputed_probabel.legend --chrom X Results in output like this (full output in the attached file): ======= Backtrace: ========= /lib64/libc.so.6[0x3b3427230f] /lib64/libc.so.6(cfree+0x4b)[0x3b3427276b] pacoxph-0.1-9b[0x4150d1] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3b3421d994] pacoxph-0.1-9b(__gxx_personality_v0+0xf9)[0x403329] ======= Memory map: ======== 00400000-00425000 r-xp 00000000 08:05 4977102 /usr/lo cal/bin/pacoxph-0.1-9b 00625000-00626000 rwxp 00025000 08:05 4977102 /usr/lo cal/bin/pacoxph-0.1-9b In ProbABEL <= 0.1-3 the Cox model is reported to work, but this version doesn't read files in filevector/DatABEL format. ";"Fixed";"Linux (64bit)";"major";"None";"None";"ProbABEL";"" 1889;2;"Closed";5;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-03-18 10:23";"2012-03-26 22:07";"2012-03-26 22:07";"Different results when running ProbABEL/palinear with mmscore on 32bit or 64bit Linux";"As pointed out in the following post on the mailing list: http://lists.r-forge.r-project.org/pipermail/genabel-devel/2012-March/000392.html, ProbABEL's palinear gives different results when running on a 32bit or a 64bit platform. This bug was found in ProbABEL 0.2.0-beta, but checks with older versions of ProbABEL show that it has been present also in earlier version. At first sight it seems to have something to do with using FileVector files as input and using the mmscore option, because the examples/example_mms.sh test script fails (on 64bit Linux, it passes on 32bit Linux). This was tested on Ubuntu 11.04 (64 and 32 bit) and Ubuntu 11.10 (64bit). Attached the output of the first test in the example_mms.sh script.";"Fixed";"Linux (64bit)";"critical";"All";"other";"ProbABEL";"" 1398;2;"Closed";5;1713;"Yurii Aulchenko";100;"Nobody";"2011-05-17 19:29";"2011-05-18 01:32";"2011-05-18 01:32";"GenABEL fails CRAN checks";"from PeterD: Dear maintainers of BMA GenABEL SNPassoc cherry. Your packages are currently failing the automatic CRAN checks under r-devel. This is due to a change in the labeling of columns in anova tables, which you have been using to extract p values. E.g. (from ""cherry"") anova(glm(form, data=birthwt, family=binomial), fullfit, test=""Chisq"")$""P(>|Chi|)""[2] does no longer work because the column is now labeled ""Pr(>Chi)"". Since you probably don't want to break compatibility with R 2.13.x, you can't just change the string. Instead, the straightforward workaround would seem to be t1 <- glm(form, data=birthwt, family=binomial), fullfit, test=""Chisq"") t2 <- t1$""P(>|Chi|)"" if (is.null(t2)) t2 <- t1$""Pr(>Chi)"" t2[2] Or, at some loss of readability: t1[2, grep(""^P.*Chi"",names(t1))] Apologies for the inconvenience, but please adjust your packages and resubmit to CRAN. ";"Fixed";"None";"blocker";"None";"None";"GenABEL";"" 1641;2;"Closed";4;17280;"Karl Forner";100;"Nobody";"2011-10-27 18:33";"2012-08-30 10:01";"2012-08-30 10:01";"regression bug with merge.snp.data in version 1.6.9";"The following code library(GenABEL) print( packageVersion(""GenABEL"") ) data(srdta) x1 <- gws[1:4,1] x2 <- gws[5:10, 2] xy <- merge(x1, x2, intersected_snps_only=FALSE) produces this ==> Error in !monos(coding(y)[which_snp_intersect_in_y]) : invalid argument type Error in merge.gwaa.data(x1, x2, intersected_snps_only = FALSE) : error occured in merging gtdata slots of x and y The problem occurs when there is no SNP in common, so that monos() returns NULL... Another maybe related issue: When I load the 1.6.9 version of GenABEL, I get the following message: >GenABEL v. 1.6-9 (August 30, 2011) loaded > I>nstalled GenABEL version (1.6-9) is not the same as stable >version available from CRAN (1.6-7). Unless used intentionally, >consider updating to the latest CRAN version. For that, use '>install.packages(""GenABEL"")', or ask your system administrator > to update the package. This lets me think that this package version is not considered as stable, so maybe should not be available from CRAN ? Best regards, Karl Forner ";"Fixed";"All";"major";"None";"v1.6-9";"GenABEL";"" 2672;2;"Closed";4;1713;"Yurii Aulchenko";100;"Nobody";"2013-04-09 09:18";"2013-04-09 17:41";"2013-04-09 17:41";"GenABEL::cocohet default graph output";"cocohet makes graphs using 'bitmap' by default - which is not compatible with the default R. This also leads to the fact that Mac OS X binaries are missing from CRAN.";"Fixed";"MacOS X";"critical";"None";"None";"GenABEL";"http://www.r-project.org/nosvn/R.check/r-release-macosx-x86_64/GenABEL-00check.html" 1676;2;"Closed";4;5001;"Lennart Karssen";100;"Nobody";"2011-11-30 14:54";"2012-04-03 13:15";"2012-04-03 13:15";"Regression in merge of gwaa.data, phenotypes don't get merged correctly";"Merging two gwaa.data objects does not merge the phenotypes correctly. This used to work fine (prior to approximately v1.6-7). What happens is that instead of merging phenotype columns that are identical, separate columns are created, e.g. sex.x and sex.y A minimal example (with some superfluous output removed): > library(GenABEL) > data(srdta) > x1 <- srdta[1:4,1] > x2 <- srdta[5:10, 2] > xy <- merge(x1,x2) There are not intersected SNPs ...merging finished... > x1@phdata id sex age qt1 qt2 qt3 bt 1 p1 1 43.4 -0.58 4.46 1.43 0 2 p2 1 48.2 0.80 6.32 3.90 1 3 p3 0 37.9 -0.52 3.26 5.05 1 4 p4 1 53.8 -1.55 888.00 3.76 1 > x2@phdata id sex age qt1 qt2 qt3 bt 5 p5 1 47.5 0.25 5.70 2.89 1 6 p6 0 45.0 0.15 4.65 1.87 0 7 p7 0 52.0 -0.56 4.64 2.49 0 8 p8 1 42.5 NA 5.77 2.68 1 9 p9 0 29.7 -2.26 0.71 1.45 0 10 p10 0 45.8 -1.32 3.26 0.85 0 > xy@phdata id sex.x age.x qt1.x qt2.x qt3.x bt.x sex.y age.y qt1.y qt2.y qt3.y bt.y p1 p1 1 43.4 -0.58 4.46 1.43 0 NA NA NA NA NA NA p2 p2 1 48.2 0.80 6.32 3.90 1 NA NA NA NA NA NA p3 p3 0 37.9 -0.52 3.26 5.05 1 NA NA NA NA NA NA p4 p4 1 53.8 -1.55 888.00 3.76 1 NA NA NA NA NA NA p5 p5 NA NA NA NA NA NA 1 47.5 0.25 5.70 2.89 1 p6 p6 NA NA NA NA NA NA 0 45.0 0.15 4.65 1.87 0 p7 p7 NA NA NA NA NA NA 0 52.0 -0.56 4.64 2.49 0 p8 p8 NA NA NA NA NA NA 1 42.5 NA 5.77 2.68 1 p9 p9 NA NA NA NA NA NA 0 29.7 -2.26 0.71 1.45 0 p10 p10 NA NA NA NA NA NA 0 45.8 -1.32 3.26 0.85 0 This is probably linked to bug #1641 as well. Related forum posts: - http://forum.genabel.org/viewtopic.php?f=6&t=467&start=0 - http://forum.genabel.org/viewtopic.php?f=6&t=557&p=931";"Fixed";"All";"critical";"None";"v1.6-9";"GenABEL";"" 5726;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2014-05-26 15:43";"2014-10-28 09:48";"2014-10-28 09:48";"ProbABEL Cox regression gives (too) many NaNs, does not match with R output";"The URL associated with this report points to the forum discussion. Aside from the people in the forum discussion I also got a report via e-mail about the same bug. Comparing CoxPH regression output between R and pacoxph gives different results for many (all?) SNPs. pacoxph gives nan for those SNPs, whereas R does give output. The reports are inconclusive about whether this behaviour is present in v0.4.3 only or also in v0.4.2. In v0.4.2 I implemented additional convergence checks in the estimate() function of pacoxph, based on the way R checks the output. As user wuttke points out in the forum I made a mistake there. R's survival package checks each component in the regression coefficients (beta vector) for anomalies. I misread R's code when implementing the checks. Maybe this is the cause of the problems... ";"Fixed";"All";"major";"All";"PA v0.4.3";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=10&t=866" 4700;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-06-29 23:53";"2013-06-30 00:01";"2013-06-30 00:01";"Output header of 2df files has wrong order of beta and se_beta";"When running the 2df model the output header has the following beta and se_beta information: beta_SNP_A1A2 beta_SNP_A1A1 sebeta_SNP_A1A2 sebeta_SNP_A1A1 However, it turns out when looking at the numbers the order should be: beta_SNP_A1A2 sebeta_SNP_A1A2 beta_SNP_A1A1 sebeta_SNP_A1A1 (which makes more sense anyway). Thanks to Anne G. and Yurii for noticing this bug and pointing out the possible solution. ";"Fixed";"All";"major";"All";"PA v0.3.0";"ProbABEL";"" 2055;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-06-11 09:00";"2013-05-30 13:49";"2013-05-30 13:49";"export.plink() uses too much memory (up to the point where a system can hang)";"Converting a GenABEL object to plink format using export.plink() from GenABEL v 1.7-0 nearly brings the computer to a halt because it used all available memory (RAM + swap), even on a machine with 128GB RAM. Our GenABEL object contained almost 3700 individuals and about 700k SNPS. This was recently independently confirmed with a 1k individuals and 3.6M SNPs. Even when when trying to export 10 or a 100 individuals at a time. Trying to run 1 individual at a time: RAM-usage has been increasing steadily with just under 1GB/individual, which would indicate to me that there could be an issue with memory leakage? ";"Fixed";"All";"normal";"All";"v1.7-0";"GenABEL";"https://lists.r-forge.r-project.org/pipermail/genabel-devel/2011-December/000384.html" 2418;2;"Closed";4;1713;"Yurii Aulchenko";5001;"Lennart Karssen";"2012-12-03 21:46";"2013-08-26 15:56";"2013-08-26 15:56";"impute2databel does not work in C++ mode";"To reproduce the error, run RUnit test GenABEL/inst/unitTestsrunit.impute2xxx.R This problem can be 'fixed' if instead of GA's ITERlib the ITERlib of DA is used (but in this case other functions stop working). ";"Fixed";"All";"major";"All";"v1.7-6";"GenABEL";"" 1280;2;"Closed";4;1713;"Yurii Aulchenko";100;"Nobody";"2011-02-10 21:31";"2011-03-31 02:03";"2011-03-31 02:03";"memory leak in MixABEL FastMixedModel";"Thanks to Gulya and Nadya: apparently there is a memory leak in FastMixedModel code, basically after a number of runs with FastMixedModel, a lot of RAM is used. Attach original message from Nadya here (sorry, it is in Russian) Posylayu izmenennyj script, tam teper' net FMM. Bez nego cikly idut na < 1Gb operativnoj pamyati, a s FMM zadacha zabiraet vse bol'she pamyati s kazhdym ciklom poka ne veshaet mashinu. Pri etom odin cikl s FMM idet na < 3Gb (ne otdaet operativku?)";"Fixed";"None";"critical";"None";"None";"MixABEL";"" 1281;1;"Open";4;1713;"Yurii Aulchenko";100;"Nobody";"2011-02-10 22:07";"";"2011-02-10 22:07";"MixABEL iterator issue";"RUnit test fails: Executing test function test.iterator_qtscore ... *** caught segfault *** address 0x5be4920, cause 'memory not mapped' ";"None";"None";"major";"None";"None";"MixABEL";"" 1187;1;"Open";4;1713;"Yurii Aulchenko";100;"Nobody";"2010-10-23 00:01";"";"2014-10-30 13:50";"flip bug?";"I have 4 data sets and in 3 of them the effective allele is C, and strand is -. In one of them the effallele is G and strand +. This C/- should correspond to G/+, right? At least the effective allele frequency is about the same. So the betas should be comparable as they are? In the metABEL results, however, the effallele is C, strand is -, and the beta of the fourth data set has been flipped into -0.20 (it was 0.20 before the meta-analysis)...? Am I misunderstanding something, or is there a bug in the metABEL? I'm using Version: 0.0-3, Date: 2008-09-21 (The example data can be created in R using the attached script. I also included the output there.) Many thanks, Kati";"Accepted As Bug";"None";"major";"None";"None";"MetABEL";"" 2664;1;"Open";4;13427;"Daniel Taliun";5001;"Lennart Karssen";"2013-04-04 17:35";"";"2015-07-30 07:35";"export.merlin produces incorrect ped files.";"GenABEL v. 1.7-4 (February 22, 2013) When exporting a subset of individuals from gwaa.data with export.merlin, the genotypes in ped files are incorrect. Additionally, ped files produced by analogous commands export.merlin(df[ids, snps], datafile=data_file_name, pedfile=ped_file_name, mapfile=map_file_name, order=T, fixstrand=""+"", stepids=1) and export.merlin(df[ids, snps], datafile=data_file_name, pedfile=ped_file_name, mapfile=map_file_name, order=T, fixstrand=""+"", stepids=100) are not identical. When stepids=1, the ped file seems to be correct. This behavior is observed only with subset of ids. When gwaa.data is exported completely, the everything is ok.";"Accepted As Bug";"Linux (64bit)";"major";"All";"v1.8-0";"GenABEL";"" 2295;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-10-03 22:32";"2012-10-08 00:20";"2012-10-08 00:20";"ProbABEL: The inverse var-covar matrix contains (incorrect) zeroes when people have missing data";"Maarten Kooyman reported that in his ProbABEL-refactoring branch the inverse variance-covariance matrix (used when --mmscore is given) is not correctly subset when missing genotype data is present. The matrix contains n rows and columns of zeros at the edges, where n is the number of NA values for a given id. This shows up by printing the invvarmatrix in line 380 of src/reg1.h and is also present in ProbABEL trunk. This may also be related to bug #1889, which dealt with the same part of the code. The attached out2 file shows the output for a small dose file with 10 ids. ";"Fixed";"All";"major";"All";"PA v0.2.0";"ProbABEL";"" 2525;2;"Closed";4;1713;"Yurii Aulchenko";100;"Nobody";"2013-02-02 10:14";"2013-04-04 13:44";"2013-04-04 13:44";"export.merlin not identical with old/new parameter";"Originally the problem was reported at http://forum.genabel.org/viewtopic.php?f=6&t=743 The following test shows that using option dpieceFun= old/new produces different resuts: in R, run library(GenABEL) data(srdta) export.merlin(srdta[,1:2],dpieceFun=""new"") export.merlin(srdta[,1:2],dpieceFun=""old"",mapfile=""me.map"",pedfile=""me.ped"",datafile=""me.dat"") then diff merlin.ped me.ped shows problems with sex coding (and this starts from 100+ id!)";"Fixed";"None";"major";"None";"None";"GenABEL";"" 2436;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-12-13 16:54";"2012-12-13 18:12";"2012-12-13 18:12";"probabel.pl doesn't overwrite output file (as it used to do before 0.2.2). ";"The probabel.pl script doesn't overwrite the output file anymore, even though it used to do so before v0.2.2 (i.e. before the changes that allowed the use of chunked input files). ";"Fixed";"All";"major";"All";"PA v0.2.2";"ProbABEL";"" 1388;2;"Closed";4;1713;"Yurii Aulchenko";100;"Nobody";"2011-05-13 10:09";"2011-05-13 13:10";"2011-05-13 13:10";"convert.snp.ped does not work";"Reported by Marcin Kierczak: It seems that calling convert.snp.ped on OsX, GenABEL 1.6.6 rises the following errors: 1. ""Error: segfault from C stack overflow"" or even ""R quit unexpectedly"". (32 bit version) R 64 either 1. *** caught segfault *** Traceback: 1: .C(""convert_snp_merlin"", as.character(pedfile), as.character(mapfile), as.character(outfile), as.integer(intstrand), as.integer(bcast), as.character(alcodes), as.integer(length(alcodes)), as.integer(intfmt), as.integer(traits), as.integer(mapHasHeaderLine), PACKAGE = ""GenABEL"") 2: convert.snp.ped(""Sw_ej_opheno.ped"", ""Sw_ej_opheno.map"", ""Sw.raw"") or 2. invalid permissions and than segfault When I modified permissions to 777, still segfault. When downgraded to 1.6.5 - everything went smooth! Marcin";"Fixed";"None";"major";"None";"v1.6-6";"GenABEL";"" 1430;2;"Closed";4;5001;"Lennart Karssen";100;"Nobody";"2011-06-14 15:01";"2011-07-06 11:46";"2011-07-06 11:46";"MixABEL 0.0-9 as distributed on the GenABEL web site doesn't compile, needs header file";"In forum post http://forum.genabel.org/viewtopic.php?f=6&t=487&p=697 it was pointed out that the MixABEL-0.0-9.tar.gz source as distributed on www.genabel.org doesn't compile (when installing from R). The error message is: dautil.cpp: In function ‘void error_R(const char*, ...)’: dautil.cpp:17: error: ‘va_start’ was not declared in this scope dautil.cpp:19: error: ‘va_end’ was not declared in this scope make: *** [dautil.o] Error 1 This can be fixed by including #include in src/dautil.cpp of the tar.gz file. I haven't yet looked into how this change needs to be applied to SVN HEAD. ";"Fixed";"All";"blocker";"All";"None";"MixABEL";"" 1158;2;"Closed";4;1713;"Yurii Aulchenko";2402;"Stepan Yakovenko";"2010-10-16 22:58";"2010-12-03 13:42";"2010-12-03 13:42";"Request from prof. Ripley";"You have void error_R (const char * format, ... ) { va_list args; char buffer[256]; va_start(args, format); vsprintf(buffer, format, args); va_end(args); Rprintf(""ERROR in Rstaff: %s"",buffer); } but you have not included a header which defines va_list etc, and indeed as they are not part of C++ there might be none. You will probably get away with including the C header stdarg.h, but it would be far better to write C in C, that is include this in a separate C file. (Since R assumes a C99 compiler, we know they are valid in C.) (In previous versions of R stdarg.h was included via long chain of inclusions, but you should never rely on such accidents.) Note that frerror.h includes both cstdarg and stdarg.h: that is not valid and the effect is very system-specific. Can we have a corrected update for CRAN please. Note that there are other errors shown at http://cran.r-project.org/web/checks/check_results_DatABEL.html, the one shown on Windows and Mac being using a non-unique filename and not cleaning up, and those on Solaris being further C++ errors. Brian Ripley";"Fixed";"None";"major";"None";"None";"DatABEL";"" 6041;2;"Closed";4;5001;"Lennart Karssen";5001;"Lennart Karssen";"2015-03-06 11:50";"2015-03-17 14:55";"2015-03-17 14:55";"ProbABEL's Cox module reports too many errors (beta may be infinite, setting beta and se to 'NaN')";"Reported via e-mail by Anne G.: ------------------------------------------------------------------------------------------------------------------------------------------ When using a constant covariate (=0) to the model (see bug #1266), I get the error message X matrix deemed to be singular, setting beta and se to 'NaN' for all SNPs, sometimes with an additional message beta may be infinite, setting beta and se to 'NaN' nr of iterations > MAXITER (20): 20 Cox regression ran out of iterations and did not converge, setting beta and se to 'NaN' Consequently, all parameter estimations (beta, SE, chi^2) are nan for all SNPs. When adding a non-constant covariate to the model (e.g. sex), I do get estimates, but I still get X matrix deemed to be singular, setting beta and se to 'NaN' Beta may be infinite, setting beta and se to 'NaN' for many SNPs. In this last case I do get parameter estimates for the SNPs with error messages, but those are usually marked by huge confidence intervals or unrealistic beta's. This is mostly for low-MAF SNPs. ------------------------------------------------------------------------------------------------------------------------------------------ This seems to be too many errors. We should double check the error detection with the R code in the survival package.";"Fixed";"All";"major";"All";"PA v0.4.4";"ProbABEL";"" 6280;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2016-01-11 21:23";"2016-01-12 10:01";"2016-01-12 10:01";"The convert.snp.affymetrix() function uses a system(""ls"") call, which doesn't work on MS Windows";"See the URL for a thread on the forum describing the bug. We can probably simply use R's list.files() function to get the same output. Thanks to forum user JRecoq for finding and reporting this bug.";"Fixed";"Windows 7";"normal";"All";"v1.8-0";"GenABEL";"http://forum.genabel.org/viewtopic.php?f=6&t=992" 1210;1;"Open";3;1713;"Yurii Aulchenko";100;"Nobody";"2010-11-17 11:00";"";"2011-02-07 09:45";"intermediate inbreeding checks with check.marker";"Apparently 'intermediate inbreeding' checks lead to TOO many samples dropped; need to cf PLINK and decide which threshold / test procedure to use See eg request from Ross Fraser: The issue concerns the QC process, specifically the sex check for intermediate inbreeding. For example, with our ORCADES isolate metabochip dataset, 409 of 894 people are excluded for this reason. In our other metabochip dataset, from the Edinburgh Artery Study, 15 of 733 are excluded. I've talked to Veronique Vitart at the MRC HGU about the issue, and she mentioned that previous versions of GenABEL (ie <1.4.x) do not exhibit this behaviour. I wonder if it has to do with the introduction of checks for intermediate X-chromosome inbreeding since 1.4.9? Only around 100 of 200k metabochip SNPs are on the X chromosome. ";"None";"All";"normal";"All";"v1.6-4";"GenABEL";"" 1211;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2010-11-17 22:53";"2013-01-08 21:51";"2013-01-08 21:51";"ProbABEL doesn't accept IDs containing a dash (-)";"As reported on the devel mailing list by Lorna Lopez: ""The only difference that I can see between my files that are working and those that aren't is the presence of a ""-"" in the id number."" The error message was: "".phenofile and dosefile did not match at line 4 (\ufffdB != 330-D003)"" Removing the dashes from the IDs solved the issue.";"Fixed";"All";"minor";"All";"None";"ProbABEL";"" 1227;2;"Closed";3;5001;"Lennart Karssen";100;"Nobody";"2010-12-07 11:35";"2011-02-08 16:26";"2011-02-08 16:26";"Problems in NAMESPACE files (according to e-mail of Duncan Murdoch)";"According to the e-mail of Duncan Murdoch the Namespace file of GenABEL contains one or more typo's. > > Yesterday a bug in R NAMESPACE processing was discovered that > affects one of your packages. (The full list of packages that are > known to be affected is shown below.) The bug was that typos in > NAMESPACE files were not reported; those lines were just ignored. > As a package writer, you would not have been told that one or more > of the lines in your package NAMESPACE was ignored, you would just > see strange behaviour. > > As of today, the patched version of R 2.12.0 will give a warning > when it detects one of these errors, and R-devel (to become R 2.13.0 > next spring) treats them as errors. They are generally easy to > fix: just find the error, and correct your NAMESPACE file to follow > the instructions in the Writing R Extensions manual. > > Most of the errors are simple typos in the spelling of directives. > For example, since R is case-sensitive, small differences (e.g. > ""S3Method"") will not be recognized. Here is the list of correctly > spelled directives that will be recognized in a NAMESPACE file: > > ""export"" ""exportPattern"" ""exportClassPattern"" > ""exportClass"" ""exportClasses"" ""exportMethods"" > ""import"" ""importFrom"" ""importClassFrom"" > ""importClassesFrom"" ""importMethodsFrom"" ""useDynLib"" > ""S3method"" > > A few other directives that look like R code will be recognized > (e.g. conditional directives using ""if""), but general R code is not > allowed in the NAMESPACE file. > ";"Fixed";"None";"normal";"All";"None";"GenABEL";"" 1266;2;"Closed";3;1713;"Yurii Aulchenko";5001;"Lennart Karssen";"2011-02-03 14:04";"2015-03-17 14:55";"2015-03-17 14:56";"pacoxph with no covariates";"From Aron Joon: We tried to run Cox models using pacoxph An error message will come up as ""nc <=0"" when I tried to model ""phenotype : SNPs"" (ie, no covariate). Is there a trick how to fix this? I added a constant dummy (covariate) variable (all values = 1) in order to get ProbABEL run smoothly ";"Fixed";"All";"minor";"All";"None";"ProbABEL";"" 1275;2;"Closed";3;1713;"Yurii Aulchenko";100;"Nobody";"2011-02-08 16:24";"2011-05-16 00:11";"2011-05-16 00:11";"Replace MGA as backup version keeper";"Now version is kept at (see zzz.R of GenABEL, DatABEL, ...?) address <- c( ""http://genabel.r-forge.r-project.org/version_and_news.html"", ""http://mga.bionet.nsc.ru/~yurii/ABEL/version_and_news.html"" ) should be address <- c( AMAZON, ""http://genabel.r-forge.r-project.org/version_and_news.html"" ) ";"Fixed";"None";"enhancement";"None";"None";"None";"" 1287;2;"Closed";3;1713;"Yurii Aulchenko";100;"Nobody";"2011-02-16 23:40";"2013-04-03 17:13";"2013-04-03 17:13";"ibs() example";"from Nadya: http://forum.genabel.org/posting.php?mode=reply&f=6&t=16#pr48";"Fixed";"None";"trivial";"None";"None";"GenABEL";"" 1339;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2011-03-27 11:36";"2011-04-01 14:58";"2013-05-14 18:44";"ProbABEL does not compile because of missing frerror.* files";"See http://forum.genabel.org/viewtopic.php?t=363&f=6 for discussion. Compiling ProbABEL (both svn rev. 701 and the tar-ball on www.genabel.org) does not work, make complains of missing the file src/fvlib/frerror.h. Checking the svn log messages, this file (and frerror.cpp) were last changed in r311, and were deleted in r599. The log message for that revision states: ""removing vararg since C++ doesn't support it on some platforms"" and shows that the inclusion of frerror.h is removed in several files. However, in src/data.h frerror.h is still included and several calls to the function error() are also still in place. As a workaround the frerror.{h,cpp} files can be copied from sv r311. A better solution is of course to remove/change the calls to error() in src/data.h. ";"Fixed";"All";"major";"All";"None";"ProbABEL";"" 1432;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2011-06-21 17:38";"2011-08-22 10:33";"2011-08-22 10:33";"convert.snp.tped() uses ""+"" as default option for 'strand', using ""u"" would be more appropriate";"According to the documentation, the GenABEL function convert.snp.tped() uses ""+"" as the default for its strand option. Using ""u"" (for unknown) seems more reasonable. If a person does not specify the strand, GenABEL shouldn't assume it is the + strand. Furthermore, convert.snp.ped() does have ""u"" as default (according to the documentation).";"Fixed";"All";"normal";"None";"v1.6-7";"GenABEL";"" 1527;1;"Open";3;5001;"Lennart Karssen";100;"Nobody";"2011-08-16 22:17";"";"2013-08-29 23:31";"GenABEL tutorial refers to Rdata files that are not part of the GenABEL package";"In chapter 3 the GenABEL tutorial refers to the data sets ge03d1p1.Rdata and ge03d1p2.Rdata, but these don't exit in the GenABEL package. Proposed solution: Either the data sets should be uploaded to SVN, or the tutorial should be updated to reflect the current names of the data sets. ";"Accepted As Bug";"All";"normal";"None";"other";"GenABEL";"http://forum.genabel.org/viewtopic.php?f=6&t=514" 1673;2;"Closed";3;13427;"Daniel Taliun";100;"Nobody";"2011-11-28 15:20";"2012-04-03 13:14";"2012-04-03 13:14";"Bug in load.gwaa.data and export.merlin when sorting is enabled.";"Function maxch <- max(chnumU,na.rm=T) in chrom.char2num (in sortmap.internal) thows warning: In max(chnumU, na.rm = T) : no non-missing arguments to max; returning -Inf This happens when the genofile contains only non-numeric chromosomes (e.g. ""X"", ""Y"") and sorting is enabled. The bug is critical, since the non-numeric names of all different chromosomes are replaced with -Inf and, therefore, sorting will give wrong results. The function is called in load.gwaa.data and export.merlin. ";"Fixed";"All";"critical";"None";"None";"GenABEL";"" 1817;1;"Open";3;19912;"Benedikt Haug";100;"Nobody";"2012-02-13 16:48";"";"2013-06-07 09:41";"problem when adding snp-subset to existing manhattanplot with add.plot(snp.subset(), ... )";"Setup: 1) I generate a full data (=whole genome) Manhattan plot 2) I want to add a snp subset in another color to the existing plot to highlight certain SNPs/areas, using add.plot(snp.subset(x,subset), col=...) 3) Result: added points appear as desired on chromosome 1, aligning perfectly with existing points. However, added points do not match on other chromosomes (option delta was set to an equal value in both, plot() and add.plot() ). Interestingly, the points perfectly align when datasets of same sizes are utilised. (Plotting full data over full data, plotting subset over subset). Another observation is, that if the subset does not contain SNPs from Chromosome 1, other SNPs are plotted on chromosome one. Help needed, since this would be an extremely handy way to highlight candidate genes/regions in a Manhattanplot and therefore to provide a very intuitive way to access analysis results! Cheers, Ben.";"Awaiting Response";"All";"normal";"All";"v1.7-0";"GenABEL";"" 1846;2;"Closed";3;20131;"Anne Grotenhuis";5001;"Lennart Karssen";"2012-02-23 18:03";"2012-06-11 09:05";"2012-06-11 09:05";"Bug in pacoxph functionality of ProbABEL version 0.1-3";"Dear all, I noticed a bug in the ProbABEL pacoxph functionality. I used ProbABEL version 0.1-3, as I already know that there are problems with the pacoxph functionality in later versions of ProbABEL (that use filevector format). The additive Cox regression model results are different when comparing a run using the example .mlprob (test.mlprob) file to an otherwise identical run using a dose file recreated from the mlprob file (dosage_A = 2 * p_AA + p_AB). (The dose file was (re)created, because the example dose file (test.mldose) does not match the example prob file (test.mlprob).) In more detail: For the test run, the dosage file (probabel.mldose) was generated from the example file ""test.mlprob"" by the following script: awk '{ printf ""%s MLDOSE"", $1; for (i=3; i <= NF; i += 2) printf "" %s"", (2*$i + $(i+1)); printf ""\n""}' test.mlprob A run with pacoxph using ""--dose test.mlprob --ngpreds 2"" gives different results than ""--dose probabel.mldose --ngpreds 1"" (both using the same example mlinfo and phenotype data). I have the feeling that the bug is specific for using mlprob input format to pacoxph, as the Cox regression results of ProbABEL based on mldose input seem comparable to effect estimates/significance obtained based on Cox regression analysis in SPSS (where results based on mlprob file input show a large discrepancy with SPSS results) I would really appreciate it if someone could look into this to narrow down the problem and hopefully fix it. Kind regards, Anne ";"Accepted As Bug";"Linux (32bit)";"major";"None";"PA v0.1-3";"ProbABEL";"" 1890;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-03-18 12:36";"2012-10-04 02:02";"2012-10-04 02:02";"ProbABEL (palinear/palogist) leaks small amounts of memory";"Running palinear with valgrind shows memory leaks. For example: valgrind --tool=memcheck --leak-check=yes ../src/palinear -p mmscore_pheno.PHE -i mmscore_gen.mlinfo -d mmscore_gen.mldose --sep="","" -o mmscore --mmscore mmscore_InvSigma_aj.sex.age.dat > output 2> valgrindoutput produces the attached output. The last lines of that output are: ==29930== LEAK SUMMARY: ==29930== definitely lost: 10,312 bytes in 18 blocks ==29930== indirectly lost: 16,033 bytes in 503 blocks ==29930== possibly lost: 1,000,000 bytes in 1 blocks ==29930== still reachable: 0 bytes in 0 blocks ==29930== suppressed: 0 bytes in 0 blocks ==29930== ==29930== For counts of detected and suppressed errors, rerun with: -v ==29930== Use --track-origins=yes to see where uninitialised values come from ==29930== ERROR SUMMARY: 872 errors from 147 contexts (suppressed: 4 from 4) ";"Fixed";"All";"normal";"All";"PA v0.2.0-beta";"ProbABEL";"" 2147;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2012-07-13 17:01";"2012-10-04 01:03";"2012-10-04 01:03";"ProbABEL output has 'nan' when values in info file are zero";"In the ProbABEL manual we write that the actual values in the info file are not important and that they are simply copied to the output. It turns out that if the values are 0 the beta and se_beta columns (and loglik as well) are set to 'nan'. This is described in more detail on the forum: http://forum.genabel.org/viewtopic.php?f=10&t=663 Thanks to forum member vforgetta for pointing this out!";"Fixed";"All";"minor";"All";"PA v0.2.0";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=10&t=663" 2173;2;"Closed";3;20840;"Maarten Kooyman";100;"Nobody";"2012-08-06 10:37";"2012-08-06 14:18";"2012-08-06 14:18";"Invalid email adres of Yurri in documentation";"The reference manual of datABEL contains a e-mail address of Yurri that does not function. . User can now not contact the author and might think the project is dead(in combination with a broken website). This might be the case in more documentation. ";"Fixed";"All";"major";"None";"None";"DatABEL";"http://cran.r-project.org/web/packages/DatABEL/DatABEL.pdf" 2174;2;"Closed";3;20840;"Maarten Kooyman";5001;"Lennart Karssen";"2012-08-06 10:42";"2015-03-30 17:38";"2015-03-30 17:38";"windows 7 64bit gives warning it is a 32 bit system";"see snippet. I verified it was a windows7 64bit OS . Platform: x86_64-pc-mingw32/x64 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > library(DatABEL) DatABEL v. 0.9-2 (October 17, 2010) loaded YOU APPEAR TO WORK ON 32-BIT SYSTEM. LARGE FILES ARE NOT SUPPORTED. > ";"Fixed";"Windows 7";"normal";"None";"other";"DatABEL";"" 2279;1;"Open";3;1713;"Yurii Aulchenko";100;"Nobody";"2012-09-17 13:09";"";"2012-09-17 13:09";"GC_ovdom example";"in the example provided for the GC_ovdom function the code result=GC_ovdom(p=freq,method = ""median"",data=chi2.1df,n=nids(ge03d2)) (now commented out) produces error message Error in nlm(GC_VIF_nlm, c(F = F1, K = K1)) : missing value in parameter ";"None";"None";"None";"None";"None";"GenABEL";"" 5118;1;"Open";3;244085;"Ge Zhang";100;"Nobody";"2013-11-19 22:00";"";"2014-03-03 13:05";"Number of genotypes is limited to (2^31-1)/4";"The current GenABEL can only handle (2^31-1)*4 genotypes, corresponding approximately less than 4.3 million SNPs in 2,000 samples. The problem is caused by the upper limit of vector length 2^31-1 in R/GenABEL. A lot of functions in GenABEL are influenced by this limitation. The development team might consider to fix this problem since most machines are running 64-bit systems and R started supporting long vectors since version 3.0.";"None";"All";"major";"All";"v1.7-6";"GenABEL";"" 5119;1;"Open";3;1754;"Maksim Struchalin";100;"Nobody";"2013-11-20 09:27";"";"2013-11-20 09:27";"export_plink.cpp:116:57: warning: index of massive has type ""char"" [-Wchar-subscripts]";"The 116 line export_plink.cpp contains a weird thing: the element of massive is addresed by a variable with ""char"" type. The line 116 in the fuction export_plink: fileWoA << "" "" << Genotype[gtMatrix[i][csnp]] Here is: 1) std::string* Genotype = new (std::nothrow) std::string [4]; 2) char **gtMatrix = new (std::nothrow) char*[nids]; for (int i=0; i 4GB on windows are problematic";"Reported by C. Sikorska in a presentation: using DatABEL on Windows with files > 4GB is problematic. I am not sure what the exect problem is. Maybe related to FAT32 (which has a 4GB limit on file size)? I verified that this is not an issue on Linux (x86_64). ";"Accepted As Bug";"Windows 7";"normal";"All";"None";"DatABEL";"" 5658;2;"Closed";3;5001;"Lennart Karssen";20840;"Maarten Kooyman";"2014-04-28 00:46";"2014-05-16 12:58";"2014-05-16 12:58";"Missing genetic data cannot be coded as NA or N as mentioned in the manual";"Thanks to user jal on the forum for reporting this bug. From his post: There are missing genotypes in my dosage file, while missing values were coded as ""NA"". My palogist run is aborted with error message: Reading genotype data... No digits were found while reading genetic data (individual 5, position 1) where ""individual 5, position 1"" is the location where the first missing value ""NA"" appears. The ProbABEL manual says missing value can be coded as ""NA"", ""NaN"" or ""N"", but seems ""NA"" and ""N"" do not work in my case. We use the standard C function strtod() to convert the genetic data from text to numbers. I did a quick check and strtod() only accepts ""NaN"", ""NAN"", ""nan"", no ""NA"" or ""N"". My guess is that the 'nan' variations are the only ones defined for floating point numbers (IEEE 754). We should decided whether we want to change the manual or change to code. Changning the manual has my preference, because changing the code would make reading data slower. ";"Accepted As Bug";"All";"normal";"All";"PA v0.4.3";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=10&t=871" 5665;1;"Open";3;5001;"Lennart Karssen";100;"Nobody";"2014-05-02 11:41";"";"2014-05-02 11:41";"mach2databel() doesn't work correctly if the part before -> in the mach file contains letters";"I received this bug in an e-mail from one of our users. If the mldose/mlprob file from MaCH contains letters before the -> these are not stripped, only numbers are. So with NA1234->NA1234 MLDOSE .... the smaple id is converted to NANA1234 instead of NA1234. ";"Confirmation Needed";"All";"normal";"All";"v1.8-0";"GenABEL";"" 5793;2;"Closed";3;5001;"Lennart Karssen";1754;"Maksim Struchalin";"2014-07-02 09:25";"2014-07-03 07:05";"2014-07-07 13:39";"impute2DatABEL gives several errors";"This bug was reported on the forum (see URL). It may be related to what was reported in http://forum.genabel.org/viewtopic.php?f=6&t=814; Linux 64bit, R 3.1.0 Typical error messages: Error in .Call(""iterator"", tmp_fv@data, as.integer(0), as.integer(0), : ""iterator"" not resolved from current namespace (GenABEL) and file contains data of unknown type 5 Maybe two bugs? Maksim's first look at the problem suggests that it works for him, but may be related to compile order?";"Accepted As Bug";"None";"major";"All";"v1.8-0";"GenABEL";"http://forum.genabel.org/viewtopic.php?f=6&t=884&p=1877" 5883;2;"Closed";3;299731;"Farid Radmanesh";1754;"Maksim Struchalin";"2014-08-21 20:48";"2014-08-22 11:00";"2015-01-04 23:16";"ProbABEL: The main effect is displayed in the output with the `interaction_only` option";"When testing GXE, the `interaction_only` option can be used to only include the interaction term in the model, as opposed to `interaction` option that includes both the main effect and interaction term in the model. Although the main effect is truly excluded from the model with `interaction_only`, the output displays a model that includes the main effect. ";"Fixed";"Linux (64bit)";"minor";"All";"PA v0.4.3";"ProbABEL";"" 5982;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2014-11-07 12:56";"2014-11-07 13:26";"2014-11-07 13:26";"ProbABEL's make install fails on MacOS X and FreeBSD with sed error";"When trying to install ProbABEL v0.4.3 from source on MacOS X, the 'make install' step fails with the following sed errors: make install Making install in src .././install-sh -c -d '/Users/max/Desktop/Software_new/probabel_installed/bin' /usr/bin/install -c palinear palogist pacoxph '/Users/max/Desktop/Software_new/probabel_installed/bin' .././install-sh -c -d '/Users/max/Desktop/Software_new/probabel_installed/bin' /usr/bin/install -c probabel '/Users/max/Desktop/Software_new/probabel_installed/bin' .././install-sh -c -d '/Users/max/Desktop/Software_new/probabel_installed/etc' /usr/bin/install -c -m 644 probabel_config.cfg.example '/Users/max/Desktop/Software_new/probabel_installed/etc' /Applications/Xcode.app/Contents/Developer/usr/bin/make install-exec-hook /usr/bin/sed -i ""s;probabel_config.cfg;/Users/max/Desktop/Software_new/probabel_installed/etc/probabel_config.cfg;"" \ /Users/max/Desktop/Software_new/probabel_installed/bin/probabel sed: 1: ""/Users/max/Desktop/Soft ..."": invalid command code m See also the forum post linked above. Thanks to forum user 'mmold' for reporting this bug. ";"Accepted As Bug";"other";"normal";"None";"PA v0.4.3";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=10&t=901#p1936" 6010;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2015-01-04 22:53";"2015-01-04 23:16";"2015-01-04 23:16";"The model displayed by ProbABEL is wrong when the interaction_only option is used";"When using the --interaction_only option (-k) in ProbABEL, the model displayed on the screen is incorrect. Consider a phenotype file with the following header: id height cov1 cov2 cov3 cov4 cov5 When running --interaction_only=3, the model that SHOULD be printed is: Linear model: ( height ) ~ mu + cov1 + cov2 + cov4 + cov5 + SNP_A1 + cov3*SNP_A1 (i.e. without a cov3 term). The model that IS printed is: Linear model: ( height ) ~ mu + cov1 + cov2 + cov3 + cov4 + cov5 + SNP_A1 + cov3*SNP_A1 This is related to the fix in r1803 (which also seems to have left some debug cout statements in the code). ";"Fixed";"All";"normal";"All";"PA v0.4.4";"ProbABEL";"" 6011;1;"Open";3;1754;"Maksim Struchalin";100;"Nobody";"2015-01-06 02:41";"";"2015-01-06 02:41";"Problem with iterator again.";"Today's report from GenABEL user: Error in .Call(""iterator"", tmp_fv@data, as.integer(0), as.integer(0), : ""iterator"" not resolved from current namespace (GenABEL) It looks like the bug #1126 that has been fixed with the last release of DatABEL (0.9-5) but I can't workaround this issue despite trying multiple combinations of different versions of DatABEL(0.9-4, 0.9-4.1, 0.9-5), GenABEL(1.7-6, 1.8 + GenABEL.data_1.0.0) and R (3.1.0,3.0.0 and 2.15.0) on 2 different servers (Linux 2.6.32-431.20.3.el6.x86_64 x86_64 and Linux 2.6.18-194.17.1.el5.alces x86_64). ";"Confirmation Needed";"None";"normal";"None";"None";"GenABEL";"" 6045;2;"Closed";3;5001;"Lennart Karssen";100;"Nobody";"2015-03-06 18:23";"2015-11-04 15:42";"2015-11-04 15:42";"Using --mmscore and --interaction will not output a column with cov_SNP_int_SNP_covariate";"This was reported several times in the forum: http://forum.genabel.org/viewtopic.php?f=10&t=830&p=1662 http://forum.genabel.org/viewtopic.php?f=10&t=896 http://forum.genabel.org/viewtopic.php?f=10&t=885&p=1881 Some test output: ../src/palinear -p testphenommscore.phe -d inputfiles/mmscore_gen.dose.fvi -i inputfiles/mmscore_gen.mlinfo -o lck2 --mmscore=inputfiles/mmscore_InvSigma_aj.sex.age.dat --interaction=1 probabel v. 0.4.4 (C) Yurii Aulchenko, Lennart C. Karssen, Maarten Kooyman, Maksim Struchalin, The GenABEL team, EMC Rotterdam Using EIGEN version 3.2.0 for matrix operations Options in effect: --pheno = testphenommscore.phe --info = inputfiles/mmscore_gen.mlinfo --dose = inputfiles/mmscore_gen.dose.fvi (using FVF data) --ntraits = 1 --ngpreds = 1 --interaction = 1 --interaction_only = 0 --mmscore = inputfiles/mmscore_InvSigma_aj.sex.age.dat --map = not in output --nids = estimated from data --chrom = not in output --out = lck2 --skipd = 2 --separat = "" "" --score = OFF --nohead = OFF --allcov = OFF --robust = OFF Reading info data... Number of SNPs = 5 Reading phenotype data... Actual number of people in phenofile = 500; using all of these Linear model: ( height_residuals ) ~ mu + cov1 + cov2 + SNP_A1 + cov1*SNP_A1 You are running mmscore... loaded InvSigma... Reading genotype data... done. loaded null data... estimated null model... formed regression object... Analysis: 100.00%... done Gives: name A1 A2 Freq1 MAF Quality Rsq n Mean_predictor_allele beta_SNP_addA1 sebeta_SNP_addA1 beta_SNP_cov1 sebeta_SNP_cov1 chi2_SNP_add rs735579 AC B 0.5847 0.5847 0.5847 0.5847 491 0.534623 1.73386 0.909754 0.296646 1.59171 3.63231 rs9088604 A CTG 0.5847 0.5847 0.5847 0.5847 497 0.435614 -2.07862 0.961285 1.87346 1.6741 4.67569 rs1413801 A B 0.5847 0.5847 0.5847 0.5847 492 0.311992 -2.18676 1.12553 1.20374 1.87225 3.77478 rs4911638 A B 0.5847 0.5847 0.5847 0.5847 496 0.150202 0.675667 1.30507 0.75037 2.25757 0.268039 rs70099 A B 0.5847 0.5847 0.5847 1.2e-17 493 0.0922921 NaN NaN NaN NaN NaN ";"Accepted As Bug";"All";"normal";"All";"PA v0.4.4";"ProbABEL";"" 6194;2;"Closed";3;5001;"Lennart Karssen";100;"Nobody";"2015-10-14 22:09";"2016-01-12 10:21";"2016-01-12 10:21";"Coxph interactions not working";"See also the forum post linked above. From the forum post: When our phenotype file includes four columns (ID, Age, Event, cov1) and the interaction parameter is specified as interaction==1, the model given is incorrect (Coxph model: ( Age , Event ) ~ mu + cov1 + SNP_A1 + mu*SNP_A1). When the interaction parameter is specified as interaction==2, the model shown is now correct, Coxph model: ( Age , Event ) ~ mu + cov1 + SNP_A1 + cov1*SNP_A1, but the analysis doesn't run, giving the following error error: Interaction parameter is out of range (interaction=2) When we include a phenotype file with an additional covariate column (ID, Age, Event, cov1, cov2) and specify interaction==2, the model looks ok (with the exception of a covariate we didn't want to include), Coxph model: ( Age , Event ) ~ mu + cov1 + cov2 + SNP_A1 + cov1*SNP_A1, and the analysis seems to run, but it's not clear what analysis is being run to give the results; we can't replicate any of the results shown in R. ";"Confirmation Needed";"All";"normal";"All";"PA v0.4.5";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=10&t=975" 1126;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2010-10-11 23:50";"2014-09-11 11:13";"2014-09-11 11:13";"Using mach2databel() or impute2mach() to convert files to the filevector format leaves fvtmp filles behind";"Observed behaviour: I recently used the functions impute2mach() and mach2databel() to convert impute and mach files to DatABEL's filevector format. In both cases the .fv? files were created correctly. However, in both cases two files ending in _fvtmp.fvi and _fvtmp.fvd were left behind. Note: The _fvtmp.fv? file and its corresponding .fv? file have the same size, however, their md5sums differ, so they are not identical. Expected behaviour: The functions should only leave the final .fvi and .fvd files. Temporary files should be removed after successful conversion. ";"Accepted As Bug";"Linux (64bit)";"minor";"None";"other";"DatABEL";"" 2437;2;"Closed";3;13427;"Daniel Taliun";100;"Nobody";"2012-12-14 11:04";"2015-11-04 15:37";"2015-11-04 15:37";"palinear can't process more than 2 millions SNPs in a dosage file";"Error message: mematrix(nr,nc): cannot allocate memory (1148,2582783) Input: 1148 individuals, dosage file with 2582783 SNPs. Cause: In mematr1.h file lines: 20: data = new (nothrow) DT [ncol*nrow]; 165: data = new (nothrow) DT [ncol*nrow]; The ncol and nrow are of type int. The result ncol*nrow is stored in int, which is not enough to represent big number and becomes negative. The allocation fails. When changed to data = new (nothrow) DT [(unsigned int)ncol*nrow], the memory is allocated successfully. Another crucial thing is to change nelements variable from int to unsigned int. ";"Accepted As Bug";"Linux (64bit)";"critical";"All";"PA v0.2.2";"ProbABEL";"" 2449;2;"Closed";3;20840;"Maarten Kooyman";1713;"Yurii Aulchenko";"2012-12-22 15:45";"2013-01-27 21:37";"2013-01-27 21:37";"moorepenrose.cpp fails to compile with g++ version 4.6 and higher";"When installing MixABEL there is a compile error when compiling moorepenrose.cpp. This happen only with g++ version 4.6 and 4.7. g++ version 4.5 and 4.4 are not affected. g++ fails with the folowing message: g++-4.7 -I/usr/share/R/include -DNDEBUG -fopenmp -fpic -O2 -pipe -g -c moorepenrose.cpp -o moorepenrose.o moorepenrose.cpp: In function ‘int moore_penrose(gsl_matrix*, double)’: moorepenrose.cpp:60:64: error: taking address of temporary [-fpermissive] moorepenrose.cpp:63:96: error: taking address of temporary [-fpermissive] For sake of argument I tried to compile it with clang++ version 3.0 which tells us a nicer error message: clang++ -I/usr/share/R/include -DNDEBUG -fopenmp -fpic -O2 -pipe -g -c moorepenrose.cpp -o moorepenrose.o clang: warning: argument unused during compilation: '-fopenmp' moorepenrose.cpp:60:23: error: taking the address of a temporary object of type 'gsl_vector' [-Waddress-of-temporary] gsl_vector_scale(&(gsl_matrix_column(psvd_V_mat,it).vector),1.0/gsl_vector_get(psvd_S_vec,it)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ moorepenrose.cpp:63:33: error: taking the address of a temporary object of type 'gsl_matrix' [-Waddress-of-temporary] gsl_matrix_memcpy(pUrest_mat,&(gsl_matrix_submatrix(pA_mat,0,0,pA_mat->size1, thresh).matrix)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. ";"Fixed";"None";"normal";"None";"other";"MixABEL";"" 2575;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-02-22 16:20";"2013-02-26 00:14";"2013-02-26 00:14";"ProbABEL chooses weird file names if the -o option is not specified";"Running palinear or palogist without the -o option to specify an ouput file name base results in strange file names (output of ls): ???_add.out.txt ???_add.out.txt ?n?_add.out.txt ????_add.out.txt";"Fixed";"All";"normal";"All";"PA v0.3.0";"ProbABEL";"" 2586;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-02-27 17:12";"2013-05-13 09:34";"2013-05-14 18:44";"ProbABEL can't handle indels (SNPs with multicharacter alleles) in the mlinfo files";"According to these two reports: http://forum.genabel.org/viewtopic.php?f=10&t=757 http://forum.genabel.org/viewtopic.php?f=10&t=758&p=1434#p1434 ProbABEL crashes hard when multi-character strings are used for the alleles in the info file. As a result ProbABEL doesn't handle indels (e.g. from 1kG imputations) at all.";"Invalid";"All";"normal";"All";"PA v0.3.0";"ProbABEL";"" 2772;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-05-07 18:44";"2013-05-07 18:51";"2013-05-07 18:51";"palogist with mmscore crashes (memory issue)";"Running palogist with mmscore crashes. This issue was reported on the forum: http://forum.genabel.org/viewtopic.php?f=10&t=789&p=1536#p1536 It seems to be a memory (de-)allocation problem. I confirmed this bug with both text and fvf input files. Thanks to Anuj for reporting this. ";"Fixed";"All";"major";"All";"PA v0.3.0";"ProbABEL";"" 4854;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-08-28 14:14";"2013-08-29 23:25";"2013-08-29 23:25";"When using mmscore, there is one (nan) column missing in the output for low-frequency SNPs";"For low frequency SNPs ProbABEL prints nan for beta and SE_beta. However, when using palinear with --mmscore the nan (probably of the chi^2) is missing, so in the output file not every line has the same number of columns. This makes it difficult to read the output file into R. Reported by Sven vd Lee.";"Fixed";"All";"normal";"All";"PA v0.4.0";"ProbABEL";"" 4885;2;"Closed";3;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-09-10 13:35";"2013-11-13 13:18";"2013-11-17 23:50";"ProbABEL's Cox regression gives error, but doesn't say for which SNP";"ProbABEL's pacoxph sometimes gives the error: ""Error: Cox regression did not converge"". However, it doesn't say for which SNP this error occurred. See the forum topic http://forum.genabel.org/viewtopic.php?f=10&t=825 for more details. ";"Fixed";"All";"normal";"All";"PA v0.4.1";"ProbABEL";"" 4915;2;"Closed";3;151695;"Hermann Norpois";5001;"Lennart Karssen";"2013-09-18 12:07";"2013-09-18 14:35";"2013-09-18 14:35";"VariABEL: the argument ""analysis_type"" is truncated ";"In the pdf-documentation of VariABEL the argument ""analysis_type"" is truncated by the margin. So you dont know explicitly the default.";"Fixed";"All";"minor";"All";"None";"VariABEL";"" 4916;2;"Closed";3;151695;"Hermann Norpois";1754;"Maksim Struchalin";"2013-09-18 12:43";"2013-11-07 07:11";"2013-11-07 07:11";"VariABEL: levene test does not work";"> result <- var_test_gwaa (""bt"", genodata=gtdata (srdta), phenodata=phdata (srdta), testname=""levene"") [1] ""reading genotype info..."" [1] ""Start variance analysis..."" Fehler in var_test_gwaa(""bt"", genodata = gtdata(srdta), phenodata = phdata(srdta), : error: var: sample has not more than one element The same happens with quantitative trait.";"None";"Linux (64bit)";"critical";"Other";"None";"VariABEL";"" 4919;2;"Closed";3;13427;"Daniel Taliun";5001;"Lennart Karssen";"2013-09-19 12:41";"2013-11-04 11:13";"2013-11-04 11:13";"Too small reading buffers for long alleles in mach info and legend files";"1) Segmentation fault when trying to read mach info file that contains alleles longer than 100 characters. The issue is too small buffer allocated in mlinfo::mlinfo(char * filename, char * mapname) : only 100 characters (data.cpp, line 72) 2) The same problem is when reading map file (if --map option is specified). The buffer of 1000 characters is not enough and as a result position is always equal to -999 (data.cpp, line 139). Generally insertion/deletion alleles can be extremely long. But buffer of 1MB (1048576 characters) should be enough and cost nothing.";"Fixed";"All";"trivial";"All";"PA v0.4.1";"ProbABEL";"" 5040;1;"Open";3;1713;"Yurii Aulchenko";100;"Nobody";"2013-11-03 18:19";"";"2013-11-04 09:36";"Spelling of name incorrect ";"Spelling ""SVISHEVA"" used in referring to work of Gulnara is incorrect (correct is ""SVISHCHEVA"") This misspelling is apparently used throughout www.genabel.org and RForge site";"Accepted As Bug";"All";"minor";"All";"None";"GenABEL";"" 5065;1;"Open";3;1885;"Xia Shen";100;"Nobody";"2013-11-07 15:49";"";"2013-11-26 10:21";"polygenic() runs into numerical error when changing the way of input";"I had: > names(orkney_imp@phdata) [1] ""id"" ""sex"" ""sex0"" ""Sex"" ""age"" ""plate"" [7] ""row"" ""column"" ""part"" ""machine"" ""GP1Raw"" ""GP2Raw"" [13] ""GP3Raw"" ""GP4Raw"" ""GP5Raw"" ""GP6Raw"" ""GP7Raw"" ""GP8Raw"" [19] ""GP9Raw"" ""GP10Raw"" ""GP11Raw"" ""GP12Raw"" ""GP13Raw"" ""GP14Raw"" [25] ""GP15Raw"" ""GP16Raw"" ""GP17Raw"" ""GP18Raw"" ""GP19Raw"" ""GP20Raw"" [31] ""GP21Raw"" ""GP22Raw"" ""GP23Raw"" ""GP24Raw"" ""TotalArea"" ""Conc"" [37] ""GP1"" ""GP2"" ""GP4"" ""GP5"" ""GP6"" ""GP7"" [43] ""GP8"" ""GP9"" ""GP10"" ""GP11"" ""GP12"" ""GP13"" [49] ""GP14"" ""GP15"" ""GP16"" ""GP17"" ""GP18"" ""GP19"" [55] ""GP20"" ""GP21"" ""GP22"" ""GP23"" ""GP24"" ""DP1"" [61] ""DP2"" ""DP3"" ""DP4"" ""DP5"" ""DP6"" ""DP7"" [67] ""DP8"" ""DP9"" ""DP10"" ""DP11"" ""DP12"" ""DP13"" [73] ""DP14"" ""DP15"" ""DP16"" ""DP17"" ""DP18"" ""DP19"" [79] ""DP20"" ""DP21"" ""DP22"" ""DP23"" ""DP24"" ""DP25"" [85] ""DP26"" ""DP27"" ""DP28"" ""DP29"" ""DP30"" ""DP31"" [91] ""DP32"" ""DP33"" ""DP34"" ""DP35"" ""DP36"" ""DP37"" [97] ""DP38"" ""DP39"" ""DP40"" ""DP41"" ""DP42"" ""DP43"" [103] ""DP44"" ""DP45"" ""DP46"" ""DP47"" ""DP48"" ""DP49"" [109] ""DP50"" ""DP51"" ""DP52"" ""DP53"" ""DP54"" > i [1] 37 Error was generated by: > poly <- polygenic(orkney_imp@phdata[,i] ~ sex + age + plate + part + machine, data = orkney_imp, kinship.matrix = gkin_imp) LM estimates of fixed parameters: desmat(Intercept) desmatsex desmatage desmatplate -1.847502e+00 -2.174026e-17 -3.334917e-19 1.468850e-01 desmatpart desmatmachine -5.807583e-18 -3.584089e-17 iteration = 0 Step: [1] 0 0 0 0 0 0 0 0 Parameter: [1] -1.847502e+00 -2.174026e-17 -3.334917e-19 1.468850e-01 -5.807583e-18 [6] -3.584089e-17 3.000000e-01 2.160984e-32 Function Value [1] 1.797693e+308 Gradient: [1] 0 0 0 0 0 0 0 -Inf Error in nlm(llFUN, p = parsave, y = y, desmat = desmat, relmat = relmat, : non-finite value supplied by 'nlm' But: > poly <- polygenic(GP1 ~ sex + age + plate + part + machine, data = orkney_imp, kinship.matrix = gkin_imp) ... ... difFGLS: [1] 1.144640e-12 8.242126e-11 7.493652e-12 1.352104e-11 2.998067e-11 [6] 4.183117e-10 ****************************************** *** GOOD convergence indicated by FGLS *** ****************************************** Why simply changing the way of input gave different outcome?? By the way, > poly <- polygenic(orkney_imp@phdata[,i] ~ sex + age + plate + part + machine, data = orkney_imp, kinship.matrix = gkin_imp) worked well. ";"Awaiting Response";"Linux (64bit)";"major";"None";"v1.7-6";"GenABEL";"" 1259;2;"Closed";2;1713;"Yurii Aulchenko";100;"Nobody";"2011-01-28 07:57";"2011-03-31 02:01";"2011-03-31 02:01";"descriptives.trait with by.var argument does not work (contributed by Richard Ahn)";"Contributed by Richard Ahn: see discussion at http://forum.genabel.org/viewtopic.php?f=6&t=4 Attached test data and script. Unpack, then R -f test.R ";"Fixed";"None";"minor";"None";"v1.6-5";"GenABEL";"" 5299;2;"Closed";2;5001;"Lennart Karssen";100;"Nobody";"2014-01-24 09:38";"2015-10-30 05:07";"2015-10-30 05:07";"Filevector doesn't work on big-endian architectures";"The Debian build logs for big-endian machines (see URL) show that the ProbABEL checks fail on machines with that architecture. Closer inspection reveals that the checks fail on the comparison between text and binary (filevector-format) input. Also see this discussion on the debian-mentor mailing list, especially Gert Wollny's posts: https://lists.debian.org/debian-mentors/2014/01/msg00326.html Wollny writes: ""I dug around in the code and voila, e.g. in fvlib/frutil.cpp the function blockWriteOrRead uses fstream.read|write to do raw data IO and then in other parts of the code the data is just cast to the desired type without doing any checks of endianess let alone the needed conversions."" Since I doubt that many people will use ProbABEL/DatABEL/filevector on other (big-endian) architectures there is no hurry in fixing this. Nevertheless it's worth having this bug visible and in the back of our minds.";"Accepted As Bug";"All";"normal";"Other";"other";"FileVector";"https://buildd.debian.org/status/package.php?p=probabel" 1322;1;"Open";2;1713;"Yurii Aulchenko";100;"Nobody";"2011-03-09 15:32";"";"2011-03-09 15:32";"polygenic would not run with a covariate which is non-informative";"see forum to understand where this comes from (but there is workaround): http://forum.genabel.org/viewtopic.php?f=6&t=134#p218 example attached";"None";"None";"normal";"None";"None";"GenABEL";"" 1186;2;"Closed";2;1713;"Yurii Aulchenko";5001;"Lennart Karssen";"2010-10-22 23:56";"2012-10-03 23:40";"2012-10-03 23:40";"Wrong error message in ProbABEL when .map file missing";"From Nicola Pirastu: when the map file is missing the error message will tell you that the mlinfo file is missing instead";"Fixed";"All";"normal";"All";"PA v0.1-9b";"ProbABEL";"" 4776;2;"Closed";2;5001;"Lennart Karssen";100;"Nobody";"2013-07-24 14:02";"2013-11-29 20:48";"2013-11-29 20:48";"Specifying --sep=""\t"" as an option to pa* doesn't insert a TAB as separator";"When running palinear/pacoxph/palogist with the --sep=""\t"" option, the output has the characters \t literally in the output: name\tA1\tA2\tFreq1\tMAF\tQuality\tRsq\tn\tMean_predictor_allele\tchrom\tposition\tbeta_SNP_add\tsebeta_SNP_add\tchi2_SNP This should be interpreted as a TAB. FYI: setting --sep="";"" works as expected. ";"Accepted As Bug";"All";"minor";"All";"PA v0.3.0";"ProbABEL";"" 6054;2;"Closed";2;5001;"Lennart Karssen";5001;"Lennart Karssen";"2015-03-16 21:30";"2015-03-16 23:01";"2015-03-16 23:01";"Not all ProbABEL's short command line options are correctly parsed";"the short options mentioned in command_line_settings.cpp are not entirely correct: - k for the long option interaction_only is not present - the v option for mmscore doesn't have a : to indicate a mandatory argument ";"Fixed";"All";"minor";"All";"PA v0.4.4";"ProbABEL";"" 5147;1;"Open";2;20840;"Maarten Kooyman";100;"Nobody";"2013-11-26 15:28";"";"2015-04-03 18:28";"matrix2databel does not check user is allowed to write files";"When I use matrix2databel in a directory where there is no write access for the usere, there is a non informative error message: dat1 <- matrix2databel(matr , filename=""/etc/testnew"") Index file not exists: testnew.fvi Error in checkAtAssignment(""databel"", ""data"", ""NULL"") : assignment of an object of class “NULL” is not valid for @‘data’ in an object of class “databel”; is(value, ""externalptr"") is not TRUE When I use this function in a directory where I do have access the everything works smoothly. dat1 <- matrix2databel(matr , filename=""/tmp/testnew"")";"Accepted As Bug";"Linux (64bit)";"normal";"PC";"other";"DatABEL";"" 5409;2;"Closed";2;5001;"Lennart Karssen";5001;"Lennart Karssen";"2014-03-05 22:25";"2014-03-21 14:47";"2014-03-21 14:47";"The header for dosage-based output is not equal to that of prob-based ProbABEL output.";"As discussed on the dev list, starting at [1], the headers of the output files for dosage-based and probability-based ProbABEL runs (for the additive model, of course) are different. There doesn't seem to be a reason for this difference and it makes the run_diff.sh script in the ProbABEL/checks/ dir unnecessarily compilcated (having to run diff with the -I argument). Some OSes (Solaris for one) don't have GNU diff and therefore may miss the -I option, resulting in ProbABEL failing its checks. Thanks to Lucho Dimitrov for reporting this bug on de dev list. [1] http://lists.r-forge.r-project.org/pipermail/genabel-devel/2014-March/000993.html";"Fixed";"All";"minor";"All";"PA v0.4.3";"ProbABEL";"http://lists.r-forge.r-project.org/pipermail/genabel-devel/2014-March/000993.html" 2598;2;"Closed";2;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-03-08 15:40";"2013-05-13 09:20";"2013-05-13 09:20";"The prepare_data.R script is mentioned in the manual, but not distributed in .deb or .tar.gz";"In ProbABEL: The file is located in de src directory, but doesn't get included when running the ""make dist"" command. Probably needs to be fixed in src/Makefile.am See forum post: http://forum.genabel.org/viewtopic.php?f=10&t=759&p=1448#p1448";"Fixed";"All";"minor";"All";"PA v0.3.0";"ProbABEL";"" 2608;1;"Open";2;1713;"Yurii Aulchenko";100;"Nobody";"2013-03-12 09:14";"";"2013-12-02 09:26";"GenABEL-package loads too long if there is no internet connection";"Try loading the GenA-package ('library(GenABEL)"") in R with and without internet connection. There is a clear difference. This is something to do with the (multiple???) 'timeout' argument - probably need to do quicker. ";"None";"None";"trivial";"None";"None";"GenABEL";"" 1383;2;"Closed";2;5001;"Lennart Karssen";100;"Nobody";"2011-05-05 13:02";"2012-04-03 13:14";"2012-04-03 13:14";"Message about upgrade on loading the library not entirely correct";"When loading e.g. GenABEL and a newer version of the package is available a message is printed: > library(GenABEL) Loading required package: MASS GenABEL v. 1.6-6 (March 31, 2011) loaded Installed GenABEL version (1.6-6) is not the same as stable version available from CRAN (1.6-5). Unless used intentionally, consider updating to the latest CRAN version. For that, use 'install.packages(""GenABEL"")', or ask your system administrator to update the package. In this case the message is wrong. 1.6-6 is not yet declared stable (we're in the final test phas), but it is the one that is available on CRAN. Therefore, in this case the suggestion to run install.packages() is incorrect (and that's what I just did). I guess we should put in a check to see if the version in CRAN is higher than the reference stable version number. ";"Fixed";"All";"minor";"All";"v1.6-6";"All";"" 1185;2;"Closed";1;1713;"Yurii Aulchenko";100;"Nobody";"2010-10-22 19:34";"2011-03-31 02:01";"2011-03-31 02:01";"descriptives.trait with missings in by.var argument";"if missing data present in by.var, it does not run: to get to the bug, run library(GenABEL) data(ge03d2ex) # this works descriptives.trait(ge03d2ex,by.var=phdata(ge03d2ex)$sex) phdata(ge03d2ex)$sex[2] <- NA # and this does not! descriptives.trait(ge03d2ex,by.var=phdata(ge03d2ex)$sex) ";"Fixed";"All";"minor";"All";"None";"GenABEL";"" 1184;2;"Closed";1;1713;"Yurii Aulchenko";100;"Nobody";"2010-10-22 19:32";"2011-03-31 02:01";"2011-03-31 02:01";"descriptives.trait can not see the variable in by.var argument unless full path specified";"the full path is to be specified for the by.var argument, function does not look up in the data object to get to the bug, run library(GenABEL) data(ge03d2ex) # this works descriptives.trait(ge03d2ex,by.var=phdata(ge03d2ex)$sex) # and this does not! descriptives.trait(ge03d2ex,by.var=sex) ";"Fixed";"All";"minor";"All";"None";"GenABEL";"" 2529;2;"Closed";1;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-02-07 09:32";"2013-05-13 18:22";"2013-05-14 18:44";"ProbABEL doesn't warn when a required file is not specified on the command line";"When running palinear/palogist/pacoxph without the required -i, -p or -d option ProbABEL simply prints the default help message, but no explanatory message about what is missing. We should make this more user friendly.";"Fixed";"All";"minor";"All";"PA v0.3.0";"ProbABEL";"" 1290;2;"Closed";1;5001;"Lennart Karssen";5001;"Lennart Karssen";"2011-02-21 18:16";"2011-08-12 12:50";"2011-08-12 12:50";"The probABEL manual does not show how to use files in DatABEL format.";"Bug in the probABEL manual: The probABEL manual does not indicate how to use files in DatABEL (filevector) format. This can be done by using the .fvi file. ";"Fixed";"All";"trivial";"All";"other";"ProbABEL";"http://forum.genabel.org/viewtopic.php?f=6&t=22" 4683;2;"Closed";1;5001;"Lennart Karssen";5001;"Lennart Karssen";"2013-06-19 14:35";"2013-06-30 00:44";"2013-06-30 00:44";"probabel.pl writes to the wrong directory if a .PHE file with path is given on the command line";"This report comes from Aaron Isaacs. When running the probabel.pl script with a relative path name for the phenotype file (e.g. ../myphenofile), the output file ends up in the other directory (../ in this case). This is when not specifying the -o option. The expected behaviour is to have the output file end up in the present directory. ";"Fixed";"All";"minor";"All";"PA v0.3.0";"ProbABEL";"" 2085;1;"Open";1;5001;"Lennart Karssen";100;"Nobody";"2012-06-18 10:31";"";"2012-06-18 10:31";"When using impute2databel() the output file (as printed on the screen) is wrong";"When converting impute files to DatABEL format using impute2databel(), the screen output lists the wrong output file. For example: impute2databel(""HG19.for-impute.plink.chr1.ped.chunk1.impute2"", ""HG19.for-impute.plink.chr1.ped.sample"", ""HG19.for-impute.plink.chr1.ped.chunk1.genabel"") Options in effect: --infile = HG19.for-impute.plink.chr1.ped.chunk1.impute2 --outfile = ./tmp64964 --skiprows = OFF --skipcols = 5 --cnrow = OFF --rncol = ON, using column 2 of 'HG19.for-impute.plink.chr1.ped.chunk1.impute2' --transpose = ON --Rmatrix = OFF --nanString = NA Here you see that outfile is listed as ./tmp64964 instead of the third argument of the function. In line 36 of GenABEL's impute2databel() function a tmp file is created and this file is passed to the text2databel() function to be used for output. For the conversion this tmp file is used to create a temporary DatABEL object. Near the end of the impute2databel() function the temporary fv object is converted to a 'real' DatABEL file with the outfile name. DatABEL's text2databel() function calls the function text2fvf_R() in DAlib, which, in turn, calls the C function text2fvf() in fvlib's convert_util.cpp. This function prints the options list unless the 'quiet' argument is true. Maybe we should set quiet to true when using impute2databel() in order to reduce confusion? This behaviour is probably the same for other '2databel()' functions as well.";"Accepted As Bug";"All";"minor";"All";"v1.7-0";"GenABEL";""