Closed jamesrhester closed 1 year ago
An idea:
_pd_phase.is_amorphous
_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
#...
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:
For example:
data_theStd _pd_block.idhttp://pd_block.id std _pd_block_diffractogram.idhttp://pd_block_diffractogram.id diffpat
data_thePyritePhase _pd_block.idhttp://pd_block.id pyrite _pd_block_diffractogram.idhttp://pd_block_diffractogram.id diffpat
data_theAlbitePhase _pd_block.idhttp://pd_block.id albite _pd_block_diffractogram.idhttp://pd_block_diffractogram.id diffpat
data_theAmorPhase _pd_block.idhttp://pd_block.id amor _pd_block_diffractogram.idhttp://pd_block_diffractogram.id diffpat _pd_phase.isamorphous yes loop _pd_peak.d_spacing _pd_peak.intensity 14.7 123 10.5 324
data_aDiffractionPattern _pd_block.idhttp://pd_block.id diffpat
loop_ _pd_phase.idhttp://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 GitHubhttps://github.com/COMCIFS/Powder_Dictionary/issues/23#issuecomment-1271748872, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACH7E2CUB2UC7UOLCGAZHODWCA7JHANCNFSM6AAAAAAQTRWXXY. You are receiving this because you are subscribed to this thread.Message ID: @.***>
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.
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:
PD_PHASE
as suggested above so that it is not restricted to crystalline phasesI 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.
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.
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:
PD_AMORPHOUS
with data name peak_id
and any parameters that we refine per amorphous peak.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.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:
— Reply to this email directly, view it on GitHubhttps://github.com/COMCIFS/Powder_Dictionary/issues/23#issuecomment-1280173325, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACH7E2AMPIHLC3BRMSAKTFLWDSYKHANCNFSM6AAAAAAQTRWXXY. You are receiving this because you commented.Message ID: @.***>
So here are two alternatives:
- (maximum) We could define a new category
PD_AMORPHOUS
with data namepeak_id
and any parameters that we refine per amorphous peak.- (minimum) We define a new category
PD_AMORPHOUS
with data namepeak_id
. The refined parameters are identical to those inPD_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_PEAK
s can exist without being indexed, but the _pd_peak.id
allows them to be linked to a specific hkl.
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:
I think #2https://github.com/COMCIFS/Powder_Dictionary/issues/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.idhttp://pd_peak.id allows them to be linked to a specific hkl.
— Reply to this email directly, view it on GitHubhttps://github.com/COMCIFS/Powder_Dictionary/issues/23#issuecomment-1287007819, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACH7E2BUSU22AT2YMLUPUTLWEKOVLANCNFSM6AAAAAAQTRWXXY. You are receiving this because you commented.Message ID: @.***>
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.
OK, so it sounds like a minimal
PD_AMORPHOUS
category with a singlepeak_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?
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.