COMCIFS / magnetic_dic

Development of the magnetic CIF dictionary
0 stars 4 forks source link

We can now simplify _atom_site_moment_Fourier/..._moment_Fourier_param #25

Closed jamesrhester closed 1 year ago

jamesrhester commented 8 years ago

Following the move away from a requirement for single datanames that are unique in every looped list in the latest COMCIFS discussions, there is no longer any reason to separate _atom_site_moment_Fourier and _atom_site_moment_Fourier_params. Ideally, these two categories would merge, at the same time dropping the 'id' datanames and simply using the label/axis/wavevector datanames as unique keys into the loop rows. At the same time, there is no issue with simply keeping them as they are.

brantonc commented 1 year ago

I hesitate to make this change now that _atom_site_moment_Fourier_params is already in wide use in the ISOTROPY suite, the Bilbao Crystallographic Server, JANA, and the FullProf Suite.

brantonc commented 1 year ago

I remember the logic we employed while setting up child categories in the first place. Are other child categories in the magCIF dictionary like _atom_site_moment and _atom_site_rotation also no needed anymore?

jamesrhester commented 1 year ago

atom_site_moment makes sense as a child category because it will not take values for all atoms in the list, and so there is some symbolic space saving by only listing magnetic atoms in this separate loop instead of having potentially many atoms with a . in the moment-related columns if the categories were merged. The same is presumably true for atom_site_rotation. I raised this issue because there was no such advantage for the above categories - the same rows were populated for both categories, so if they were merged there wouldn't have been any blank entries.

Anyway, you've answered my original question so let's close this.