v0.4.6-alpha

[bowring]

Modifies rounding of stats in cycle mode of OGTripoli plots per:
https://docs.google.com/document/d/14PPEDEJPylNMavpJDpYSuemNb0gF5dz_To3Ek1Y_Agw/edit?usp=sharing

What's Changed

• Updated rounding of cycle mode stats for OGTripoli per Noah by @bowring in Updated rounding of cycle mode stats for OGTripoli per Noah #210
• fixed version number by @bowring in fixed version number #211

Full Changelog: v0.4.5-alpha...v0.4.6-alpha

---

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

[noahmclean]

Suggestion: Do not label the y-axes for OGTripoli plots in the "Ratios By Cycles and Blocks" tab. Currently, y-axes are labeled "Ratio" or "Function", but this information is redundant with the title of the plot rectangle (e.g., "Ratio 206/204") displayed prominently at the top left of each tile.

[bowring]

see next version 0.4.7 soon

[noahmclean]

Feature request:

Import Case1 data from the Isotopx Phoenix generated by the older software IonVantage. IonVantage generated .xls files that include a sheet with cycle data and a separate sheet with run parameters (e.g. cyclesPerBlock, analysis name). The original Tripoli will read these files, and many labs with older instruments still use this software or used it until very recently.

Examples:

Example data files are in https://github.com/CIRDLES/TripoliTestData/tree/main/IsotopxPhoenixTIMS/KU_IGL/IonVantage

Explanation:

Inside the *.xls IonVantage file,

The sheet named "CYCLE" contains

• variable names (e.g., 206/205) in the second row starting in the third column
• columns of cycle data starting on row 17

The sheet named "CTRL" contains

• the number of cycles per block in cell D13 (cell name "ILV_CyclesPerBlk")
• the sample ID (sample name) in cell D63 (cell name "SLV_SampleID")

[bowring]

see next version 0.4.7 soon

[noahmclean]

Compliment: the y-axis grid and tick labels in "Ratios by Cycles and Blocks" are spaced well and rounded in a useful, readable way.

[noahmclean]

Bug Fix:
My understanding is that when Tripoli reads a .TIMSDP file as a Case1 dataset (i.e., time series only), it assumes the cycles/block = 10 because this information does not appear in the header.

You can find the total number of cycles in each block inside the "#BLOCKS" block of the .TIMSDP file. A row from #BLOCK contains, as its first element, the block number, and as its seventh comma-separated value the total number of cycles in that block. The number of cycles per block is the same for each block, so you can use the seventh value of the first non-header row as the cyclesPerBlock.

[bowring]

The #HEADER has "CyclesToMeasure" entry. We are assuming the same number of cycles per every block except the last block in the event it is missing data.

[bowring]

Actually, the issue is with Triton .exp files which have no mention of cycles per block or even blocks. We have hardcoded in 10 cycles per block, but maybe which should just assume 1 block with all the cycles? If not, then we will need to provide a UI for the user to specify cycles per block.