Write meta info in RLum.Data.Curve objects

[tzerk]

Each RLum.Data.Curve object produced by model_LuminescenceSignals() should contain the corresponding .BIN file meta information in the @info slot.

Example:
list(OSL = c(125, 100, 100) should produce an RLum.Data.Curve where @info is a list with the following elements:

$NPOINTS
[1] 1001

$LTYPE
[1] "OSL"

$LIGHTSOURCE
[1] "Blue Diodes"

$LPOWER
[1] 100

$LIGHTPOWER
[1] 100

$HIGH
[1] 100

$RATE
[1] 5

$MEASTEMP
[1] 125

In an ideal case, it should also contain the irradiation dose of the previous irradiation (if there is none, then 0):

$IRR_TIME
[1] 60

This would greatly help for further data processing that rely on these information (e.g. Luminescence::analyse_SAR.CWOSL().

[RLumSK]

...I'm not sure whether this a good idea, we should not preset the info elements. Info elements are by definition not fixed. If we need something similar we can add an own slot with such information and make it part of the object structure ...

[tzerk]

What does "not fixed" mean and why should the function not use the @info slot? What's its purpose then? I do not care if it's the @info slot in particular, as long as it's stored somehwere. But now it's an unnessecary loss of information that may or may not be needed for further analysis.

Of course, it also does not necessarily have to use the BIN file keywords. And what is the difference in storing the elements curveDesciptor (plot labels) and some arbitrary RLumModel_ID for each curve, but not it's measurement settings/conditions?

[RLumSK]

I do agree, but the @info slot can free float, means, there is no fixed setting of keywords. If we need another set of information, we should store them directly as object definition. The BIN-file keywords are, anyway, good and useful.

To conclude: I'm just against any presenting of keywords in the info slot ... or if so, it has to become part of the object definition.

[tzerk]

So @info is more of a "dump" for miscellaneous information. For RLum.Data.Curve objects in specific this is any data that is not @recordType @curveType or @data, which currently leaves us with only the @info slot to work with. Note that converting a Risoe.BINfileData object to an RLum object does the exact same thing as I suggested here. If we do not want this kind of information in the @info slot, I agree, we do have to come up with a further S4 slot in the object definition. But this would also mean that the above mentioned conversion needs to be adapted (i.e., BIN metadata need to be stored in the new slot).

[tzerk]

After a discussion with @RLumSK we came to the conclusion that the @info should not be used for essential/common information on curve parameters. In the long term we need to update the RLum.Data.Curve class definition and add a dedicated slot/element that stores this type of data.

Closely related issues:

• exporting stimulation curves (i.e., LED power density vs. time)
• exporting irradiation curves (i.e., dose [rate?] vs. time)
• homogenising RLum.Data.Curve objects produced by the various readers (Risoe, Lexsyg, Daybreak, ...)

Ultimately, this demands an agreement on which parameters should be stored (or not) and in which format.