Refactoring #1594

Feature #1290: === Core: framework ===

Review and possibly refactor IFormFactor class hierarchy

Added by herck over 4 years ago. Updated about 4 years ago.

Status:ArchivedStart date:23 Aug 2016
Priority:NormalDue date:
Assignee:herck% Done:

0%

Category:-
Target version:Sprint32

Description

It seems that conceptually all concrete IFormFactor classes (with the exception of the two DWBA form factors) could be directly derived from IFormFactorBorn. Investigate this possibility and refactor accordingly. This is related to an issue with FormFactorCrystal, which now

History

#1 Updated by herck over 4 years ago

Currently, IFormFactorBorn does not only represent form factors that only depend on the wavevector transfer q, but there also exists a distinction in the treatment of polarized/non-polarized evaluation. To make IFormFactorBorn truly represent all from factors that only depend on q, an extra virtual evaluate_for_q_pol(...) would be needed (which can be given a default implementation that returns the scalar value times the unit matrix). Because of the dependency of the scattering density of a material on the wavelength, FormFactorDecoratorMaterial cannot be moved under IFormFactorBorn for now. This then recursively applies to all decorators, to FormFactorCrystal and FormFactorWeighted.

#2 Updated by wuttke about 4 years ago

This is related to #409, right?

#3 Updated by wuttke about 4 years ago

  • Parent task set to #1290

#4 Updated by herck about 4 years ago

  • Status changed from Sprint to Resolved

#5 Updated by herck about 4 years ago

  • Status changed from Resolved to Archived

Also available in: Atom PDF