Hi, Trying to run a workflow. But cannot due to the insistence of cuffdiff on existence of SAM/BAM file(s) (which are not generated before the workflow is run).
This really seems to limit the utility of workflows. Is there any way to get past this (p.s. in prior runs of this workflow, this was not experience).
Hi All, Just re-ran and the problem persists (nothing changed; still unable to run workflow). I waited some time for things to settle after the system changes. Any idea to to overcome? Mike
p.s. oddly, my prior message about the workflow disappeared. here is the workflow: https://usegalaxy.org/u/mike-2/w/diff1
I'll take a look at this Boa and Mike and get back to you both here. Is there a share history link you can share that contains the workflow inputs? Also, a shared link to a history that contains the problematic execution would be helpful. Both can be the same - as every history executed with a workflow automatically copies the input datasets over. Thanks, Jen
Hi Jennifer, I just have two pairs of files (2x LAA and 2x LV). That is all which is being used for the inputs. The error is coming about as a result of trying to run the workflow; no error messages are being shown in the history (doesn't get that far). workflow-->diff1-->run-->choose files-->execute --> unable :(
Sincerely, Mike
I found the inputs and made a copy to test the workflow. Thanks. Jen
The workflow has a few issues:
Help:
First, rerun again now. The server is still undergoing updates/changes and this could be related.
If it still is an issue, could you explain more or share a link to the workflow and a test history with the inputs you use. I am wondering if the objects in the workflow are configured/linked correctly. In particular, I'd like to check if "Input" selections are included in the workflow (required - found at the top of the tool panel in the workflow editor - click the appropriate type to add these to the editor and link to the downstream tool(s)).
If there is a workflow editor issue, this will help to track that down as well. Plus we will be able to let you know if this is related to current server upgrades. Details/status about those here: https://biostar.usegalaxy.org/p/20733/#20854
Post here if you do not mind the history/workflow being accessible to all. Otherwise, a direct email with the links can be sent to galaxy-bugs@lists.galaxyproject.org (private list, internal to the team running the http://usegalaxy.org server). Please include a link to this post and send from your registered Galaxy account, if you choose to send an email. If there is a history that contains errors from the partial workflow run, that can be shared too (direct bug report). Please leave datasets (inputs/error jobs) undeleted.
How to share any Galaxy object with a link: https://wiki.galaxyproject.org/Learn/Share
Thanks! Jen, Galaxy team
I also ran into an issue with workflow but I am not sure if it is related to the issue mentioned here.
Yesterday I ran some workflows that had previously ran smoothly. Here is a link to the workflow:
https://usegalaxy.org/u/sushivision/w/mm9-mf10-noref-161207
Basically the main work flow goes like this: (1)input --> (2)mapped with bowtie --> (3)converted to bam --> (4)MACS --> (5)converted from wig to bigwig
The workflow also branches out with with (1)input -> FastQC and (2)bowtie (sam) -> (invisible internal BAM conversion) -> Flagstat
However this time the workflow only proceeded with the initial steps, i.e (1), (2) and (3) and FastQC. Flagstat and MACS (along with its downstream conversion) did not run --- did not appear in the history at all. (When I initiated the workflow all processes invoked were present, however.) I had to manually run the downstream steps myself, which offset the advantages of using workflow.
I hope that this is a temporary issue related to the move and would be resolved soon.
Bao
Hi Jennifer,
Just tried and the problem persists.
Seems similar with the issues raised by Bao.
My workflow is NOT top secret :) and may be found here: https://usegalaxy.org/u/mike-2/w/diff1
Thanks for investigating!
Mike
There seems to be a problem with input datasets being copied to a new history (when that is a selected option). This is causing the outputs of other steps (like FastQC) to be sent to the mapping tool, instead of the fastq data. Reviewing with team to see if a known issue.
A work-around could be to not send the results to a new history - testing that now.
More feedback soon & thanks for reporting the problem. Jen
Running the workfow in the same history as the inputs does use the correct inputs, but the launched jobs are not complete. There are several workflow changes in progress and this may be related. No ticket yet, team reviewing, but I will post one back (or let you know that this is already fixed) once more is known. Jen