Can you calculate amounts for unnamed peaks?

Im trying to calculate amount for peaks that are not named in my comp editor, is this possible? I'm running related impurities samples and I'm trying to quantify the amounts off the bracketing standards but of course the only named component in the standards is the active peak. 
There are up to 50 peaks in the samples (100 min run time) so I don't name all these peaks. Right now I use excel spreadsheets for the calculation but was wondering is there any way Empower can do amounts for the unknown peaks or is this not possible?

Best Answers

  • Accepted Answer
    Couldn't you add all the peaks automatically (the button left of Apply Method Set in the main Review Window)? That way all get names as PeakX (Peak 1, Peak 2, Peak 3) and then you just set the CurveReference to your main peak?
  • Accepted Answer
    I'm quite certain that yes, you need to name a peak. Like Dan said, if you set* the main peak  and then apply your method set all peaks will be named RRT x.xx (regarding the main component). 


    *To get peaks named by RRT go to the Components window, click the dropdown menu of "RT Reference Used To name Unnamed Peaks by RRT" and choose your main peak.
  • Accepted Answer
    To quantify unknown peaks, one just needs to set the main peak as 'default peak' in the PM, (just checkmark it in the column 'default peak'). However, this will not help, if you need to perform any kind of intersample calculation. The "RT Reference Used...." won't help either, because the RRT is calculated for each injection and it is very probable, that the value for the RRT of a component will shift a little, what would in fact mean, that the name for the same component will also be different from injection to injection. Currently, there is no automatism implemented in Empower to take this into account. One would need to assign peak names manually, adjusting the retention times against each chromatogram. (or excel;-)

