ReadW and charge state

[John Damask]

Hi,
I'm confused about how charge state info is passed along the pipeline.
Our orbitraps are set to enable charge state screening (Data dependent
settings->segment->charge state->enable charge state screening) and we
observe charge annotation in the RAW files (via qual browser).
However, ReadW (both from Squall 3.3 and 3.4) doesn't seem to find/use
these and the subsequent mzXML files lack this metadata.

C:\TEMP>c:\cygwin\bin\readw 20071210_9-Pep-iTRAQ_100fmol_PQD2.RAW c
Saving output to 20071210_9-Pep-iTRAQ_100fmol_PQD2.mzXML
Converting to centroid
Processing header
Calculating sha1-sum of RAW
Processing scans
Writing the index
Calculating sha1-sum of mzXML
Inaccurate Masses: 241
Accurate Masses: 315
done

Am I missing something??? I've read several posts on this forum which
indicate that charge states from RAW files, if present, are extracted.

Thanks for any help,
John

[Joshua Tasman]

Hi John,

Currently, the released version and latest source code versions have different behaviors. I can point you to the latest beta version if you're interested; let's continue off-list.

Josh

[Matthew Chambers]

Josh, until the beta version of Readw officially replaces the release
version, it would be a good idea to document the differences somewhere.
I didn't respond to this because I couldn't remember the difference
between how the two versions handled charge states. :)

-Matt

[Jimmy Eng]

The charge attribute for scans when available, that you can see in Qual
Browser, has been supported in ReAdW for at least a couple of years now
(including much earlier than ReAdW from 3.3 and 3.4). So it's
surprising to hear that the charge state info isn't supported. John, do
your mzXML files not have the text string 'precursorCharge=' in them at all?

- Jimmy

[John Damask]

Jimmy, I've grepped several directories of mzXMLs from different
instruments (all orbis) and I don't find 'precursorCharge' (or even
'charge') in any.
btw we have xcalibur v 2.0.6 on my TPP server

Thanks,
John

[Jimmy Eng]

John,

Can you send me one RAW file? I'm curious enough (and a test conversion
is quick enough) that I'd like to test it myself. If it's OK, we'll
coordinate off this list to xfer a file.

- Jimmy

[Edwin Lowe]

I've noticed that the version of ReadW that ships with Labkey CPAS does add
the charge state information, whereas the version with TPP doesn't. It
makes a huge difference to the search so it would be good if perhaps the TPP
version was the same as the CPAS one.

Edwin

[Jimmy Eng]

I guess this means we're still distributing a _really_ old version of
ReAdW with the TPP package and no one ever thought to update it. If
that's the case, until the next TPP is released feel free to grab a
ReAdW binary that does add precursor charge information from:
http://sourceforge.net/project/showfiles.php?group_id=69281&package_id=68160

[John Damask]

you know, I see something funny - I found a collaborator's old RAW
file and ran ReAdW...low and behold, charge states. Ok, so what's
different?
Their RAW file was created with an older version of Xcalibur (and Tune
+...I'm told it was a developer's kit version at the time)
<software type="acquisition"
name="Xcalibur"
version="2.0"/>

Our instruments are all using later versions...mzXML files of ours
show the acquisition software as >= 2.2

On Feb 28, 5:22 pm, Jimmy Eng <j...@systemsbiology.org> wrote:
> I guess this means we're still distributing a _really_ old version of
> ReAdW with the TPP package and no one ever thought to update it. If
> that's the case, until the next TPP is released feel free to grab a

> ReAdW binary that does add precursor charge information from:http://sourceforge.net/project/showfiles.php?group_id=69281&package_i...

[John Damask]

I think you're right Jimmy.
Sourceforge version of readw produces charge states. I'll test on
other files and write back if there are problems.

Thanks a lot for the help guys,
John

[Joshua Tasman]

Hi all,

I'm in charge of building and releasing the converters and the TPP, and I'm a bit confused. The version of ReAdW distributed in the TPP (at least for the last half year or more) is exactly the same as the file in the SourceForge link Jimmy sent.

