I just changed to a really big value. (9 was considered big many
years ago!)
On Thu, Jun 10, 2010 at 9:49 AM, Matthew Chambers
wrote:
> Unless there are indeed downstream problems, it would be good to change that
> default upper scan number since others are running into the problem and it's
Unless there are indeed downstream problems, it would be good to change
that default upper scan number since others are running into the problem
and it's a pretty obscure source of error.
Dave, the peak filtering has been in msconvert for several months, so
presumably users can now convert str
Brian,
I've just had a second look and found the reason the conversion stops at
scan 9:
The default upper scan number in the options struct is set to 9:
MzXML2Search.cxx:117
iLastScan = 9;
Then just before the main loop it's used to set the value used to
terminate the main loop:
Returning to the behavior of mzXML2Search, just eyeballing the code I don't
see any reason it should fail at scan numbers > 9. Perhaps the problem
is actually downstream from mzXML2Search? While mzXML2Search should quite
happily emit 6 digit MGF scan numbers, I can imagine a consumer of MGF m
Matt,
We just apply a (low) absolute threshold. Different values for different
instruments, but it's most critical on the Agilent and Water's QTOFs, as
without any threshold there are 1000s of peaks.
Look forward to seeing the filtering in msconvert.
DT
Matt Chambers wrote:
> What kind of t
What kind of thresholding do you do? Enabling that in msconvert is
overdue - the backend code to support it is already in place.
MzXML2Search is failing because it depends on a strict DTA name scheme
with 5 digits. This is going to break with long LTQ Velos runs so it
needs to be fixed regardl
