v0.5.5-alpha

[bowring]

What's Changed

• File and analysis handling by @bowring in File and analysis handling #260

Full Changelog: v0.5.4-alpha...v0.5.5-alpha

---

This discussion was created from the release v0.5.5-alpha.

[YakovYermakov]

Hi!

When I import a .timsdp file, Tripoli opens the preview and sculpt mode immediately, with all the data included. In old Tripoli it firstly asks me what data to graph, and only then shows graphs. For example, while working with Pb data, I don't need alpha ratios and 204, 206, 207, 208 Pb counts.
I think it would be handy to ask what data to sculpt before opening the window with graphs. Also, the good Idea is to create presets for specific TIMS methods (where data you don't usually use already unchecked).

Another issue that I have is the control settings. I cannot get used to these combinations with ctrl+ left or right mouse. Maybe it's my personal problem, but I would like to discuss it. I feel that the current way to manage and sculpt data is counterintuitive. I will try to make more specific suggestions about it later.

[bowring]

Hi @YakovYermakov -

1. Opening graphs - currently all graphs open, but you can easily click the selectors without closing the graph window and then click the preview button to refresh the graphs- this is basically what you are suggesting plus an initial plotting that costs nothing. When you save the session/analysis your choices are saved. The problem with having a general pattern of on/off for a method is that there is fuzzyness in naming the columns. We could however, start with all ratios and no user functions as a first pass. If someone can come up with a general way to preselect a meaningful subset, please chime in!

2. control settings - please make suggestions! Current scheme here

[ryanickert]

Just to add to this feature request: For our daily-driver mass spectrometer outputs, I edit them so that it only outputs the quantities that we might want plotted, so we typically always want everything plotted. I suspect that's the case for many labs? So if the default could be "everything" so we can quickly click througg (the same functionality on OG tripoli) that would be great.

[bowring]

Hi @ryanickert - I believe select all is the case now? Unless I am missing something.

[ryanickert]

Ok!

[joneelzinto]

Is there a way to undo the Chauvenet Rejection without having to reset all data?

[noahmclean]

Yeah, I generally agree—there's no one objective definition for an 'outlier'. Applying the Chauvenet rejection algorithm to normally distributed data will result in a biased (low) estimate of the standard error and a less accurate mean value. But there is often demand for automated outlier rejection, and Chauvenet is certainly better than the once(?)-common two-sigma rejection in U-Pb TIMS measurements. MC-ICPMS data is often a little messier, in my experience, with more flier ratios among otherwise good-looking data. Whether the solution is 'outlier' rejection, robust statistics, or something else is certainly up for debate.

[joneelzinto]

Yeah, some of the carbonate TIMS data I reject relates to your third category and that rejection is usually something done by the user. I'm familiarizing myself more with Tripoli so I'm playing around with different operations during data analysis.

A couple off topic suggestions. The first suggestion is a 270U/265U measured output in Tripoli because that value is useful for calculating the covariance between the measured 265U/267U and 270U/267U. There is an oxide corrected 238/233 measured output, but for my purpose the non-corrected value is useful.
Occasionally some samples will require stopping and starting a second run. It would be nice to be able to be able to stitch together two or more runs. I know of some tedious ways of splicing and stitching together LA-ICMPS data into Iolite based off the timestamps. It would be nice to stitch in or important an additional dataset that would be included as additional blocks in Tripoli.

[ryanickert]

Oh yeah ICPMS data can be weird, right. Well, playing around with Chauv didn't throw up any red flags anyways.

Joneel glad to hear another "third group" person. Re: the 270/265 I have the same issue, for the same reason (and I assume that flexibility will be built into NuTrip) but for the time being if you rename it something that Tripoli doesn't recognize you can extract the measured ratio without any pesky interventions. I usually just add my initials before the masses and that works.

[joneelzinto]

Oh nice! Thanks for the tip. I'll try that out.

[bowring]

@joneelzinto -
There is an experimental stitcher sitting in the middle of the session page since v0.5.5 (june 4). Please try it and give me feedback - it is not meant to be finished, but to start the conversation. Almost 4 months and no one has taken the bait!!

[bowring]

@ryanickert -
Please expound on your suggestion above re:
Re: the 270/265 I have the same issue, for the same reason (and I assume that flexibility will be built into NuTrip)
Can you give me more specifics about this flexibility?

[ryanickert]

In OG tripoli, 270/267 and 265/267 data are automatically oxide corrected and there is no straightforward way to have tripoli report the data "as measured" rather than with a correction. In the screen shot below, you can see that those ratios have been corrected and the uncorrect ratios are not available for inspection by a user. The easiest way to get around this is to name the functions in the IsotopX software something that tripoli does not recognize. I don't know why this got hard coded originally so I can't really give advice on whether that should be a default in NuTripoli. Since the oxide correction also happens in U-Pb Redux (which it should) it's not clear why it needs to be done in tripoli as well.

[noahmclean]

A historical note: this capability was added to Tripoli before U-Pb_Redux (later rebranded as ET_Redux) was born -- probably @bowring's and my first collaboration. Here's my recollection, which might have some holes because it was a long time ago.

Those were the days that dinosaurs roamed the Earth and we used PbMacDat to reduce U-Pb data. My memory is that PbMacDat did not do the U oxide correction because it was developed before folks ran U 'piggyback' on their Pb beads, and instead measured U as a U+ loaded on a separate bead with colloidal graphite. So, the oxide correction, when it came along, was programmed into the Sector54 as a user function. With Dan Condon's realization that we needed to revise and keep track of the 18O/16O of the O in the UO2 during the ET tracer calibration (2006ish?), we added the 18O/16O as a parameter in Tripoli so that we could do the oxide correction, pass oxide-corrected U ratios to your data reduction program if you wanted, and additionally pass the 18O/16O used if you were so inclined.

[bowring]

@noahmclean - please chime in!