Maybe the installer isn't correctly overwritting an existing ReAdW binary you might have?

John, can you please upload the binary you have been using to our FTP site so I can try to understand the situation?

Thanks,

Josh

[John Damask]

<sigh> - ok, my dev box has Squall 3.4 and that's where
ReAdW_2006Nov01.exe seemed to do the trick. However, my production box
is Squall 3.3 and running ReAdW_2006Nov01.exe against the same RAW
file did not give charge states.

Josh, I'm behind firewall so I'll try to upload the readw tonight.

thanks,
John

[Joshua Tasman]

Thanks, John. Can you also post the full Xcalibur version (with any patches) on both machines?

Josh

[John Damask]

Well I'm at a loss...for the same file, ReAdW.exe correctly parses
charge states from my dev box but not production (see below). I've
reinstalled TPP and XCalibur, ensured the same versions of each, etc.
The only thing I can think of is that the prod box is a Windows 2003
server whereas dev is XP pro...maybe it's a Windows MFC thing?
Josh, I'm not a C++ guy - could you compile a new readw with a print
statement in the charge state conditional? I'd like to see which part
of the code misses the line.

if( m_xRawfile.GetTrailerExtraValueForScanNum(m_scanNum, "Charge
State:" , &varValue ))
{ // First try to use the OCX
if( varValue.vt == VT_I2 )
{
m_precursorCharge = varValue.iVal;
}
}

Thanks,
John

Dev:
C:\TEMP\MarkusTest\BSA_25fm_114>c:\cygwin\bin\readw.exe
BSA_25fm_114.RAW c
Saving output to BSA_25fm_114.mzXML

Converting to centroid
Processing header
Calculating sha1-sum of RAW
Processing scans
Writing the index
Calculating sha1-sum of mzXML

Inaccurate Masses: 0
Accurate Masses: 234
Charge 2: 183
Charge 3: 50
Charge 6: 1
done

Prod:
C:\Temp\MarkusTest>c:\cygwin\bin\readw.exe BSA_25fm_114.RAW c
Saving output to BSA_25fm_114.mzXML

Converting to centroid
Processing header
Calculating sha1-sum of RAW
Processing scans
Writing the index
Calculating sha1-sum of mzXML

Inaccurate Masses: 0
Accurate Masses: 234
done

[Matthew Chambers]

Wow, that is weird. It is getting the accurate m/zs in both cases, and
that is through the same GetTrailerExtraValueForScanNum call that's not
working for the charge state call. Can you see the charge state trailer
value in Qual Browser on the 2003 box?

-Matt

[John Damask]

Yes - under "LTQ Orbitrap Data" in the scan header...that is the
section where this information is pulled from, right?

John

On Mar 3, 4:13 pm, Matthew Chambers <matthew.chamb...@vanderbilt.edu>
wrote:

[Matthew Chambers]

Yes. What about using the XRawfileTest.exe from the XDK? If you don't
have the XDK or a way to build that app, you can download it from my server:
http://fenchurch.mc.vanderbilt.edu/files/XRawfileTest.exe

XRawfileTest uses the same mechanism to get the trailer values as Readw,
so I'd be very surprised if it worked and Readw didn't.

-Matt

[Edwin Lowe]

Just a thought ... With the Labkey 2.3 release there was some problems with
ReadW ..

https://www.labkey.org/announcements/home/CPAS/support/thread.view?rowId=202
6

It was to do with the MFC version ... might be worth a look

Edwin

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com] On Behalf Of Matthew Chambers
Sent: Tuesday, 4 March 2008 7:14 AM
To: spctools...@googlegroups.com
Subject: Re: ReadW and charge state

[Edwin Lowe]

Im happy to try out any version of ReadW if you want a different PC to try
it on. I also have Xcalibur 2.0 SR2 and 2.0.5 to test on.

Edwin

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com] On Behalf Of Matthew Chambers

Sent: Tuesday, 4 March 2008 7:14 AM
To: spctools...@googlegroups.com
Subject: Re: ReadW and charge state

[Joshua Tasman]

Thank you, Matt-- this is the correct direction for debugging, John. Use Xcalibur's own program to look at the .raw file, and we can figure out if this is a readw or Xcalibur problem.

Josh

[John Damask]

Thanks for the input guys. Edwin, I followed the labkey link but
didn't see mention of MFC.

Here's an update:

On my Windows Server 2003 production box charge states appear via
XRawfileTest.exe - which makes sense because they're also present in
Qual Browser. Actually, I would suspect this behavior since
XRawfileTest (and probably Qual Browser) simply iterates over the
extra data array.

As I see it, there are three points in the readw code where charge
state assignment could fail: 1) data lookup; 2) data type check; and
3) charge state var set.
1) readw performs a lookup of "Charge State:" by name - this probably
gets translated into a hash lookup or regex by XRawfile but I don't
think that matters. Since readw's charge state retrieval works fine in
most cases I'd suspect that the object is being returned here, too.

2) This is a point of interest: readw checks if the datatype is a
VT_I2, 2 byte signed int, if not the code falls through. Perhaps
Windows Server 2003 returns a VT_I4 or other datatype here?

3) Setting the var includes retrieving the iVal from varValue....I
doubt this is the culprit since if the varValue was found and passed
the data type check then the iVal should be present

So my money (monopoly money, of course) is on #2. Any thoughts?
I spend my days in Java so this C++ stuff looks pretty greek - I'll
try to find someone with basic knowledge around here so I can test my
theory. However, If any of you C++ folks want to add this additional
check I'd very much appreciate it!

John

[Brian Pratt]

If you haven't already done so, it's probably time to convince yourself
(perhaps even by means of binary file comparisons) that exactly the same
build of XCalibur is installed on both machines. Or possibly to go to a
third machine and see which way things fall?

With sympathy,

Brian

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com] On Behalf Of John Damask
Sent: Tuesday, March 04, 2008 8:41 AM
To: spctools-discuss
Subject: Re: ReadW and charge state

[Edwin Lowe]

Hi John ..

The link got split over a line. I think there was a 6 missing at the end ...
anyway sounds like you know what you're doing.

One thing .. I've had versons of ReadW that do and don't detect the charge
state on exactly the same computer with exactly the same version of
Xcalibur. The one that is distributed with CPAS works for me .. the one
with the TPP doesn't :-(

Edwin

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com] On Behalf Of John Damask
Sent: Wednesday, 5 March 2008 3:41 AM
To: spctools-discuss
Subject: Re: ReadW and charge state

[Matthew Chambers]

#2 seems interesting. I reviewed the code in XRawfileTest and it
accesses the trailer data in a different way. It gets both arrays
separately (labels and values) and treats them all as strings. So it
could indeed be that Windows 2003 returns a different variant type, but
I find that unlikely unless you are on a different architecture (64
bit?). Do you have terminal services on that machine that Josh or I can
use to test?

-Matt

[Greg Bowersock]

I'm not sure of the exact version of readw that I have, but the version that I have works the same on XP as server 2003, and both have Excalibur 2.0.6. If you want to try it, you can grab it from: http://uro-apps.urology.uab.edu:7070/readw.exe

 

 

Greg

 

[Matt Chambers]

Hi Greg, are you testing on data with charge states available to extract?

-Matt

Greg Bowersock wrote:
> I'm not sure of the exact version of readw that I have, but the
> version that I have works the same on XP as server 2003, and both have
> Excalibur 2.0.6. If you want to try it, you can grab it from:
> http://uro-apps.urology.uab.edu:7070/readw.exe
>
>
> Greg
>
>

> On 3/4/08, *Matthew Chambers* <matthew....@vanderbilt.edu

> <mailto:jtas...@systemsbiology.org>> wrote:
> >
> >> Thank you, Matt-- this is the correct direction for debugging,
> John. Use Xcalibur's own program to look at the .raw file, and we
> can figure out if this is a readw or Xcalibur problem.
> >>
> >> Josh
> >>
> >> Matthew Chambers wrote:
> >>
> >>> Yes. What about using the XRawfileTest.exe from the XDK? If
> you don't
> >>> have the XDK or a way to build that app, you can download it
> from my server:
> >>> http://fenchurch.mc.vanderbilt.edu/files/XRawfileTest.exe
> >>>
> >>> XRawfileTest uses the same mechanism to get the trailer values
> as Readw,
> >>> so I'd be very surprised if it worked and Readw didn't.
> >>>
> >>> -Matt
> >>>
> >>> John Damask wrote:
> >>>
> >>>> Yes - under "LTQ Orbitrap Data" in the scan header...that is the
> >>>> section where this information is pulled from, right?
> >>>>
> >>>> John
> >>>>
> >>>> On Mar 3, 4:13 pm, Matthew Chambers
> <matthew.chamb...@vanderbilt.edu

> <mailto:matthew.chamb...@vanderbilt.edu>>

> <jtas...@systemsbiology.org <mailto:jtas...@systemsbiology.org>>

> wrote:
> >>>>>>
> >>>>>>> Thanks, John. Can you also post the full Xcalibur version
> (with any patches) on both machines?
> >>>>>>>
> >>>>>>> Josh
> >>>>>>>
> >>>>>>> John Damask wrote:
> >>>>>>>
> >>>>>>>> <sigh> - ok, my dev box has Squall 3.4 and that's where
> >>>>>>>> ReAdW_2006Nov01.exe seemed to do the trick. However, my
> production box
> >>>>>>>> is Squall 3.3 and running ReAdW_2006Nov01.exe against the
> same RAW
> >>>>>>>> file did not give charge states.
> >>>>>>>>
> >>>>>>>> Josh, I'm behind firewall so I'll try to upload the readw
> tonight.
> >>>>>>>>
> >>>>>>>> thanks,
> >>>>>>>> John
> >>>>>>>>
> >>>>>>>> On Feb 28, 6:03 pm, Joshua Tasman

> <jtas...@systemsbiology.org <mailto:jtas...@systemsbiology.org>>

> wrote:
> >>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>>
> >>>>>>>>> I'm in charge of building and releasing the converters
> and the TPP, and I'm a bit confused. The version of ReAdW
> distributed in the TPP (at least for the last half year or more)
> is exactly the same as the file in the SourceForge link Jimmy sent.
> >>>>>>>>>
> >>>>>>>>> Maybe the installer isn't correctly overwritting an
> existing ReAdW binary you might have?
> >>>>>>>>>
> >>>>>>>>> John, can you please upload the binary you have been
> using to our FTP site so I can try to understand the situation?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Josh
> >>>>>>>>>
> >>>>>>>>> John Damask wrote:
> >>>>>>>>>
> >>>>>>>>>> I think you're right Jimmy.
> >>>>>>>>>> Sourceforge version of readw produces charge states.
> I'll test on
> >>>>>>>>>> other files and write back if there are problems.
> >>>>>>>>>> Thanks a lot for the help guys,
> >>>>>>>>>> John
> >>>>>>>>>> On Feb 28, 5:51 pm, John Damask <jbdam...@gmail.com

> <mailto:jbdam...@gmail.com>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> you know, I see something funny - I found a
> collaborator's old RAW
> >>>>>>>>>>> file and ran ReAdW...low and behold, charge states.
> Ok, so what's
> >>>>>>>>>>> different?
> >>>>>>>>>>> Their RAW file was created with an older version of
> Xcalibur (and Tune
> >>>>>>>>>>> +...I'm told it was a developer's kit version at the time)
> >>>>>>>>>>> <software type="acquisition"
> >>>>>>>>>>> name="Xcalibur"
> >>>>>>>>>>> version="2.0"/>
> >>>>>>>>>>> Our instruments are all using later versions...mzXML
> files of ours
> >>>>>>>>>>> show the acquisition software as >= 2.2
> >>>>>>>>>>> On Feb 28, 5:22 pm, Jimmy Eng <j...@systemsbiology.org

> <mailto:j...@systemsbiology.org>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I guess this means we're still distributing a
> _really_ old version of
> >>>>>>>>>>>> ReAdW with the TPP package and no one ever thought to
> update it. If
> >>>>>>>>>>>> that's the case, until the next TPP is released feel
> free to grab a
> >>>>>>>>>>>> ReAdW binary that does add precursor charge
> information
> from:http://sourceforge.net/project/showfiles.php?group_id=69281&package_i.

> <http://sourceforge.net/project/showfiles.php?group_id=69281&package_i.>..

[Greg Bowersock]

Yes, we are able to get charge state information (up to 5 in our triple play zoom scan runs, 10 if we use ultra zoom) from our LTQ XL. I normally convert files on an XP box, but I verified last night that it worked with 2003 server also.

 

Greg

 

[Matthew Chambers]

That's good to know. Now I'm wondering about if John's 2003 machine is
64-bit.

-Matt

Greg Bowersock wrote:
> Yes, we are able to get charge state information (up to 5 in
> our triple play zoom scan runs, 10 if we use ultra zoom) from our LTQ
> XL. I normally convert files on an XP box, but I verified last night
> that it worked with 2003 server also.
>
> Greg
>
>

> On 3/4/08, *Matt Chambers* <matthew....@vanderbilt.edu

> <mailto:matthew....@vanderbilt.edu>> wrote:
>
>
> Hi Greg, are you testing on data with charge states available to
> extract?
>
> -Matt
>
>
> Greg Bowersock wrote:
> > I'm not sure of the exact version of readw that I have, but the
> > version that I have works the same on XP as server 2003, and
> both have
> > Excalibur 2.0.6. If you want to try it, you can grab it from:
> > http://uro-apps.urology.uab.edu:7070/readw.exe
> >
> >
> > Greg
> >
> >
> > On 3/4/08, *Matthew Chambers* <matthew....@vanderbilt.edu
> <mailto:matthew....@vanderbilt.edu>

> > <mailto:matthew....@vanderbilt.edu

> > <mailto:jtas...@systemsbiology.org

> > <mailto:matthew.chamb...@vanderbilt.edu

> <mailto:jtas...@systemsbiology.org

> <mailto:jtas...@systemsbiology.org>>>
> > wrote:
> > >>>>>>
> > >>>>>>> Thanks, John. Can you also post the full Xcalibur
> version
> > (with any patches) on both machines?
> > >>>>>>>
> > >>>>>>> Josh
> > >>>>>>>
> > >>>>>>> John Damask wrote:
> > >>>>>>>
> > >>>>>>>> <sigh> - ok, my dev box has Squall 3.4 and that's where
> > >>>>>>>> ReAdW_2006Nov01.exe seemed to do the trick. However, my
> > production box
> > >>>>>>>> is Squall 3.3 and running ReAdW_2006Nov01.exe
> against the
> > same RAW
> > >>>>>>>> file did not give charge states.
> > >>>>>>>>
> > >>>>>>>> Josh, I'm behind firewall so I'll try to upload the
> readw
> > tonight.
> > >>>>>>>>
> > >>>>>>>> thanks,
> > >>>>>>>> John
> > >>>>>>>>
> > >>>>>>>> On Feb 28, 6:03 pm, Joshua Tasman
> > <jtas...@systemsbiology.org
> <mailto:jtas...@systemsbiology.org>

> <mailto:jtas...@systemsbiology.org

> <mailto:jtas...@systemsbiology.org>>>
> > wrote:
> > >>>>>>>>
> > >>>>>>>>> Hi all,
> > >>>>>>>>>
> > >>>>>>>>> I'm in charge of building and releasing the converters
> > and the TPP, and I'm a bit confused. The version of ReAdW
> > distributed in the TPP (at least for the last half year or more)
> > is exactly the same as the file in the SourceForge link
> Jimmy sent.
> > >>>>>>>>>
> > >>>>>>>>> Maybe the installer isn't correctly overwritting an
> > existing ReAdW binary you might have?
> > >>>>>>>>>
> > >>>>>>>>> John, can you please upload the binary you have been
> > using to our FTP site so I can try to understand the situation?
> > >>>>>>>>>
> > >>>>>>>>> Thanks,
> > >>>>>>>>>
> > >>>>>>>>> Josh
> > >>>>>>>>>
> > >>>>>>>>> John Damask wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I think you're right Jimmy.
> > >>>>>>>>>> Sourceforge version of readw produces charge states.
> > I'll test on
> > >>>>>>>>>> other files and write back if there are problems.
> > >>>>>>>>>> Thanks a lot for the help guys,
> > >>>>>>>>>> John
> > >>>>>>>>>> On Feb 28, 5:51 pm, John Damask
> <jbdam...@gmail.com <mailto:jbdam...@gmail.com>

