Age models

[Eric Grimm]

I've been experimenting with a P_Sequence model, which has 16 radiocarbon dates. The site has proxy measurements from many depths, and I need to determine mean ages and ranges for each of these depths. I did this by clicking on the    symbol next to P_Sequence in the results table, but these ages are apparently determined simply by linear interpolation between the modeled radiocarbon ages. On the other hand, it would seem that a modeled age could be determined by using the Date function in the original model, e.g. 

Date("1470 cm") { z=1470; };  

I did this with just the depths for pollen samples (76 samples), and the model ran, although it sat for significant periods of time at "Resolving order. Finding U" and "Resolving order. Finding  P_Sequence". However, when I add many more sample depths for other proxies (LOI and charcoal), it bombs. 

Is there a reason why the Date function is inappropriate for determining modeled ages between radiocarbon depths? I'm thinking of age modeling programs like Bacon and Bchron, which do provide modeled ages for depths.

[Christopher Ramsey]

Eric

The best way to do this in OxCal is to do some interpolation within the code, using the interpolation parameter of the P_Sequence.

If your core is ~2000cm with 76 samples, you could choose the interpolation parameter to be 0.1 this will give you about 200 interpolation points (0.1 per cm). This will not give you exactly the depths of your pollen proxies but it will give you depths between the radiocarbon dates themselves. These depths are chosen to be evenly spaced between the points at which you have dates as this is more efficient. You can then linearly interpolate from these points - which will be a very good approximation.

The issue with using large numbers of Date functions is that it make the models parameter space very large, and this slows down convergence and increases the run time. It is necessary if you need to pull out a full correlation matrix for the associated uncertainties - but not necessary for most purposes.

Most other age-depth modelling fits piecewise linear deposition rates and so extracting those depths from the model is easy - but still ultimately interpolated. The P_Sequence model is not piecewise linear and so there is noise at every scale - if you have a large number of Date functions you can explore that noise but it will be a slower process.

Best wishes

Christopher

> On 27 Aug 2020, at 05:03, Eric Grimm <scarlet...@gmail.com> wrote:
>
> I've been experimenting with a P_Sequence model, which has 16 radiocarbon dates. The site has proxy measurements from many depths, and I need to determine mean ages and ranges for each of these depths. I did this by clicking on the <Raw.gif> symbol next to P_Sequence in the results table, but these ages are apparently determined simply by linear interpolation between the modeled radiocarbon ages. On the other hand, it would seem that a modeled age could be determined by using the Date function in the original model, e.g.

>
> Date("1470 cm") { z=1470; };
>
> I did this with just the depths for pollen samples (76 samples), and the model ran, although it sat for significant periods of time at "Resolving order. Finding U" and "Resolving order. Finding P_Sequence". However, when I add many more sample depths for other proxies (LOI and charcoal), it bombs.
>
> Is there a reason why the Date function is inappropriate for determining modeled ages between radiocarbon depths? I'm thinking of age modeling programs like Bacon and Bchron, which do provide modeled ages for depths.
>

> --
> You received this message because you are subscribed to the Google Groups "OxCal" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to oxcal+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/oxcal/1d530ea2-d7d2-452d-b4ad-6ff2f853ecc5n%40googlegroups.com.
> <Raw.gif>