Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crystalfield bugfixes #21604

Merged
merged 29 commits into from
Feb 22, 2018
Merged

Crystalfield bugfixes #21604

merged 29 commits into from
Feb 22, 2018

Conversation

mducle
Copy link
Member

@mducle mducle commented Jan 21, 2018

This is a collection of bugfixes for the CrystalField calculations routines since the back-end was rewritten last autumn. Due to the changes in the back-end some workflows (which don't have system tests) became broken, and this was not picked up in the unit tests.

The major changes are in the handling of peak widths (setting a resolution model disables peak with fitting and invalidates the .FWHM property; setting .FWHM invalidates a resolution model; previously the behaviour when both are set was ambiguous and in some cases wrong (e.g. fixed FWHM at starting value given in .FWHM)), and in the multi-site routines (particularly handling of background).

In addition, due to requests from users, two additional features were added:

  1. The ability to calculate the dipole transition matrix
  2. The ability to add a residual (background) susceptibility (chi0) to the susceptibility calculations.

The first feature is purely Python, the second involved some C++ changes.

Most of the bugs were in the Python interface (e.g. the arbitrary J calculations was mistakenly removed in the Python interface but the C++ remained), but there were some C++ changes (particularly handling the peak widths) needed.

To test:

Code review and check automated tests run ok.

Test scripts and related datafiles are in the following zip:
cf_test_scripts.zip
Unzip and add the data folder to the Mantid data path and reduction_scripts to the Mantid scripts path and run.

A new system test based on the cf_doc.py file has been added to check that the python syntax works (it runs some fits but the results are not checked - the unit tests are used for checked the numerical validity of the computations).

Fixes #20990

Release Notes

Release notes included.


Reviewer

Please comment on the following (full description):

Code Review
  • Is the code of an acceptable quality?
  • Does the code conform to the coding standards?
  • Are the unit tests small and test the class in isolation?
  • If there are changes in the release notes then do they describe the changes appropriately?
Functional Tests
  • Do changes function as described? Add comments below that describe the tests performed?
  • Do the changes handle unexpected situations, e.g. bad input?
  • Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

@mducle mducle added the Direct Inelastic Issues and pull requests related to direct inelastic label Jan 21, 2018
Copy link
Contributor

@mantid-roman mantid-roman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CrystalFieldControl has field std::vector<int> m_physprops which I think is never used. Can it be deleted?

if (m_FWHMs.size() == 1 && m_FWHMs.size() != nSpec) {
m_FWHMs.assign(nSpec, m_FWHMs.front());
}
if (attr.asVector().size() > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use empty()? attr.asVector() creates a new copy of the vector. Can you use m_FWHMs instead?

}
} else if ((name.compare(0, 5, "FWHMX") == 0 ||
name.compare(0, 5, "FWHMY") == 0) &&
attr.asVector().size() > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same as above

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mantid-roman I can't find a way to avoid using asVector in this case. attr.isEmpty() implicitly assumes the attribute is a string, and so raises an exception in this case (where the attribute is a vector), and there's no other public method to access the contents of the attribute except to using the as* methods...

Copy link
Contributor

@mantid-roman mantid-roman Feb 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you then use !attr.asVector().empty() ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I'll do that.

Copy link
Contributor

@mantid-roman mantid-roman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of minor issues.

@@ -91,7 +91,7 @@ class MANTID_CURVEFITTING_DLL CrystalFieldControl
/// Cache number of fitted peaks
// mutable std::vector<size_t> m_nPeaks;
/// Cache the list of "spectra" corresponding to physical properties
std::vector<int> m_physprops;
// std::vector<int> m_physprops;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you delete this line please? And the m_nPeaks definition as well.

@@ -139,6 +139,18 @@ void CrystalFieldSusceptibilityBase::function1D(double *out,
} else {
calculate(out, xValues, nData, m_en, m_wf, m_nre, H, convfact);
}
const double lambda = getParameter("Lambda");
if (fabs(lambda) > 1.e-6) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you define a named constant (all upper case) for 1.e-6?

@@ -27,18 +27,19 @@ where :math:`N_A` is Avogadro's constant, :math:`k_B` is Boltzmann's constant, :
crystal field Hamiltonian. :math:`g_J` is the Landé g-factor, :math:`\mu_B` is the Bohr magneton and the moment operator
is defined as :math:`\mathbf{J} = \hat{J}_x B_x + \hat{J}_y B_y + \hat{J}_z B_z` where :math:`\hat{J}_x`, :math:`\hat{J}_y`,
and :math:`\hat{J}_z` are the angular momentum operators in Cartesian coordinates, with :math:`z` defined to
be along the quantisation axis of the crystal field (which is usually defined to be the highest symmetry rotation axis).
be along the quantisation axis of the crystal fied (which is usually defined to be the highest symmetry rotation axis).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mistype?

@@ -261,6 +314,10 @@ def makePhysicalPropertiesFunction(self, i=0):
if len(fieldParams) > 0:
out += ',%s' % ','.join(['%s=%s' % item for item in fieldParams.items()])
ties = self._getFieldTies()
if ppobj.TypeID == 2:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using numbers as type ids is no ideal. Can they be replaced by named constants?

@martyngigg martyngigg merged commit 0728c32 into master Feb 22, 2018
@martyngigg martyngigg deleted the 20990_crystalfield_bugfixes branch February 22, 2018 16:27
@rosswhitfield
Copy link
Member

The CrystalFieldPythonInterface system tests fails with python 3 because we don't have PyCifRW for python 3. @martyngigg can we update the Mantid ppa to include a python 3 build and we probably should bump the version to the newest 4.4?

@martyngigg
Copy link
Member

@rosswhitfield Sure. I'm in the deb packaging zone with bibtex anyway!

@martyngigg
Copy link
Member

@rosswhitfield The updated version is in the PPA and has the Python 3 packages too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Direct Inelastic Issues and pull requests related to direct inelastic
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CrystalField and CrystalFieldMulti bugs
4 participants