Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gimme motifs --known ERROR #128

Closed
fgualdr opened this issue Jul 2, 2020 · 4 comments
Closed

gimme motifs --known ERROR #128

fgualdr opened this issue Jul 2, 2020 · 4 comments
Milestone

Comments

@fgualdr
Copy link

fgualdr commented Jul 2, 2020

Hi,

I am attempting to run gimme motifs with --known parameter on a fresh installation but it fails giving several errors.

The installation was performed following instructions e.g. creating an environment using Conda. The installation is done on an hpcs cluster at the institute where I am working.

The pipe I am sending is the following:

gimme motifs $PEAK $$FOLDER --size 200 --background $BG_PEAKS -g hg38 --known --nthreads 5
The error I get is the following:

2020-07-02 09:31:27,868 - INFO - skipping de novo
2020-07-02 09:31:27,872 - INFO - creating motif scan tables
2020-07-02 09:52:01,351 - INFO - calculating stats
[1. 1. 1. ... 0. 0. 0.]
[' nan' ' nan' ' nan' ... ' nan' ' nan' ' nan']
ufunc 'subtract' did not contain a loop with signature matching types (dtype('<U4'), dtype('<U4')) -> dtype('<U4')
[1. 1. 1. ... 0. 0. 0.]
[' nan' ' nan' ' nan' ... ' nan' ' nan' ' nan']
ufunc 'subtract' did not contain a loop with signature matching types (dtype('<U4'), dtype('<U4')) -> dtype('<U4')
[1. 1. 1. ... 0. 0. 0.]
[' nan' ' nan' ' nan' ... ' nan' ' nan' ' nan']
ufunc 'subtract' did not contain a loop with signature matching types (dtype('<U4'), dtype('<U4')) -> dtype('<U4')
...
ufunc 'subtract' did not contain a loop with signature matching types (dtype('<U4'), dtype('<U4')) -> dtype('<U4')
[1. 1. 1. ... 0. 0. 0.]
[' nan' ' nan' ' nan' ... ' nan' ' nan' ' nan']
ufunc 'subtract' did not contain a loop with signature matching types (dtype('<U4'), dtype('<U4')) -> dtype('<U4')
Traceback (most recent call last):
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/bin/gimme", line 11, in
cli(sys.argv[1:])
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/lib/python3.7/site-packages/gimmemotifs/cli.py", line 625, in cli
args.func(args)
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/lib/python3.7/site-packages/gimmemotifs/commands/motifs.py", line 183, in motifs
ncpus=args.ncpus,
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/lib/python3.7/site-packages/gimmemotifs/stats.py", line 160, in calc_stats_iterator
for motif_id, s, ret in it:
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/lib/python3.7/site-packages/gimmemotifs/stats.py", line 284, in _mp_stats
ret = job.get()
File "/hpcnfs/data/GN2/fgualdrini/.conda/envs/Envgimme/lib/python3.7/multiprocessing/pool.py", line 657, in get
raise self._value
multiprocessing.pool.MaybeEncodingError: Error sending result: '<multiprocessing.pool.ExceptionWithTraceback object at 0x7ff7e81e11d0>'. Reason: 'Pic
klingError("Can't pickle <class 'numpy.core._exceptions.UFuncTypeError'>: it's not the same object as numpy.core._exceptions.UFuncTypeError")'

I tried to check on previous FAQ and forums but I cold not find anyone with the same issue.
Thanks in advance for the help
Francesco

@simonvh
Copy link
Member

simonvh commented Jul 7, 2020

Hi @fgualdr , this is indeed also a new error for me. At the moment I am at a loss to explain this. Can you test with a minimal / small input file and see if you can reproduce the error? Can you give me the output of conda list?

@simonvh
Copy link
Member

simonvh commented Jul 7, 2020

@fgualdr What are the sizes of your input regions? I think this could be a bug related to #123?

@fgualdr
Copy link
Author

fgualdr commented Jul 8, 2020

Thanks!
Indeed was the BED peak size the problem - I provided a one base BED to gimme.
I was thinking it was performing like Homer as I specified the --size 200 I though gimme would extend the peak when --size is specified.
By modifying the BED it now works smoothly.
Thanks again
Francesco

@simonvh
Copy link
Member

simonvh commented Jul 8, 2020

Great that it worked! To be clear: what you expected is the intended behavior. This is clearly a bug to fix for the next release.

@simonvh simonvh added this to the 0.15.0 milestone Jul 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants