BornAgain: Issueshttp://apps.jcns.fz-juelich.de/redmine/http://apps.jcns.fz-juelich.de/redmine/redmine/favicon.ico2019-11-21T13:19:15ZScientific Computing Group
Redmine Feature #2423 (Backlog): Core: add posterior normalization for reflectivity curveshttp://apps.jcns.fz-juelich.de/redmine/issues/24232019-11-21T13:19:15Zdmitryd.yurov@fz-juelich.de
<p>Good first issue.</p>
<p>It can be implemented as an additional unit for representation (in the same way as RQ^4, q-space, degrees, etc.).<br />Such normalization can come handy for fitting data with noticeable footprint effect.<br />If normalization is not applied in this case and the footprint is one of the fit parameters,<br />intensity has to be adjusted at each fitting step.</p> Feature #2422 (Backlog): Core: add free-form resolution for reflectometryhttp://apps.jcns.fz-juelich.de/redmine/issues/24222019-11-21T12:37:22Zdmitryd.yurov@fz-juelich.de
<p>Good first issue.</p>
<p>Currently BA features only predefined resolution functions (though one can set different standard deviations for each point on x-axis) in reflectivity simulations.</p>
<p>It is useful to let the user define a free-form distribution as a piecewise-linear function.<br />From the interface viewpoint, it can look like defining a free-form distribution</p>
<p><strong>distr = ba.RangedDistributionFreeForm(n_points, n_sig)</strong></p>
<p>exactly like already existing ones, and then setting it together with probability values to a scan</p>
<p><strong>scan.setAbsoluteQResolution(distr, q_val, q_prob)</strong></p>
<p>Here <strong>q_val</strong> is a n-by-m matrix, with m being the number of on-axis points, n - the number of points in piecewise-linear distribution for each on-axis point.<br /><strong>q_prob</strong> is a corresponding n-by-m matrix with probability values.</p>
<p>In case of angle-based reflectivity, the scan should feature two independent free-form distributions - for wavelength and angle.</p> Refactoring #2421 (Backlog): Core: instrument: Remove remnants of old-style divergence definition...http://apps.jcns.fz-juelich.de/redmine/issues/24212019-11-20T16:16:00Zdmitryd.yurov@fz-juelich.de
<p>Good first issue.</p>
<p>Since a better (pointwise) resolution mechanism is available for reflectometry,<br />one can remove adaptations for old resolution handling with parameter pool.</p>
<p>Namely, all the pieces with the note "TODO: remove when pointwise resolution is implemented" can be deleted from SpecularSimulation.cpp.</p>
<p>Setting resolutions through parameter pool must be then directly prohibited for specular reflectivity.</p> Feature #2420 (Backlog): TO DISCUSS: Switch back to previous 1D (interactive) data loaderhttp://apps.jcns.fz-juelich.de/redmine/issues/24202019-11-20T15:41:52Zdmitryd.yurov@fz-juelich.de
<p>The interactive loader provided a more reach functionality (e.g. data scaling and choice of units) than the currently used default-only approach.<br />The defaults can be adjusted to coincide with parameters assumed in current default-only loader.</p>
<p>In the future the loader can be expanded / rewritten, but for the time being it is definitely the best option.</p> Feature #2418 (Backlog): Polarized: support polarized reflectivity in GUIhttp://apps.jcns.fz-juelich.de/redmine/issues/24182019-11-20T12:52:23Zdmitryd.yurov@fz-juelich.de
<p>It is necessary to add <strong>PolarizationAnalysisEditor</strong> to <strong>SpecularInstrumentEditor</strong>.<br />One can use <strong>GISASInstrumentEditor</strong> as an example.<br />It will also require an adaptation of <strong>SpecularInstrumentItem</strong> (in order to use it together with the <strong>PolarizationAnalysisEditor</strong>).<br />Namely, one will need to add <strong>DetectorItem</strong> to it.</p>
<p>Afterwords one can revert the commit 7cace6d7f88ba65e0601c0f034cf912106883a65 - it was necessary to mute magnetic field parameters for specular instrument.</p> Feature #2417 (Backlog): Polarized: support z-component of magnetic fieldhttp://apps.jcns.fz-juelich.de/redmine/issues/24172019-11-20T11:47:45Zdmitryd.yurov@fz-juelich.de
<p>As described in section 1.1 of <a href="https://jugit.fz-juelich.de/mlz/intern/ba-intern/blob/master/theory/SpecularReflectivity/PolarizedSpecular.pdf" class="external">this internal report</a>,<br />external magnetic field is subtracted during the computation of the wave reflected from magnetized sample.<br />In the section 1.2 of the same document it is stated, that z-component of the magnetic field (that is, the one normal to the sample surface)<br />must be constant across the sample.</p>
<p>As the result, z-component of magnetic field, B_z, is always nullified during the computation.<br />It would be useful to check how it is treated in other codes.<br />For example, GenX considers only the angle between beam polarization and the direction of the magnetic field, thus avoiding direct treatment of z-component.<br />This approach however does not allow for not fully polarized beams and imperfect analyzers.</p>
<p>Anyhow, B_z nullifying has a counter-intuitive behavior, since a user can specify any B_z in the layers,<br />but it will not affect the result of computation.</p> Bug #2416 (Backlog): Polarized: Fix treatment of imperfect analyzershttp://apps.jcns.fz-juelich.de/redmine/issues/24162019-11-20T10:45:10Zdmitryd.yurov@fz-juelich.de
<p>Currently the analyzer operator used in BornAgain is written (in latex notation) as</p>
<p>a = t (1 + \xi \sigma p).</p>
<p>Here t is the transmission, \xi - efficiency, p - vector of analyzer direction, \sigma - vector of Pauli matrices.<br />However, only the combination of t = 1/2, \xi = 1 and |p| = 1 is meaningful and corresponds<br />to a perfect analyzer (i.e. the one always selecting a particular polarization state).</p>
<p>According to the section 4 of <a href="https://jugit.fz-juelich.de/mlz/intern/ba-intern/blob/master/theory/SpecularReflectivity/PolarizedSpecular.pdf" class="external">this internal report</a><br />(note that login to jugit is required to access the document), the analyzer operator should look like</p>
<p>a = \frac{t}{2} (2 - |p| + \sigma p).</p>
<p>Then |p| <= 1 corresponds to the efficiency of the analyzer and 0 <= t <= 1 - to the transmission.</p>
<p>The formula above for sure works for specular reflectivity, but before modifying the code it is necessary<br />to check that it holds true in the case of GISAS. <a href="https://jugit.fz-juelich.de/mlz/intern/ba-intern/blob/master/theory/NanoParticles/DWBAPolarized.pdf" class="external">The description of polarized DWBA by Walter Van Herck</a> can provide some insight in how DWBA is applied in BornAgain.</p>
<p>The analyzer operator is computed in <strong>DetectionProperties::analyzerOperator</strong>.<br />One will also need to change the signature of the method <strong>setAnalyzerProperties</strong> in <strong>Simulation</strong> class, and correspondingly amend polarization-related classes in the GUI.</p> Feature #2415 (Backlog): Polarized: validate reflectivity against other softwarehttp://apps.jcns.fz-juelich.de/redmine/issues/24152019-11-20T09:36:31Zdmitryd.yurov@fz-juelich.de
<p>One needs to make sure that BornAgain produces the same result as other<br />codes capable of polarized reflectivity. One can take <a href="https://sourceforge.net/projects/genx/" class="external">GenX</a> or <a href="https://github.com/reflectometry/refl1d" class="external">Refl1D</a> for comparison.<br />Note that all the three codes differ in the input format for magnetic field and layer properties.</p>
<p>The numerical stability of the polarized implementation can be probed by comparing it to a scalar computation with a modified SLD, according to the applied magnetic field. <br />This applies to samples where the magnetic field is (anti)parallel to the polarization.</p> Feature #2414 (Backlog): Polarized: enable specular signal for polarized GISAShttp://apps.jcns.fz-juelich.de/redmine/issues/24142019-11-20T09:32:01Zdmitryd.yurov@fz-juelich.de
<p>Can be enabled in <strong>GISASSpecularComputation::compute</strong></p> Refactoring #2410 (Backlog): Core: beam propagation: Speeding up computations on samples with a l...http://apps.jcns.fz-juelich.de/redmine/issues/24102019-10-21T08:23:41Zdmitryd.yurov@fz-juelich.de
<p>Despite recent <a href="https://github.com/scgmlz/BornAgain/pull/878" class="external">speed up</a> in computations on a large number of layers,<br />the computation complexity is still O(N^2), where N is the number of layers in the sample.<br />The computation engine is capable of working with worst-case complexity of O(N logN).</p>
<p>The reason for such slow computations is in <code>INode::createParameterTree()</code>:</p>
<p>1. To build string paths it computes the number of copies of same-type objects in the sample.<br />Each of the uniform objects requires the counting of its siblings, total complexity of the computation<br />being O(N^2). This problem can be solved as in <a href="https://github.com/scgmlz/BornAgain/pull/881" class="external">pull-request 881</a>,<br />providing 1.5 times speed-up on 1000 layer-thick sample.</p>
<p>2. Second problem is the string concatenation and reallocation: if optimized, it can provide another factor of 2 speed-up on 1000 layers.<br />One can find a screenshot of kcachegrind output in the same <a href="https://github.com/scgmlz/BornAgain/pull/881" class="external">PR</a>.</p>
<p>To measure the performance, one can use the dedicated performance test in Tests/Functional/Core/CoreSpecial/MultilayerPerformanceTest.(h,cpp)</p> Bug #2403 (Backlog): Units: upon GUI import, int.gz file with reflectometry data shows Q units bu...http://apps.jcns.fz-juelich.de/redmine/issues/24032019-09-05T15:26:49Zdmitryd.yurov@fz-juelich.deRefactoring #2376 (Long Term Idea): Fit: Look for an alternative to root minimizershttp://apps.jcns.fz-juelich.de/redmine/issues/23762019-06-05T11:14:23Zdmitryd.yurov@fz-juelich.de
<p>Root library covers lots of very different minimizers under one umbrella.<br />However it lacks some modern minimizers (e.g. differential evolution)<br />which could be handy. Besides it costs big efforts to support the<br />interfacing and bring all the minimizers to stable functioning.</p>
<p>I would give a try to <a href="https://github.com/kthohr/optim" class="external">OptimLib</a></p> Feature #2335 (Backlog): Fit: Non-obvious way of constructing custom evaluate function for FitObj...http://apps.jcns.fz-juelich.de/redmine/issues/23352019-04-03T12:02:08Zdmitryd.yurov@fz-juelich.de
<p>evaluate function defined in python will not work properly without calling evaluate_residuals.<br />In particular, it will not call an update of fit status. When evaluate_residuals is used, it shows<br />objective function value for built-in chi-square instead of user-defined metrics.</p> Feature #1068 (Backlog): GUI: provide SLD profile viewhttp://apps.jcns.fz-juelich.de/redmine/issues/10682015-05-08T17:55:37Za.glavicartur.glavic@psi.ch
<p>Often you would want to build a model after fitting specular reflectivity data. It would be very helpful in defining the layer structure and materials if there were a small graph on the GUI Sample tab showing the SLD profile of the current model.</p> Feature #1032 (Long Term Idea): Core: Rotation of inter-particle structureshttp://apps.jcns.fz-juelich.de/redmine/issues/10322015-04-07T21:29:15Za.glavicartur.glavic@psi.ch
<p>For the simulation of 2D arbitrary orientation of ordered structures like lattices of non-spherical particles the simulation needs to be carried out for different lattice rotations including rotation of unit vectors and particles. This can become very tricky when more then one particle is inside the unit cell.<br />A possibility to rotate the sample xy-coordinate system with respect to the incident beam would be helpful.</p>