Most Task Parameters are more like Software Preferences

[sbodorkos]

I'm in the process of trying to generate the source files for arithmetic comparisons between SQUID 25.0 and Squid3. One of my first jobs is to create 8 Squid3 Tasks from 8 SQUID2.50 Tasks, and generate ReportTables for each. I have started that process, but I'm going to take a break to write a couple of Issues that are making the process not very much fun.

This one is to do with the Parameters attributed to the Task... most of these things actually transcend individual Tasks, or even groups of Tasks. Some are more fundamental than Tasks. And some are (to my mind) just misattributed.

The stuff coloured yellow really doesn't have anything to do with any given Task. They are more like system/software Preferences in the classical "set and forget" sense: you'd configure these once, for your own installation of Squid3, and you'd rarely change anything. Besides which, they transcend Tasks. Your choice of Task will not dictate whether you set 'Normalise to SBM' ON or OFF - it is much more likely that your Prawn XML file-contents will dictate that.

The stuff coloured green is changed more frequently... but not primarily as a function of Task choice (although we are now familiar with Reference Material-specific Tasks used by GSC). In general, the green more strongly controlled by Prawn XML file-contents, and these controls should be nested elsewhere, with closely related activities (in this case, it would be Data... Manage Spots and Reference Materials: more on that in a separate Issue).

The stuff coloured pink relates to common Pb and its correction, which is difficult to categorise, but doesn't correlate strongly with Task choice. The default common-Pb composition is perhaps best considered a type of high-rotation Preferences setting.

Of course, all the Directive-related stuff is fine: this screen is where it belongs.

[bowring]

We need to consider how to manage 1) user preferences for these various choices and 2) actual choices made in the current project and task. We should examine some use cases in detail to fully grasp the complexities.

Note - this is a brainstorm on my part trying to tease out the key issues!

For example, let's say we create a new "Data Handling Preferences" or "Data Preparation Preferences" menu item under Data that includes all the yellow, green, and purple stuff. Then, when the user creates a new project from a data file, they should expect that the initial data handling decisions would be done per their preferences and that they should also be able to change some of those decisions for the current project without necessarily changing their long-term preferences. Since these decisions are not really task-related, they need to be saved at the project level so that they can be retrieved when the project is re-loaded. When the user creates or loads a task into the project, the task will need to be configured (or updated) because its built-in expressions depend on these data preparation decisions (the various parameter models and common lead choices). A complication will be that the directives specific to a task might clash with the choice of Pb208 as the index isotope. Conversely, when the user saves a task, the data preferences decisions (the various parameter models and common lead choices) are not included because they are part of the project context that contains the task and the task does not care which decisions are made, only that decisions can be made.

Thus, in conclusion, a task should be independent of these data preparation decisions, in contrast to the current Squid3 architecture. In retrospect, this is the case with Squid2.5. Squid3 is adding the layer of "Project" between task and preferences, which allows for customizing the processing environment (project) for the data file and task without necessarily changing the user's preferences.

The changes to Squid3 will be straightforward because of its modularity. However, I suggest we examine some other use cases in addition to reviewing the one presented above so that we can specify the workflows and menu items before proceeding with changes to Squid.

[sbodorkos]

Yes to Project v System Preferences (although I am still grappling with the concept of what a Project actually is). I had conceived of a Project as a passive collection of one Prawn XML file, one Task, and one set of user-defined preference and parameter models... but the menu items under Data suggest my perception is wrong. But at the moment, I don't know when to create a new one, or when to save an existing one, if I am interested in keeping track of what I have done.

Re Preferences, one approach might be to examine which parameters predate and/or are independent of Tasks, and which are Task-dependent (choice of index isotope being an example of the latter). It could well be that index isotope needs to remains a Task parameter, in view of the definition work we have done - I am happy with that.

New issue will outline a proposal specifically for the green stuff.

[cwmagee]

