Need datanames to describe amorphous contributions to diffraction pattern

[jamesrhester]

This is a placeholder issue to note that we would like to be able to describe how amorphous phases are described. Make some suggestions on how to do this below.

[rowlesmr]

An idea:

• _pd_phase.is_amorphous
  • yes|no
  • Allows a data block to be made to contain information such as a phase.name, elemental composition, block_id, maybe even _pd_peak.* information, which then leads to the individual phase profile suggestion.
  • Requires (small) redefinition of PD_PHASE: "This section contains a description of the crystalline phases contributing to the powder diffraction data set."
  • Allows a data block to be a "structure" without having normally essential data items, such as _cell.length_a.

For example:

data_theStd
_pd_block.id std
_pd_block_diffractogram.id diffpat
#crystal structure information

data_thePyritePhase
_pd_block.id pyrite
_pd_block_diffractogram.id diffpat
#crystal structure information

data_theAlbitePhase
_pd_block.id albite
_pd_block_diffractogram.id diffpat
#crystal structure information

data_theAmorPhase
_pd_block.id amor
_pd_block_diffractogram.id diffpat
_pd_phase.is_amorphous   yes
loop_
_pd_peak.d_spacing
_pd_peak.intensity
14.7 123
10.5 324
#...


data_aDiffractionPattern
_pd_block.id diffpat

loop_
_pd_phase.id
_pd_phase.block_id
_pd_phase.scale_factor #the scale factors don't make sense, I didn't want to calculate them
_pd_phase.mass_percent
1	std	0.000124	33.006
2	pyrite	0.000123	10.54(12)  
3	albite	0.000123	40.75(12)
4       amor    .               15.70(12)

_pd_calib.std_internal_mass_percent	33.333  #ie the internal std is 99.02% crystalline
_pd_calib.std_internal_name		"NIST SRM676a Al2O3"
_pd_calib.std_block_id			std

loop_
_pd_meas.2theta_scan
_pd_meas.counts_total
_pd_calc.intensity_net
5.00	1231	1024.212
5.10	1254	1024.212
#...

[briantoby]

Perhaps overly picky, but I am not sure a yes/no response for this is sufficient. Nanocrystalline and locally-disordered are other responses that come to mind. It would need a really clear (and likely controversial) definition if yes/no. On Oct 7, 2022, at 10:34 AM, Matthew Rowles ***@***.******@***.***>> wrote: An idea: * _pd_phase.is_amorphous * yes|no * Allows a data block to be made to contain information such as a phase.name, elemental composition, block_id, maybe even _pd_peak.* information, which then leads to the individual phase profile suggestion. * Requires (small) redefinition of PD_PHASE: "This section contains a description of the crystalline phases contributing to the powder diffraction data set." * Allows a data block to be a "structure" without having normally essential data items, such as _cell.length_a. For example: data_theStd _pd_block.id<http://pd_block.id> std _pd_block_diffractogram.id<http://pd_block_diffractogram.id> diffpat #crystal structure information data_thePyritePhase _pd_block.id<http://pd_block.id> pyrite _pd_block_diffractogram.id<http://pd_block_diffractogram.id> diffpat #crystal structure information data_theAlbitePhase _pd_block.id<http://pd_block.id> albite _pd_block_diffractogram.id<http://pd_block_diffractogram.id> diffpat #crystal structure information data_theAmorPhase _pd_block.id<http://pd_block.id> amor _pd_block_diffractogram.id<http://pd_block_diffractogram.id> diffpat _pd_phase.is_amorphous yes loop_ _pd_peak.d_spacing _pd_peak.intensity 14.7 123 10.5 324 #... data_aDiffractionPattern _pd_block.id<http://pd_block.id> diffpat loop_ _pd_phase.id<http://pd_phase.id> _pd_phase.block_id _pd_phase.scale_factor #the scale factors don't make sense, I didn't want to calculate them _pd_phase.mass_percent 1 std 0.000124 33.006 2 pyrite 0.000123 10.54(12) 3 albite 0.000123 40.75(12) 4 amor . 15.70(12) _pd_calib.std_internal_mass_percent 33.333 #ie the internal std is 99.02% crystalline _pd_calib.std_internal_name "NIST SRM676a Al2O3" _pd_calib.std_block_id std loop_ _pd_meas.2theta_scan _pd_meas.counts_total _pd_calc.intensity_net 5.00 1231 1024.212 5.10 1254 1024.212 #... — Reply to this email directly, view it on GitHub<#23 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACH7E2CUB2UC7UOLCGAZHODWCA7JHANCNFSM6AAAAAAQTRWXXY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rowlesmr]

Perhaps overly picky, but I am not sure a yes/no response for this is sufficient. Nanocrystalline and locally-disordered are other responses that come to mind. It would need a really clear (and likely controversial) definition if yes/no.

It is a good starting point, though! 😊

My initial thoughts are: if a phase can be described by a crystal structure (unit cell parameters, space group, atom positions...), then it is crystalline. Otherwise it is amorphous.

You then fall into the issue where a phase can be described as "crystalline" , but the peaks are so broad as to render the concept of "long range order" meaningless. (currently facing that issue with some pseudorutile)

There is also the opposite issue of PONKCS or DDM phases, where there may be no known crystal structure, but a series of peaks are calibrated in some fashion to allow modelling to take place.

[jamesrhester]

Phases might be modulated and/or magnetic, in which case data names from the MS/magnetic dictionaries could make their way into a data block. These don't get a special is_magnetic data name so I don't see why amorphous particularly needs this. And we avoid the "what is amorphous?" conversation that way - an amorphous material is anything that can have values assigned to the data names we define.

How I would approach this:

1. Change the definition of PD_PHASE as suggested above so that it is not restricted to crystalline phases
2. Define whatever data names are required to describe an amorphous phase.
3. Continue as before: the only software that is in trouble is software that expects to find cell parameters in a data block that has been identified as containing a phase. If cell parameters are not found, there is no danger that an incorrect calculation is performed as the software will either ignore the phase or error out. No QPA calculations involving amorphous phases could error as such a thing can't exist until we define the data names.

I suppose one benefit of the is_amorphous flag is to allow checking that a phase data block doesn't contain both amorphous information and crystallographic information. Of course this is equally possible simply by making sure that no crystallographic structure data names are present in a data block containing amorphous data names. But equally, perhaps there are distinct materials that we might like to describe using a combination of amorphous and crystalline data names.

[rowlesmr]

I'm stuggling to think of any amorphous-specific data names.

An amorphous phase can have a name, be modelled with some peaks, maybe even contain a per-phase profile. Have an elemental composition, density, MAC, LAC, chemical moiety, even a _pd_phase.mass_percent.

It could even have cell parameters and a space group; it just won't have atom positions - you can do PONKCS/DDM phases like this. I've even modelled amorphousy background shaped humps with a really funky unit cell such as P4 with a=2, c=40 and do a Pawley fit with the many peaks that are generated.

[jamesrhester]

So the issue here is really "can we use PD_PEAK to describe an amorphous phase?", as all the other data names mentioned above seem to be used in the exact same way regardless of whether we are talking about an amorphous phase or not. Let's check what the current function of these peaks are in the pdCIF scheme: if we look where _pd_peak.id pops up, it is used solely to link a phase's h,k,l with an observed peak. So the concept is that a peak is located and refined against a peak shape model, and added to the PD_PEAK list. The crystal structure refinement then, quite separately from this list of peaks, predicts peak positions and intensities. So PD_PEAK is very much just for holding observed peaks for comparison with the model.

Suppose we include our amorphous peaks in PD_PEAK. Their status in this list is of observed peaks, such as you might refine individually. These are not (conceptually at least) the amorphous model peaks, but perhaps the process of refining individual peak shapes and heights is essentially all that happens for amorphous models.

So here are two alternatives:

1. (maximum) We could define a new category PD_AMORPHOUS with data name peak_id and any parameters that we refine per amorphous peak.
2. (minimum) We define a new category PD_AMORPHOUS with data name peak_id. The refined parameters are identical to those in PD_PEAK so there is no need for further definitions, this category simply indicates which peaks are associated with an amorphous phase.

[briantoby]

