Difference in Scheme order when using splitSchemes

[suryanshsingh20]

splitSchemes splits the schemes in an order that is different from what we get when we use myFSRS.schemes in command window Data used in Matlab script : https://drive.google.com/drive/folders/1wLNuNEsO_xljyzLCUxcIKJAAZ3CRnZxn?usp=sharing Matlab code for recreating the issue:

myFSRS = fsrs('22-04-27_17h39m24s_Sample_S_pH_13100mMNaOH','short name','OC_ns_FSRS');

myFSRS_split = splitSchemes(myFSRS);

SchemeOrderCompare = cell(5,1); SchemeOrder = myFSRS.schemes;

for ii = 1:5

SchemeOrderCompare{ii,1} = myFSRS_split(1,ii).schemes;

end

% SchemeOrder and SchemeOrderCompare are not the same

[IlyaVino]

I think the reason for this is that to both 1) maintain array support and 2) to go from: -a TS object array with several schemes in each TS object array element to: -a TS object array with a new dim for each internal scheme and only one scheme in each TS object array element one needs to check to make sure there is a common set of schemes in the full TS object array. The order is lost in this check.

For example, what if I have an TS object array where the first element contains GS Raman and ES Raman and the second element contains just Transient Reflectance? This TS object array cannot be split. Or if the first element is in order GS Raman, ES Raman, while the second is ES Raman, GS Raman. The array can be split, but which order should be used?

I think the best way to resolve this issue is to stick to the order that is defined in the first element that contains all common schemes. For example, a TS object array with schemes [{GSR, ESR, TR}, {GSR, ESR, TR}, {ESR, GSR}] would return [{GSR},{ESR};{GSR},{ESR};{GSR},{ESR}] even though the last TS element has the reverse order. What do you think?

[IlyaVino]

Btw, the above is a fringe case but one may run into it if using a new acquisition program that now saves the schemes in reverse order.

[IlyaVino]

Also, the syntax for splitSchemes can optionally return the new scheme order

[objOut, schemeList] = splitSchemes(objIn, varargin)

[IlyaVino]

TLDR: there are use cases where the scheme order may be ambiguous. Let's choose a rule that tries to resolve this ambiguity.