R-Lum/Luminescence

template_DRAC() ... is not a template

Closed this issue · 6 comments

Expected behaviour

The function should provide a meaningful template where preset values are chosen very carefully and, wherever allowed, left empty or zero. Unexpected behaviour should be avoided. In particular, all none necessary columns should be left empty.

Observed behaviour

The function initialises the template with none justified default values, e.g., Etch depth min (microns)
is preset with 8 instead of 0. The value appears to be taken from the examples provided with DRAC. However, if the template is used, but the user has not etched the samples, it is very unlikely that the user is ever tempted to check this value (why something should be inserted that is not relevant?). In other words, the subsequent calculation is highly likely to become systematically wrong.

Please make the template a real template or rename it to 'example'.

Running mini example

library(Luminescence)
template_DRAC()

Supplement

It is, even more, worse than I thought, the default setting 0 for the internal user-defined dose rate sends all the internal dose rate values to waste. Without further notice! But why the user should modify this value if U, Th and K values had been provided. There is no need to even look at this column.

tzerk commented

I object, it is a template (yes, even a real one).

That being said, the remaining question would be if it is a reasonable template, which is certainly subject for discussion. Yes, the current "default" values are (at least partly) from the DRAC input template.

In other words, the subsequent calculation is highly likely to become systematically wrong.

This reads like the "systematic error" would be due to the function/template, but it is due to the user not being careful and naively relying on default values.

The function initialises the template with none justified default values

Any default value would be "none justified". What would be the reason to use Guerinetal2011 over Liritzisetal2013 for the conversion factors? How can we justify to estimate the Rubidium content concentration from Potassium by default?
I certainly see the problem, but the only real way out of this dilemma is by having no default values. Come to think of it, it is probably what I'd also prefer given that any preset could be disputed.

Edit:
I will probably replace all values with either NA_integer_, NA_real_ or NA_character_. This will ensure type safety. but also force the user to have a look at all the columns.

Any default value would be "none justified". What would be the reason to use Guerinetal2011 over Liritzisetal2013 for the conversion factors? How can we justify to estimate the Rubidium content concentration from Potassium by default?

This is not a good example. The differences between Guerinetal2011 and Liritzisetal2013 are not important, and so is the question whether the Rb concentration is calculated. This is meaningful, however, my examples, e.g., setting an etching range is a different level.

That being said, I would prefer to set all values very conservative, but not NA_integer or so, otherwise we don't really need the template. I like the idea of the template, but if you have to touch all columns, this is nothing you want to do with R.

By the way, the 0 for the user-defined dose rate is somehow a glitch in DRAC itself. The manual demands even 0 ... I reported this to the authors of DRAC.

After thinking about it, I have a better suggestion: Please create a template as suggested (means with nothing but NA_integer etc.) as default. At the same time, the template_DRAC() function gets a new argument, providing different settings, e.g.

  • quartz (coarse grain)
  • quartz (fine grain)
  • K-feldspar (coarse grain)
  • Polymineral (fine grain)

I guess this would fix the problem and provide a real benefit to the user. I know, using settings is somehow prescriptive, but the default is basically NA everywhere which keeps us safe from complaints.

tzerk commented

Even if all values would be NA by default there would still be value in the function, because otherwise the user would need to create his own data.frame from a reference (e.g., having opened the DRAC .csv template). With the template object you can immediately see what data you need without switching context.

The differences between Guerinetal2011 and Liritzisetal2013 are not important, and so is the question whether the Rb concentration is calculated. This is meaningful, however, my examples, e.g., setting an etching range is a different level.

In terms of impact on the equivalent dose this might be true. In a more general sense, the decision for a particular set of conversion factors or the exact values for HF etching are the same. Any default value we set will introduce a "systematic error" if the user doesn't bother to check all the values before submitting the data set to DRAC.

Anyway, I like your last suggestion and will do appropriate changes to template_DRAC().

Done