PD_PEAK must handle peaks without hkl values. Not every pattern is indexed. Brian Sent from a powerful small device but with weak eyes. On Oct 16, 2022, at 9:08 PM, James Hester ***@***.***> wrote:  So the issue here is really "can we use PD_PEAK to describe an amorphous phase?", as all the other data names mentioned above seem to be used in the exact same way regardless of whether we are talking about an amorphous phase or not. Let's check what the current function of these peaks are in the pdCIF scheme: if we look where _pd_peak.id pops up, it is used solely to link a phase's h,k,l with an observed peak. So the concept is that a peak is located and refined against a peak shape model, and added to the PD_PEAK list. The crystal structure refinement then, quite separately from this list of peaks, predicts peak positions and intensities. So PD_PEAK is very much just for holding observed peaks for comparison with the model. Suppose we include our amorphous peaks in PD_PEAK. Their status in this list is of observed peaks, such as you might refine individually. These are not (conceptually at least) the amorphous model peaks, but perhaps the process of refining individual peak shapes and heights is essentially all that happens for amorphous models. So here are two alternatives: 1. (maximum) We could define a new category PD_AMORPHOUS with data name peak_id and any parameters that we refine per amorphous peak. 2. (minimum) We define a new category PD_AMORPHOUS with data name peak_id. The refined parameters are identical to those in PD_PEAK so there is no need for further definitions, this category simply indicates which peaks are associated with an amorphous phase. — Reply to this email directly, view it on GitHub<#23 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACH7E2AMPIHLC3BRMSAKTFLWDSYKHANCNFSM6AAAAAAQTRWXXY>. You are receiving this because you commented.Message ID: ***@***.***>

[rowlesmr]

So here are two alternatives:

1. (maximum) We could define a new category PD_AMORPHOUS with data name peak_id and any parameters that we refine per amorphous peak.
2. (minimum) We define a new category PD_AMORPHOUS with data name peak_id. The refined parameters are identical to those in PD_PEAK so there is no need for further definitions, this category simply indicates which peaks are associated with an amorphous phase.

I think 2. is enough; I think you'd otherwise just be repeating the contents of PD_PEAK in PD_AMORPHOUS

PD_PEAK must handle peaks without hkl values. Not every pattern is indexed.

From what I can see, PD_PEAKs can exist without being indexed, but the _pd_peak.id allows them to be linked to a specific hkl.

[briantoby]

One more comment here from the perspective of GSAS-II. We use peaks in two different ways. There is a peak table for use in profile fitting and indexing. Not usually used once a pattern is indexed, but we also allow users to define peaks in the background function (ideal use case is for samples in kapton tubes). Ostensibly both can be included in PD_PEAK, but I am pretty sure that GSAS-II would describe background peaks as text in the background description, if it does anything at all with them. Brian On Oct 21, 2022, at 8:59 AM, Matthew Rowles ***@***.******@***.***>> wrote: So here are two alternatives: 1. (maximum) We could define a new category PD_AMORPHOUS with data name peak_id and any parameters that we refine per amorphous peak. 2. (minimum) We define a new category PD_AMORPHOUS with data name peak_id. The refined parameters are identical to those in PD_PEAK so there is no need for further definitions, this category simply indicates which peaks are associated with an amorphous phase. I think #2<#2> is enough; I think you'd otherwise just be repeating the contents of PD_PEAK in PD_AMORPHOUS PD_PEAK must handle peaks without hkl values. Not every pattern is indexed. From what I can see, PD_PEAKs can exist without being indexed, but the _pd_peak.id<http://pd_peak.id> allows them to be linked to a specific hkl. — Reply to this email directly, view it on GitHub<#23 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACH7E2BUSU22AT2YMLUPUTLWEKOVLANCNFSM6AAAAAAQTRWXXY>. You are receiving this because you commented.Message ID: ***@***.***>

[jamesrhester]

OK, so it sounds like a minimal PD_AMORPHOUS category with a single peak_id data name would be sufficient at this stage. I don't do any amorphous phase calculations, but I would suppose that amorphous peaks and background peaks (e.g. as Brian said peaks from the container) are distinct entities, so the definition should state that background peaks do not belong in this category. Background description in the dictionary is currently in the same state as preferred orientation was, so in the future we will no doubt have a PD_BACKGROUND group of categories that actually lists background function coefficients and peaks.

[rowlesmr]

OK, so it sounds like a minimal PD_AMORPHOUS category with a single peak_id data name would be sufficient at this stage.

so it would look something like:

data_an_amorphous_phase
_pd_phase.id not_crystalline

loop_
_pd_amorphous.peak_id
1
2
3

loop_
_pd_peak.id
_pd_peak.2theta_centroid
_pd_peak.width_2theta
_pd_peak.intensity
1   23.45   2.12   1234
2   46.85   5.14   1254
3   67.45   3.15   1011

How are PD_PEAK peaks normally given (ignoring the possibility of being an amorphous phase)? Do they belong to the diffractogram? are they their own phase?