It would probably be easier to tell what is a project vs a task vs an xml file if the "Load Task" button was operational.

As far as tasks vs preferences are concerned, if you think of the tasks as the range of mathematical approaches allowed by the expressions which make up that task, then the settings tell SQUID which particular expressions to execute.

In practice, most of the yellow and pink highlighted stuff will depend on the behaviour of the SHRIMP and/or the geologic context of the unknown samples being analysed. Specifically, for YELLOW stuff: -SBM normalization is going to depend on the quality of the SBM data- most people will probably default to yes, unless there is a problem with their SBM detector and-or analyst training in how to use the SBM detector. If the CAMECA people ever come on board, it will obviously be off for them, since those mass spectrometers don't have SBM detectors. -Name delimiters will usually be constantish for individual users, unless they spend a lot of time crunching other people's data (which only some of us are crazy enough to do).

The above preferences are TASK INDEPENDENT. That is to say, all data files will have sample names and SBM data in the data file- geochron of all types of minerals, and even data which aren't for geochronology at all.

The common Pb corrections, spot-to-spot error (now "weighted means of Ref Mat"), and calibration equation preferences are only relevant for tasks which have the expressions required to calculate them.

-The common Pb corrections (pink) have to be flexible enough to account for environmental Pb introduced through bad SHRIMPing/poor sample handling, OR actual geologic Pb present in the samples. I should note that the index Pb isotope for the reference zircons and the unknown zircons can be different (and are in about a third to a quarter of the GA data I've looked at). The point is that common Pb treatment will (or at least ought to) change session to session based on SHRIMP behaviour, sample preparation, and geological problem, even for a single user who is set in his or her ways.

-The calibration equation will usually depend on what the target mineral is, but most of the various tasks I have relate to different calibration equations, and looking at their effect on zircon data.

-The calibration and the common Pb are related, in that the calibration is used along with the measured Th and U to determine how much of the 207Pb and 208Pb are radiogenic.

In SQUID 2, the "weighted means of Ref Mat" line of preferences (yellow) is independent of the task, If you think about it, though, it probably should NOT be. It relates to the fundamental accuracy of the calibration, and if people load tasks with different calibrations, there is no robust reason for them to assume that this will not also change the calibration ultimate accuracy (of course, most people don't change tasks very often).

[NicoleRayner]

I'm still grappling with ideas about workflow and what constitutes a task/when to make a new one etc. In the short term though, in terms of simplifying/clarifying the Task Parameters, I would suggest that "Sample Delimiter" does not belong in the task manager. It is already defined under "Data - Sample Naming...". I was also going to suggest that the RM/CRM models be removed from Task Manager too (as they are defined in Data - Manage Spots) but I see that in the most recent version that has been removed.

The common Pb/index isotope (pink highlight above) are going to be a whole other story - as Chuck points out, the common Pb can vary from sample to sample and be different from what is used for the RM. At the Task Manager level these fields definitely apply to the RM, but not necessarily the unknowns. Perhaps to better differentiate what these parameters (yellow highlighted) refer to they could be grouped together under a "RefMat preferences" class (in blue circle)?

I guess the appropriateness of this suggestion hinges on how the common Pb correction that occurs during "Group Me" is going to play out. @sbodorkos any additional insight?

I'm unclear where the best home for the physical constants model selection would be. It does relate to the "type" of task (geochron or other)....

[NicoleRayner]

Now that DefCom and Physical Constants are the only models in the Task Designer, there is no where to set the default RM model/CRM model.

Perhaps this should be done on the Data - Manage Spots and RM window? Some sort of "set as default" check box?

[bowring]

This issue has been addressed piece-meal during the past year and the final change as of v1.5.0 is that the parameters are moved to the project management page. There is still work to do in creating the management tools for Squid3 tasks and that is next on the agenda. I am closing this issue with the hope that we can make new issues that deal with smaller changes that may be needed.