> > <mailto:jbdam...@gmail.com <mailto:jbdam...@gmail.com>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> you know, I see something funny - I found a
> > collaborator's old RAW
> > >>>>>>>>>>> file and ran ReAdW...low and behold, charge states.
> > Ok, so what's
> > >>>>>>>>>>> different?
> > >>>>>>>>>>> Their RAW file was created with an older version of
> > Xcalibur (and Tune
> > >>>>>>>>>>> +...I'm told it was a developer's kit version at
> the time)
> > >>>>>>>>>>> <software type="acquisition"
> > >>>>>>>>>>> name="Xcalibur"
> > >>>>>>>>>>> version="2.0"/>
> > >>>>>>>>>>> Our instruments are all using later versions...mzXML
> > files of ours
> > >>>>>>>>>>> show the acquisition software as >= 2.2
> > >>>>>>>>>>> On Feb 28, 5:22 pm, Jimmy Eng
> <j...@systemsbiology.org <mailto:j...@systemsbiology.org>

> > <mailto:j...@systemsbiology.org

> <mailto:j...@systemsbiology.org>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I guess this means we're still distributing a
> > _really_ old version of
> > >>>>>>>>>>>> ReAdW with the TPP package and no one ever
> thought to
> > update it. If
> > >>>>>>>>>>>> that's the case, until the next TPP is released
> feel
> > free to grab a
> > >>>>>>>>>>>> ReAdW binary that does add precursor charge
> > information
> >
> from:http://sourceforge.net/project/showfiles.php?group_id=69281&package_i

> <http://sourceforge.net/project/showfiles.php?group_id=69281&package_i>.

> >
> <http://sourceforge.net/project/showfiles.php?group_id=69281&package_i.
> <http://sourceforge.net/project/showfiles.php?group_id=69281&package_i.>>..
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> I've noticed that the version of ReadW that ships
> > with Labkey CPAS does add
> > >>>>>>>>>>>>> the charge state information, whereas the version
> > with TPP doesn't. It
> > >>>>>>>>>>>>> makes a huge difference to the search so it
> would be
> > good if perhaps the TPP
> > >>>>>>>>>>>>> version was the same as the CPAS one.
> > >>>>>>>>>>>>> Edwin
> > >>>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>>> From: spctools...@googlegroups.com
> <mailto:spctools...@googlegroups.com>
> > <mailto:spctools...@googlegroups.com
> <mailto:spctools...@googlegroups.com>>
> > >>>>>>>>>>>>> [mailto:spctools...@googlegroups.com
> <mailto:spctools...@googlegroups.com>
> > <mailto:spctools...@googlegroups.com
> <mailto:spctools...@googlegroups.com>>] On Behalf Of Jimmy Eng
> > >>>>>>>>>>>>> Sent: Friday, 29 February 2008 8:05 AM
> > >>>>>>>>>>>>> To: spctools...@googlegroups.com
> <mailto:spctools...@googlegroups.com>

> > <mailto:spctools...@googlegroups.com

> <mailto:spctools...@googlegroups.com>>
> > >>>>>>>>>>>>> Subject: Re: ReadW and charge state
> > >>>>>>>>>>>>> John,
> > >>>>>>>>>>>>> Can you send me one RAW file? I'm curious enough
> > (and a test conversion
> > >>>>>>>>>>>>> is quick enough) that I'd like to test it
> > myself. If it's OK, we'll
> > >>>>>>>>>>>>> coordinate off this list to xfer a file.
> > >>>>>>>>>>>>> - Jimmy
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Jimmy, I've grepped several directories of mzXMLs
> > from different
> > >>>>>>>>>>>>>> instruments (all orbis) and I don't find
> > 'precursorCharge' (or even
> > >>>>>>>>>>>>>> 'charge') in any.
> > >>>>>>>>>>>>>> btw we have xcalibur v 2.0.6 on my TPP server
> > >>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>> John
> > >>>>>>>>>>>>>> On Feb 28, 3:29 pm, Jimmy Eng
> > <j...@systemsbiology.org <mailto:j...@systemsbiology.org>

