Misunderstanding some of the ``elemental_composition`` function outputs

Ramon13

Hi all, just a quick one:

When using elemental_composition on JEdit, the "Original" and "Other" column gives the crystalline and amorphous compositions of the sample respectively with consideration of what's been refined from the different phases (i.e. Al wt%, Ba wt% (etc.)). This can be made more accurate by constraining the system by using the element_weight_percent_known [Element] function and using values retrieved from bulk analyses, like XRF (I'd post an image here of my code for clarity but I'm not sure how to as I can't just upload one..).

I've noticed that, after all the elements are given in elemental_composition there is a final row labelled "Other".

In the "Original"/crystalline column, the "Other" row (not to be confused with the "Other" column, which is the composition of the amorphous analytes) seems to correspond to the total sum of the amorphous analytes given in the "Other"/amorphous column (i.e. ₄₉ wt% from the image above), however, I'm not too sure what the "Other" row for the "Other"/Crystalline column corresponds to (i.e. 1.9 wt% above). Note that none of the phases refined have any elements that aren't included from the element_weight_percent_known [Element] function and the number is not the sum of the crystalline composition, so... I'm just wondering if anyone can uncover the mystery here please? It'd make sense if the value was 51wt% (i.e the sum of the crystalline analytes).

Kind regards,
Ramon

johnsoevans

Open the Technical_Reference.pdf from your TOPAS folder or from the jEdit "Durham - help - technical references" menu. In my version Section 14.3 on P114 describes these rows and columnds.

Ramon13

Hi again John,

Thanks for the reply 🙂.

I'm reading the TOPAS6 Tech manual and presume the section you refer to (i.e. "Elemental Composition Calculation", Section 11.3.1 in this version) is from from pp.159 - 162. Despite reading these sections, I can't seem to find an answer to my original question.

An additional question I have since reading this is that I usually employ the element_weight_percent_known [Element] function and presume the implicit backend software is already constraining the model, however, from the picture of JEdit code on p. 162, I see a restraint = ... and penalties_weighting_K1 .1 functions being used. The latter two in the example code are used with element_weight_percent [Element] (and not with _known function that I use, I cannnot find an example in the tech manual) but I'm now unsure if the backend software is actually restraining the model, or do I need to add the restrain function for each element? Surely not... but I'm unsure as there's no prm being used for these variables which makes me believe their unique and I want to make sure I'm actually constraining the model.

johnsoevans

My understanding is that the commands you're using are just reporting the elemental composition. You need to add a restraint or a penalty if you want to influence the refined value. There's an example of the type of format in zro2-restraint-xry-zr.inp.

If you're looking at an example like quant-1.inp, then the values for element_weight_percent_known of 63/24 for Zr/O are just being used to put values in the "Other" column. The "Other" column refers to the amorphous content of the unspiked original sample. So (see values in table below) the 0.768 is 24-O_original and 1.967 is 63-Zr_original. The final value in the "Other" column is Original_amorphous (9.943) minus the sum of these two values.

Section of quant-1.inp (equivalent to values in technical_reference.pdf):

   element_weight_percent_known Zr 63 
   element_weight_percent_known O  24 
    
   elemental_composition
	{
                       Rietveld         Corrected          Original             Other
     AL             1.173`_0.042      1.059`_0.000      0.000`_0.000      0.000`_0.000
     O             26.269`_0.017     23.709`_0.837     23.232`_0.854      0.768`_0.854
     SI             0.104`_0.004      0.094`_0.005      0.096`_0.005      0.000`_0.000
     Y              6.185`_0.013      5.582`_0.206      5.696`_0.210      0.000`_0.000
     ZR            66.270`_0.055     59.813`_2.200     61.033`_2.245      1.967`_2.245
     Other          0.000`_0.000      9.744`_3.246      9.943`_3.312      7.208`_0.214
	} 
                         
   weight_percent_amorphous  9.74365707`_3.24595755

Ramon13

Thanks for the brilliant replies as always John 🙂.

I put the code in my template and it seems to work fine. However, a follow up question I had regarding the zro2-restraint-xrf-zr.inp file you mentioned, I see that it includes

penalties_weighting_K1 10000
pen_weight 1

However, in the manual the example given on p.162 says to put this function before the xdd call:
``
penalties_weighting_K1 .1

And then on p.191 in the keywords section it says that the value is set to 1 as "default" (i.e. not 10000 or .1), what is the discrepancy here I'm missing?

Also, is the ``pen_weight 1`` function from the zro2-restraint-xrf-zr.inp file the tolerance? The +/- error ? That's how I'm understanding it from Section 4.1 regarding the Newton-Raphson method? I think I'm misunderstanding this though because I'm not sure how I could distinguish this function with the errors I have for my XRF analytes and total measurement...

johnsoevans

This is complicated! There are a few notes on penalties, restraints, how they are weighted and the differences between them on the wiki at: https://topas.awh.durham.ac.uk/doku.php?id=penalties_and_restraints
The best mathematical explanation is in the tech ref section you mention.

In brief, penalties and restraints are subtley different in the way they feed into the mimimisation. The weightings are controlled by what Alan calls K, K1, KP and KR. K1 is what is called "penalties_weighting_K1" in the INP file. It gives the overall weighting of the penalties/restraints against the data. When K1 is high the penalties/restraints are obeyed closely. When it's low the data plays a higher role and penalties/restraints will be further from set values. It's up to you to decide what is appropriate (it depends on your confidence in the penalties/restraints). Unless you've got good reason don't change it too much from the default of 1.

"pen_weight" can be used to override the default way penalties (via KP) and restraints (via KR( are weighted. I've personally never used this functionality, but it e.g. lets you rewrite the topas equations so they exactly mimic (for example) the way shelx handles restraints. The "pen_weight = 1" in that INP file is just over-riding the normal weighting equation with "1".

Ramon13

johnsoevans Thanks for that John, I will take a closer look at the maths but I believe the main things I was hoping to get answers for I've gotten thanks to you. My bulk data is from XRF with low/reasonable detection limits for me to put the default 1 value so all good there. Seems like I shouldn't muck around with the pen_weight function either so I won't.

Ramon13

johnsoevans Hi John, just an update here. I re-ran a quant and got the following at the very end whereby I inputted the wt% data for each element from XRF:

do_errors_include_restraints
...
penalties_weighting_K1 1
...
restraint = (	O_wt -	48.24	); : -1.60688098`
	restraint = (	Si_wt -	28.21	); :-13.976498`
	restraint = (	Al_wt -	13.59	); :  16.1004502`
	restraint = (	Fe_wt -	5.66	); : 3.78292882`
	restraint = (	Ti_wt -	1.11	); :-1.11
	restraint = (	Ca_wt -	0.48	); :-0.48
	restraint = (	Mg_wt -	0.51	); :-0.51
	restraint = (	P_wt -	0.16	); :-0.16
	restraint = (	K_wt -	0.38	); :-0.38
	restraint = (	Na_wt -	0.19	); :-0.19
	restraint = (	Ba_wt -	0.18	); :-0.18
	restraint = (	S_wt -	0.07	); :-0.07
	restraint = (	Mn_wt -	0.04	); :-0.04
	restraint = (	Cr_wt -	0.01	); :-0.01
	
	element_weight_percent	O	O_wt	46.63311902`
	element_weight_percent	Si	Si_wt  14.23350196`
	element_weight_percent	Al Al_wt  29.69045019`
	element_weight_percent	Fe	Fe_wt  9.44292882`
	element_weight_percent	Ti	Ti_wt 0
	element_weight_percent	Ca	Ca_wt 0
	element_weight_percent	Mg	Mg_wt 0
	element_weight_percent	P	P_wt	0
	element_weight_percent	K	K_wt	0
	element_weight_percent	Na	Na_wt 0
	element_weight_percent	Ba	Ba_wt 0
	element_weight_percent	S	S_wt	0
	element_weight_percent	Mn	Mn_wt 0
	element_weight_percent	Cr	Cr_wt 0

elemental_composition
	{
                       Rietveld         Corrected          Original
     AL            29.690`_0.000     21.085`_0.052      7.402`_0.075
     BA             0.000`_0.000      0.000`_0.000      0.000`_0.000
     CA             0.000`_0.000      0.000`_0.000      0.000`_0.000
     CR             0.000`_0.000      0.000`_0.000      0.000`_0.000
     FE             9.443`_0.000      6.706`_0.173      9.588`_0.247
     K              0.000`_0.000      0.000`_0.000      0.000`_0.000
     MG             0.000`_0.000      0.000`_0.000      0.000`_0.000
     MN             0.000`_0.000      0.000`_0.000      0.000`_0.000
     NA             0.000`_0.000      0.000`_0.000      0.000`_0.000
     O             46.633`_0.000     33.117`_0.133     27.119`_0.191
     P              0.000`_0.000      0.000`_0.000      0.000`_0.000
     S              0.000`_0.000      0.000`_0.000      0.000`_0.000
     SI            14.234`_0.000     10.108`_0.071     14.452`_0.102
     TI             0.000`_0.000      0.000`_0.000      0.000`_0.000
     Other          0.000`_0.000     28.984`_0.332     41.439`_0.474

