Please add the STR detection tool

Please add a new STR detection (for short read, reference, and mapped data) tool at the, thanks!

Hi @libinglin

Did you fix your reference fasta and quality filter the SAM already, and it still failed at I would be curious about reviewing that new job as a benchmark. Maybe we can increase the memory resources. You can send in a new bug report for it – put the URL link to this topic in the comments section, then let us know back here once done and I’ll look for it. Or, post the history share link here please. Either is fine for this one.

If I am mixing up who asked about that already, apologies! We can still follow up with your current problem. :slight_smile:

And, we can ask the EU team about this. I don’t see any tools from the STR-FM: Microsatellite Analysis tool group hosted there, which seems a bit odd but might be on purpose, or might be an oversight. ping @wm75 can you help? Am I missing something? Thanks!

I find the Show-Coords tool is running fine! (The first route is working fine)
I’m running my workflow and I’m getting an error with STR-FM (the second route), I can’t find the STR detection tool in the Europe platform.
I used two servers separated for analysis and then combined them manually. This is too much of a hassle, thanks!


Possibly not enough running memory of Show-Coords tool in the U.S. platform

1 Like

Hi @libinglin

This is a different tool, and is hosted at Direct link → Galaxy

Correct. I reviewed this one too already. Try at the EU server to see if the data can be processed.

Only run half of my workflow (needs to be split).

change to the new?

Ok, I re-read. You want to run both tools.


STR detection

  • tool_id
  • not available at (we are checking why)
  • not sure if it runs at, plus would involve splitting the workflow between two servers (not a great solution)

Let’s see what the EU has to say about the tool install. Because of time differences, this will likely take a day or two for feedback, then maybe longer for the actual installation.

You could split the workflow. Run through the steps up through needing this tool at the ORG server, export the history to the other, then run the second part. Meaning, you don’t need to map twice. Or, you can wait for feedback.

Yes, I want one platform( or where I can run all tools of this workflow, thanks!
When we set up the workflow, the STR detection is running fine at, and all analysis tools.

So the STR_FM suite of tools hasn’t been updated since 7 years and has accumulated several problems over this time, which make it hard now to install it on a Galaxy server. For example, the tool doesn’t specify requirements, but still depends on Python2 (which is unsupported since a while), instead of Python3.

In general, we are not opposed to making things possible for our users on Galaxy Europe, but are you sure there isn’t a better workflow for what you are trying to achieve, than one composed of tools (mummer is also not exactly new) from many years ago?

1 Like

Maybe the original author of STR_FM can give some recommendations if you’re asking at GitHub - Arkarachai/STR-FM?
Also @marten, it seems you have been involved many years ago in bringing the suite to - maybe you can comment on this?

such as the STRait Razor?

We build the analysis workflow for my job on the Galaxy (website), and we found the “STR decation” and “Nucmer” tool at the Currently we have not found any other replaceable analysis tools on the platform, e.g. STRait Razor, STRinNGS v2.0… And the other tools were not tested. Thanks!

I’m personally not an expert in microsatellite analysis. If you can provide us with a list of tools you’d want to see in Galaxy to build your ideal workflow (along with an outline of what that workflow would look like) that’d be a starting point and we can see what it takes to bring them to the platform.

I’m sorry. I’m actually a user based on the available tools. I will read this paper to find better analysis software. Thanks!

I assume we could update the str_fm wrapper to require python 2.7 and things would work as they were?

I don’t know the toolshed repo bundles lots of wrappers that don’t declare requirements. Haven’t checked whether all of them would work with Python as their only dependency.