Age correction for d14c data

[jb388]

@ShaneStoner @aahoyt @coreylawrence @crlsierra @setrumbore Our template info file does not clarify whether or not d14C data should be age corrected or not if it was analyzed in a later year than the year of collection. (This is not an issue for fraction modern data, as the oxalic acid standard decays at the same rate as samples do).

Ex. The template file "Trumbore_1996Koarashi_2012Marzaioli_2010.xlsx" reports layer data from samples that were collected in 1959, but analyzed by AMS in 1992. It is unclear if the reported data in the lyr_d14c field are corrected for decay since 1959 or not.

The important question here is: should we specify that data are age-corrected or not?

Also, if I am somehow wrong about the interpretation of delta 14C data (i.e. that age-correction is necessary), please weigh in.

[coreylawrence]

I'm curious about this issue as well. It came up in the context of our Powell Center Beyond Bulk sub-group because we are working with Zheng to normalize the layer and fraction 14c data, using his method. Based on that discussion, my assumption would be that (using Jeff's example) if a sample was measured in 1992 but collected in 1959, the reported data would be age-corrected to 1992.

That said, I think @setrumbore would have a much better handle on the standard conventions than I do. If it is common (possible?) that such data are reported without the correction to time of measurement, then we probably should implement a flag column to specify.

[setrumbore]

I am afraid I have bad news…..

Definitely the published data up (up until around 2010) did not have the proper correction (i.e. back to date of collection). Xiaomei caught the error and it is now fixed for any new data. For samples run within a couple of years of collection it is probably not worth going back and fixing (far smaller than the error).

The safe thing to do would be to calculate from Fraction modern if that is the primary data and use the year of collection/running.

I think most of the Detla14C data in the literature have not done this correctly….

Best, Sue

On Jan 28, 2020, at 11:21 AM, Corey Lawrence notifications@github.com wrote:

I'm curious about this issue as well. It came up in the context of our Powell Center Beyond Bulk sub-group because we are working with Zheng to normalize the layer and fraction 14c data, using his method. Based on that discussion, my assumption would be that (using Jeff's example) if a sample was measured in 1992 but collected in 1959, the reported data would be age-corrected to 1992.

That said, I think @setrumbore https://github.com/setrumbore would have a much better handle on the standard conventions than I do. If it is common (possible?) that such data are reported without the correction to time of measurement, then we probably should implement a flag column to specify.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/International-Soil-Radiocarbon-Database/ISRaD/issues/212?email_source=notifications&email_token=AH7OW2VJXFRBNIWJBCGFBX3RACASBA5CNFSM4KMUFJ4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKER27Q#issuecomment-579411326, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7OW2W7RPHBQPH2FHUVEQ3RACASBANCNFSM4KMUFJ4A.

[jb388]

Thanks for weighing in, Sue. I would hope that in cases where archived samples have been run (i.e. sample collection date << date of AMS analysis) the age correction has been made.

Two solutions come to mind: 1) add a flag for delta 14C age correction (Y/N), 2) assume that in most cases the age correction is trivial, and just keep an eye out for cases where the difference between the xxx_rc_year value and the xxx_obs_date_y value is large.

We could also implement a warning message in the QAQC for this.

[setrumbore]

Hi Jeff,

It only matters when we don’t know if the ‘known age’ correction was made or not in the original publication. For something run within 10 years of collection, the difference is <2 per mill. At 50 years, it is about 6 per mill. So for a 1900 sample run in 2010, it is nearly 15 per mil. The only info in the database that old I think came from Margaret, who I think made the appropriate correction. Of course we should be doing it right going forwards (e.g. what you’re doing now with Craig’s samples). But I see no reason to go back and correct the whole data base given that spatial heterogeneity is going to be larger in most cases (even if not measured).

I do think it is good to say we are not always sure whether this correction has been made on reported values for archived samples run decades later - and give the formula to calculate/correct it. However, we should also say that this is likely not adding an error of more than 5 per mill for results in the current database, and in most cases this is less than stated precision.

We can put on the list to correct my samples (archives from the 1950s run in the early 1990s, where I know the correction was not made). Those are likely to be the worst ones in the data base right now

Cheers,

Sue

On Jan 29, 2020, at 1:05 AM, Jeff B notifications@github.com wrote:

Thanks for weighing in, Sue. I would hope that in cases where archived samples have been run (i.e. sample collection date << date of AMS analysis) the age correction has been made.

Two solutions come to mind: 1) add a flag for delta 14C age correction (Y/N), 2) assume that in most cases the age correction is trivial, and just keep an eye out for cases where the difference between the xxx_rc_year value and the xxx_obs_date_y value is large.

We could also implement a warning message in the QAQC for this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/International-Soil-Radiocarbon-Database/ISRaD/issues/212?email_source=notifications&email_token=AH7OW2VHTAWCZCMSNNZPE43RAFBD3A5CNFSM4KMUFJ4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKGOVNI#issuecomment-579660469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7OW2T75KUOMO3ZGSAD4HLRAFBD3ANCNFSM4KMUFJ4A.