Now, obviously some of these values, like Fe, are bogus as they suggest that there is more Fe_wt% in the crystalline composition than the original bulk composition. Understandably, the values will change depending on how I do the quant, however, when i did the quant before (i.e. without the restraints and just with the element_weight_percent_known [Element] function) I get values that make more sense and are similar to literature for the sample I'm quantifying.

I'm not sure what I've done wrong here as I've followed the tech manual but have come out with less accurate results despite putting more physical and practical constraints on the system. For what it's worth I had these running uncommented from my first str (the corundum internal standard) to the very end. At this point I'm thinking of going back to my old method which is a shame because I've really been looking forward to adding these practical restraints onto my system; any help would be greatly appreciated. 🙂

If, at a very low chance, you ever want to zoom call or something for ease, let me know 🙂

johnsoevans

It seems odd that you’ve put in restraints and the quant has got worse. It’s often worth checking reatraints to make sure what you’ve set up is sensible and the equations arent fighting each other.

If you make penalties_weighting_K1 a very high number (e.g. 1000 or more) do the restraints get obeyed? What happens to the fit?

Or you could try adding “only_penalties” to the file as a check. This just fits the restraints/penalties and ignores the data.

Ramon13

Adding the K_1 to 1000 at the end gives negative FWHMs. If I instead do the only_penalties function I get negative amorphous content.

Note that I tried these at the "end" of my previous refinement though and not at the start, I'd have to redo the whole fit I guess to see if they'd work.

How confident are you that that the element_weight_percent_known function doesn't inherently restrain the data? Whenever I've used this my results have never gone above the inputted values or given nonsensical data (so far), but perhaps this is coincidental?

Ramon13

I've done some more refinements around this to try and figure out what's going on and I also reviewed again the tech manual which suggests that the element_weight_percent_known function "allows to constrain the weight percent of an element", and I think I might just use that. When I tried the restrain function I got negative values that didn't make sense. Oddly though, and maybe it's just a coincidence, but I tried two independent coal fly ash samples, each with different XRF analytics and got very similar XRD outputs. I'm not sure if it's a "coincidence", however, part of me now is thinking that nothing is actually being constrained and I've just imposed my refinement methods onto the model and gotten the same answer (even with different .str files (mostly of the same phase though))...

Now I'm unsure again, the craziness is starting to settle in hahaha.