Implementation of multiprocessing for simpack.DynamicalModel

[VeryBitter]

Hello
I am a new and happy user of xrayutities, for high resolution omega-2theta scans. My scans extend over several degrees since I analyse GaAs/AlAs SL with period from 20 to 200 nm. Calculations within the DynamicalModel take quite a while, and it would be great to have multiprocessing features as for the powder model. Is that something that could be implemented easily?

Thanks a lot for making rayutilities available open-source, thanks for this great work.

[dkriegner]

How many periods/layers you have in your superlattice? Can you provide an example script and specify what "quite a while" means?

I need to think about the possibilities of parallelization, but I think it's not as easy as in PowderModel. It might be actually easier in this case to look into numexpr.

[VeryBitter]

Thanks for you very fast answer. 555 periods ! I know its a lot (and relaxation may occur). I will have look to numexpr.

[dkriegner]

yes 555 is a lot and the main loop in DynamicalModel goes over the layers and this is one which I think can't be parallelized, but its execution (loop body) could likely be optimized (maybe by numexpr). Any pull requests/patches are certainly welcome.

[VeryBitter]

Hi Dominique
back to this topic. I found out that the Darwin model was much faster when dealing with large superlattices. Is it related to the fact that every single layer produced by the loop has its own fitting parameters in the dynamical model? Maybe a superlattice layer model could be implemented, so that the fitting parameters would remain the same for each identical layer of the loop. Not sure I am clear... sorry. And not sure I have the skills to code it... sorry.

[dkriegner]

I don't know why Darwin model could be faster.
But I think linking the parameters in a superlattice is already possible by using lmfit features. Basically in the same way as you do in your new example. You have to basically set the parameter to be equal to a different one. In this way all equal layers in a super lattice can be made to be represented by one parameter

See

xrayutilities/examples/simpack_xrd_dyn_AlGaAs.py

Lines 118 to 120 in 0af8aa7

	# same composition as AlGaAs80_1
	fitmdyn.set_param_hint('AlAs_0_80_GaAs_0_20__1_c', vary=True,
	expr='AlAs_0_80_GaAs_0_20__c')

Note:
It would maybe be good for this to be a bit more usable to give a way to during construction of a Layer define a specific name: A change for this is required in this method I guess:

xrayutilities/lib/xrayutilities/simpack/smaterials.py

Lines 50 to 66 in 0af8aa7

	def __init__(self, material, **kwargs):
	"""
	initialize a simulation material by specifiying its Material and
	optional other properties
	Parameters
	----------
	material : Material (Crystal, or Amorphous)
	Material object containing optical/crystal properties of for the
	simulation; a deepcopy is used internally.
	kwargs : dict
	optional properties of the material needed for the simulation
	"""
	self.name = utilities.makeNaturalName(material.name, check=True)
	self.material = copy.deepcopy(material)
	for kw in kwargs:
	setattr(self, kw, kwargs[kw])

Currently the names of the layers are automatically generated from the underlaying materials name. An optional keyword argument in the mentioned function would likely be better and one can still fall back to using the materials name if nothing is specified.

[dkriegner]

Currently the names of the layers are automatically generated from the underlaying materials name. An optional keyword argument in the mentioned function would likely be better and one can still fall back to using the materials name if nothing is specified.

#169 picks up this idea and implements it.