illumina2srf error: .params file not found

[Pepe]

Hi all,

I'm running the illumina2srf script on my Solexa runs to generate the correspondent srf files. During the processing of every tile it gives me this error:

Processing tile s_x_xxxx_seq.txt
../.params: No such file or directory
../../.params: No such file or directory

and then goes on processing the tile. At the end I have a valid srf file that I can play with, so it doesn't seem to be a fatal error, although a little anoying.

I've looked for that file all over the folders I'm allowed to access to retrieve my sequences, and I'm sure it doesn't exist in there (just so there is no wasting of time: I know it's a hidden file/folder, I've included those in my search too).

My problem comes down to this: Does anyone knows if this .params file/directory is fatal, therefore I need to request the creation of the file/folder to the sequencing facility, or can I live without it?

Thanks in advance. Just to mention, this is my first post although I've been following this forum for a while, and I wanted to say that it's been a great place to learn, and I'm looking forward to be an active member now that I'm starting with my analyses.

Thank you all.

[jkbonfield]

These files used to be there in the previous incarnation of the pipeline software, but have since been renamed to config.xml. The code should be storing the .xml files instead now and I think I've already sent a patch to Illumina to cure this error.

As you've observed though, it's simply a warning rather than a real problem in SRF generation. Anyway the following diff (admiteddly untested - I just quickly hacked the source) should remove the warnings.

James

[edit: fixed name of config.xml]

[Pepe]

Thanks James,

before I start with the patching, is there any gain in the srf generation by using the config files, or I'm I going to be OK with the old srf files?

Sorry for the trouble.

[jkbonfield]

The output shouldn't change at all with that patch. All I did was made it not attempt to load the .params files when running in pipeline v1.3 mode.

Ie I shut up the incessant whinging. :-)
You can just ignore them if you prefer.

James

PS. There are more serious issues that need dealing with in that code though (not least of which is the ghastly mess it's slowly turned into). Currently it doesn't seem to support multiplexed ("index"ed) samples and has no way of specifying the region components for these in the SRF file.

[Pepe]

OK,

I think I'll skip the patch, then. I don't mind getting the messages as much as screwing something up on my srf files.

Thanks for your replies.

Cheers

[alex_kozik]

Hi James,

Thank you for the explanation and the patch. I think, I am in confusion where to access the latest version of illumina2srf source code. Is it available at SourceForge (io_lib)?

http://sourceforge.net/project/showfiles.php?group_id=100316&package_id=108243

http://sourceforge.net/project/shownotes.php?group_id=100316&release_id=646241

As I know, Illumina maintain its own branched version of io_lib. It's integrated with Illumina pipeline. Is it possible to compile it (io_lib) and get illumina2srf executable without compilation the whole pipeline?

-Alex

[jkbonfield]

I am indeed the original author of illumina2srf, although looking at the code I'm somewhat ashamed of it now! It's a truely ghastly mess. That's mostly down to me I should add - I'm not complaining about the changes others have made.

It was written initially as a means to test the validity and suitability of the SRF format. It's all well and good being part of a committe to design a new file format, but until it's actually implemented and worked with for a while you really can't tell if it's "going to fly". Hence illumina2srf (then solexa2srf). It kinda grew out of an initial test hack into a full production program, as so often happens.

I persuaded (I hope!) Illumina that it was in their interests to maintain the code themselves from here on. Admittedly I was doing this
because I simply don't have time what with gap5 and other things, but I do genuingly believe the program (or something performing the same task) belongs with the pipeline software and not a third-party set of tools.

Hence I drew a line under this in io_lib. The last version there quite deliberately doesn't deal with the qseq format in v1.3. Illumina themselves made those modifications and so the latest version is the one shipped with their pipeline. The same goes for the srf2illumina program too of course.

That said, the machine agnostic tools like srf2fastq are fine as part of io_lib and we intend to keep maintaining and extending these.

James