R-Lum/Luminescence

Time-scale in analyse_FadingMeasurement()

Eiskeil opened this issue · 6 comments

Expected behaviour

The x-axis in the plot output should be log(t*/tc) (dimensionless) with respective axis numbers. There should be also the option to manually set t* and tc in the function in case of special protocols and manually loaded Lx/Tx datasets.

Observed behaviour

The x-axis is labeled with "Time since irradiation [s]" and at least the "[s]" should be removed. The numbers shown on the axis ticks are not correct. These are given in absolute terms (seconds since irradiation), but should be plotted at normalised and logged values.

Running mini example

library(Luminescence)
data("ExampleData.Fading", envir = environment())
fading_data <- ExampleData.Fading$fading.data$IR50

g_value <- analyse_FadingMeasurement(
  fading_data,
  plot = TRUE,
  verbose = TRUE,
  n.MC = 10)


@Eiskeil Regarding the three issues:

  1. The x-axis plots indeed log(t*/tc). However, the normalised values would read rather odd, and it does not allow the user to cross-check the results with what was requested in the sequence (at least not in a straightforward way). Thus, the function plots log(t*/tc) but shows the re-calculated time values (in s) as x-labels instead of the normalised values. Therefore the plot shows [log_10(t/tc)] under the plot.

  2. tc is the time since irradiation, if you want to modify this, you can l just modify the irradiation time of your prompt measurement. In particular, for manually loaded Lx/Tx datasets this should not be a problem.

  3. t* has the option 'half' (after Auclair et al., 2003) and 'end' see manual. So far no other values are allowed. However, if end is used and the dataset is provided manually any t* value of choice is possible any time since irradiation can be provided.

Update

Two further thoughts I forgot in my previous response:

  1. tc is, by definition, linked to a specific Lx/Tx value and does not stand alone. Hence, it does not make much sense to modify tc alone because it will then be disconnected from a Lx/Tx value used for the normalisation.

  2. For t* one could think about an option (nothing that is implemented yet) to inject an own function to modify the t* value in the fly, e.g., the argument t* accepts, on the top the character a function as input. This function can modify all t* values as defined by the user. Example:

f <- function(x) {x^2}
analyse_FadingMeasurement(..., t_star = f)

This would square all the time-since-irradiation values.

Thank you RLumSK for the quick response.

I spent some time to double-check everything and actually you are right regarding all issues. It is possible to povide the tc value manually with the Lx/Tx values.

For t*, the extension of the functionality would be quite useful, e.g. if you have an extra pause in between irradiation and measurement.

Regarding the x-axis in the plot, I understand your arguments, but find it still a bit confusing to see the absolute time values when there is a log-labeling. If not too complicated, would it be an option to have a double x-axis, showing both the absolute and the log numbers?

@Eiskeil I added

  1. Addition x-axis showing the real log10(t/tc) values. I find this confusing, but ok.

Screenshot 2020-07-30 at 21 41 09

  1. t_star now allows a function as input as outline above in my previous post. Naturally t_star cannot work if the data is of type data.frame in such a case the irradiation time is missing but would be needed to calculate t2 according to Auclair et al. (2003).

  2. As it turned out, t_star had zero effect if the input was imported by read_BIN2R(), i.e. from BIN/BINX-files. This bug is now corrected.

Please double-check the function (install dev_0.9.x branch). Thank you!

Thank you for fixing all these issues!

I tried to double-check the function, but could not complete it, unfortunately, due to the following error with the documentation:

Error in fetch(key) : lazy-load database '/Library/Frameworks/R.framework/Versions/4.0/Resources/library/Luminescence/help/Luminescence.rdb' is corrupt

Apart from that, the function seems to perform well. I will continue testing once access to the help functionally is possible.

After re-starting the R-session, the function worked as expected. Thank you for your efforts!

Great!