Answers

  • Hi DavidHPLC, yes I will try that. I presume then you need to have SOME kind of name (Peak1,2 etc) on a peak before Empower can calculate amounts? 
  • If "unknown peaks" is checked in the processing method, Empower will name them according to their relative retention times if a retention reference is found among named components. Otherwise, I think it just goes by RT.
  • Thanks guys for the answers. I will keep that in mind for when we upgrade to Empower 3- we are still on Empower 2!!
  • edited March 2018
    Create a custom field to calculate your amount. Set the custom field to run on unknown peaks (or all). 

    I setup an impurity analysis where there were named and unnamed impurities for a client. We didn't want to deal with the Peak 1, Peak 2, etc for unnamed. So, I just left the unknown peaks unnamed and told the custom fields to run on unknown peaks. 

    The approach worked like a charm. 

    If you want to get really fancy you can then also group those unnamed peaks in a report in accordance with RRT to a defined user tolerance (to account for minor peak shifting).
  • shaunwat said:
    Create a custom field to calculate your amount. Set the custom field to run on unknown peaks (or all). 

    I setup an impurity analysis where there were named and unnamed impurities for a client. We didn't want to deal with the Peak 1, Peak 2, etc for unnamed. So, I just left the unknown peaks unnamed and told the custom fields to run on unknown peaks...
    Having trouble w/ this in a pharma calcs setting.
    I get Amounts for named and unknown peaks,
    I have AveWt for the samples sorted, I can also get the product of AveWt x Amount, but for reasons unknown, I'm unable to get Empower to multiply that result by 100 and then divide by the label claim (component CF). Also, whenever I add an unknowns group to the Impurity tab, choose "unspecified impurity" and "Not Calibrated, Sum Peaks for Quantitation", my unknown peaks come up named with a RRT based on the main component but with no Component Type, so the line corresponding to the unspecified impurities remains blank... I feel that I'm missing something very basic here but can't figure out what it is!
    The CFs I'm using to calculate these impurities vs. the main component are set to work on all peaks. The parts work, but the CF that calls on the parts does not.
    I have tried to be mindful of the naming of the CFs (my consitiuent CFs work, are named with capital letters so they'll be sorted before my %impurity calc is attempted, that field has a lower case first letter). 
  • Dan, how is AveWt calculated? Is it a sample, real custom field where you enter the value for each line/sample in the sample set or is it another custom field? 
  • CF, sample, real, keyboard input if memory serves.
  • I don't know why, based on what you say, it wouldn't calculate this. Have you some peak type or sample type constraint in the custom field? What about your search order? Are you processing from Injections but have Result Set Only set? You could try putting the Label Claim in CConst1 instead, maybe there is a difficulty combining sample and component fields..
    Or another option is to use the Sampleweight and Dilution fields as the divisor and multiplier, but that presumes you only have one component for the label claim value and also presumes you aren't already accounting for sample weight and dilution by having values in these for your samples. You might try making the 100/LabelClaim as a separate peak CF and multiply your first CF by this. Sometimes custom fields sound great on paper but don't actually work in practice. 

    A really obvious one but do you by chance only have values for "LabelCLaim" in the "Standards Only" view of that component custom field? Standards Only is the default view for component cfs. If you click the drop down and select "Standards and Unknowns" then put in the relevant values for the samples where you want this CF to work. 


    As for the named group issue, maybe try a different option for the source of calibration x value, I believe there are 3 options. Your option might not be suitable. 
  • edited June 25

    RE: AveWt question- 
    Confirming that AveWt is a Keyboard entered, Real, Sample CF that defaults to 1 (no restrictions possible on anything else for this).

    RE: sets vs. injections - I usually process as sets.

    RE: label claim in CConst1... - This gets me back to a 1 component limit as CConsts are sample level fields.

    RE: sampleweight/dilution... - Right, not good for multiple actives and I do have sample weight and dilution entries as well as AveWt, so everything needed is in there.

    RE: ...making the 100/LabelClaim as a separate peak CF and multiply your first CF by this... - I tried something similar to this approach. I made:

    • Mg_sdf (as in milligrams solid dosage forms) with the formula: Amount*AveWt, peak, real, calc’d, search: result set only, spl: unknowns only, peak type: all
    • aa formula: Mg_sdf*100, peak, real, calc’d, search: result set only, spl: unknowns only, peak type: all
    • bb formula: 1/Label__Claim, peak, real, calc’d, search: result set only, spl: unknowns only, peak type: all
    • and cc, formula aa*bb, peak, real, calc’d, search: result set only, spl: unknowns only, peak type: all

    note that Label__Claim is a component field, real, keyboard CF that defaults to 1.

    Results: Mg_sdf, aa, bb, and cc all populate for the default (main API) peak. Mg_sdf and aa populate for all named peaks and unknown peaks. bb and cc don’t populate for anything but the default peak. ☹ It seems that Empower is just refusing to deal with unknown peaks in terms of the Label__Claim CF despite having entered a label claim for the default peak in the component table of the sample set. Component Names match those of the processing method...

    Also, Label__Claim is entered only for Unknowns. A Value is entered for standards (a concentration in mg/mL that takes dilution, moisture and purity factors into account). For "Value", samples get a 1 by default and for Label__Claim, standards get a 1 by default. This all works great for assays. It just breaks down with unnamed/unknown peaks.

    As for Group sources of X value - I think I've tried all 3 to no avail. I get named stuff only.

    Any other suggestions?
  • Hi Dan, thanks for the extra information. A few suggestions:

    I think the issue here can be traced back to the Default Peak. There has to be some "link" back to whatever peak is selected as the default peak when it comes to multi-section formulas. First the obvious things: Is the default peak box definitely ticked and do you have ranges set up as in Default Peak start and end? 

    I use several cfs including the default peak to calculate amounts for both knowns and unknowns but they are all the one formula. I think breaking up the cf formula, although I advised this, may confuse Empower when it comes to default peak. 

    Is it possible instead to incorporate the entire CF as one CF using well-placed brackets? Throw your main API peak as CCalRef1 in the processing method. So as a suggestion, peak real cf result set only all peaks and only unknown samples:

    ((Amount*100*AveWt))*((1/CCalRef1[Label_Claim]))

    Hope that helps. I think if you can get that to work it may link up to getting the source of calibration issue resolved. 




  • Start and end times are not being used. I tried it, did not help.
    What I have discovered is that if I change the PM's RT Ref. from my main peak to blank, I get full calculations for my percent impurities, but no names for the unknown peaks. If I put the main peak back in the RT Ref. drop down, I get RRT~n.nnn for my unknown peak names, but the percent impurity calculations are gone. Someone at Waters has a copy of the project and has seen this happen. They are working on it. In the mean time, I need to be happy reporting my unknowns by RT only, or I need a new CF that works to provide RRTs for the unknowns even if the RT Ref. is selected in the processing method (I have one already, but it quits when the peak IDs do).

    I *really* do not want to rely on CCalRef1 because of the multi component issue and I don't think I can rely on end users to enter that reliably.
    I have tried the complete formulas to no avail, though I have not tried them with some extra parentheses...

    I'll update this if I find anything new.
    Thanks for the replies!
  • Let us know Dan if anything new pops up here, I don't really know whats going on there with not getting answers like that. Good luck. 
Sign In or Register to comment.