> <mailto:j...@systemsbiology.org <mailto:j...@systemsbiology.org>>>

[Greg Bowersock]

That is a possibility. Mine is capable of 64-bit, but I installed the 32-bit version instead. I'm not sure if it was due to sequest needing to be on a 32-bit box, but I know I did it for a reason. 2 of my servers that are identical I did put 64-bit on, and sequest is all that box does.
 

Greg
 

[John Damask]

Edwin, I found your CPAS post enlightening, particularly Brenden's
quote "ReAdW.exe is the only EXE that uses MFC (something to do with
its original creation)".

I copied CPAS' readw.exe to my Windows Server 2003 box along with
their included Microsoft.VC80.CRT, Microsoft.VC80.MFC, and zlib1.dll
and...it got the charge states! Sadly, I couldn't get it to convert to
centroid -beats the hell out of me why not- so I can't use it.

Greg, thanks for your version of readw - it works! I'm trying to
figure out why....Microsoft has some debugging tools for tracking
executable usage of DLLs and they've shot a hole in my MFC-version
theory: your readw and the ones from Squall 3.3 & 3.4 use identical
DLLs.

Matt, thanks for offering but I'm with Novartis and I doubt they'd
allow it.

Josh, in Squall 3.5 I see charge state code has been moved from
xml_out to ThermoInterface and modified...I look forward to trying it
out.

Even though the source of my problem hasn't been identified I'm about
to put this to bed...though it wouldn't surprise me if it reared up
again with a future version.

I really appreciate everyone's help and hope I get to assist you
sometime.
John

[John Damask]

btw - my server is running Windows as 32-bit

[Davis, Darryl [CNTUS]]

Hi,
Have been following thread and wondering where one would find the charge state if it existed. Opening up mzXML in textpad it is not ther but if i run either ver of Readw (CPAS 2.3 using 2.0schema or TPP using 3.0schema) the output shoes charges although i have to use -v to have 3.5.1 display it.

2nd question is zlib doing something other than compression?

3rd ? CPAS readw gives 6 dec. places for m/z while 3.5.1 gives 2. Is there a setting to change this?
DD

Darryl L. Davis, Ph.D.
Senior Research Scientist
Centocor, PD Analytical Development
145 King of Prussia Rd.
Radnor, PA 19087
610 240-8286
Fax 610 651-6986
MailStopR-1-1
CONFIDENTIALITY NOTICE : The information in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank You

-----Original Message-----
From: spctools...@googlegroups.com
[mailto:spctools...@googlegroups.com]On Behalf Of John Damask
Sent: Wednesday, March 05, 2008 4:21 PM
To: spctools-discuss
Subject: Re: ReadW and charge state

[Joshua Tasman]

Hi Darryl,

1. Charge state is recorded for each scan with msLevel > 1, if able to be determined:
<precursorMz precursorIntensity="863646" precursorCharge="1"

2. zlib is only used for compression

3. CPAS uses an older version of ReAdW. The newest version only reports 2 decimal points when the only value it can get is from the "filter line". It does not add precision when it's not there in the source.

Please also note this header info , which should give you a specific build number for current and future versions, when reporting issues:
<dataProcessing>
<software type="conversion" name="ReAdW" version="3.5.1 (build Mar 4 2008 16:01:29)" />

Hope this helps,

Josh

[Davis, Darryl [CNTUS]]

Thanks Josh. Found the line for charge state and found that indeed 3.5 has acc m/z for some scans.

The zlib ques was aimed at trying to understand why anecdotally at least some of readw and mzwiffs 3.5 issues seem to be zlib related.