reflectivity with graphite 002

[srio]

On 8/25/22 10:28 AM, Yu Xiaojiang wrote:

Dear Manuel

I test the reflectivity with graphite 002 and Si 111 for two configurations, finding the angles on the plane crystals of graphite are same in two configures, but reflectivity is difference, NOT expected.

For Si 111, angles are different, so the different reflectivity is just expected.

Do you think the problem is from Shadow code?

Please see the setup in the workspace attached (please check in CRYSTAL widget, graphite is chosen, my crystal list in the xraylib may be different from you).

Best regards Xiaojian graphite_reflectivity.zip

[srio]

The results are similar for Graphite and Si, I mean you see that shadow autosetting sets the crystal to the "corrected Bragg angle" but using external profile, the crystal is set to the "uncorrected" Bragg angle. The latter is done by the interface, and cannot be done better.

For getting the angles that are really used in the calculation, you should see the o.e. "info", and here you see that for Graphite they are indeed (slightly!) different:

The numerical value you see in the interface is autofilled by the interface and corresponds to the Bragg angle and not to the corrected Bragg angle. It is only an indication (I accept that it could be confusing...).

Does this answers the question?

regards, Manuel

[91902078]

I use corrected bragg angle by choosing th-th bragg (corrected) in crystal widget for 2nd graphite config, I expect both curves almost overlapped in the center position, but not expect to get different

[91902078]

I use my version Shadow, in above setting, get overlapped in central position

my version has minor change in CRYSTAL subroutine in shadow_kernel.f90

[91902078]

For Si 111, if use same corrected bragg angle in CRYSTAL widget in 2nd configure, also get overlapped in central position

[srio]

I am not sure if I understood correctly the problem.

If I use autosetting in shadow, the histogram should be centered at zero (because it calculates the Bragg corrected angle) This happens with Graphite for the 3 ways to calculate the preprocessor file (v1, v2-dabax, v2-xraylib):

I get the same centered histogram if I do not use auto-setting and copy/paste the angles: Incidence Ang. 81.123721 deg Reflection Ang. 81.123721 deg

Up to here, it looks OK for me.

If you use external profile from xoppy/crystal, the shadow uses the angle defined in the "position" tab. This is changed when you have the xoppy/crystal widget connected and you "run" it. It is set at the uncorrected Bragg angle, so typically you see the resulting histogram not centered. But this is external to shadow3.

Another interesting point is your change in fortran. It looks at a first view that indeed you corrected a bug. But this is only affecting the v1 preprocessor. It is strange that I see no major differences in my comparison (see fig) from v1 (buggy?) to v2 (correct?). This I do not understand and would need a more careful look...

[91902078]

If Atomic mass not add to f0, then real part of refrac index is very small, delta is ~1, so the corrected Bragg angle theta_B is equal to uncorrectec theta (graze), but this is almost not affect the value of Darwin width, so histogram always centered around theta_B (angle 0), and with similar profile. But if one uses auto angle setting in plane crystal, the return corrected angle from shadow will be not correct (values shown in gray field), please compare this value with that inside the output tab of crystal widget.

---

From: Manuel Sanchez del Rio @.> Sent: Thursday, 25 August 2022 6:51 pm To: oasys-kit/shadow3 @.> Cc: Yu Xiaojiang @.>; Comment @.> Subject: Re: [oasys-kit/shadow3] reflectivity with graphite 002 (Issue #57)

    - External Email -

I am not sure if I understood correctly the problem.

If I use autosetting in shadow, the histogram should be centered at zero (because it calculates the Bragg corrected angle) This happens with Graphite for the 3 ways to calculate the preprocessor file (v1, v2-dabax, v2-xraylib): [image]https://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fuser%2dimages.githubusercontent.com%2f502315%2f186640148%2d3c8a5cb4%2dc96c%2d4e02%2d9c68%2dc0eb18a840ff.png&umid=443be26d-517c-4856-a28c-4833534b737b&auth=8d3ccd473d52f326e51c0f75cb32c9541898e5d5-2617aa01926123b2dac2b08e9bb770a84b7b8935

I get the same centered histogram if I do not use auto-setting and copy/paste the angles: Incidence Ang. 81.123721 deg Reflection Ang. 81.123721 deg

Up to here, it looks OK for me.

If you use external profile from xoppy/crystal, the shadow uses the angle defined in the "position" tab. This is changed when you have the xoppy/crystal widget connected and you "run" it. It is set at the uncorrected Bragg angle, so typically you see the resulting histogram not centered. But this is external to shadow3.

Another interesting point is your change in fortran. It looks at a first view that indeed you corrected a bug. But this is only affecting the v1 preprocessor. It is strange that I see no major differences in my comparison (see fig) from v1 (buggy?) to v2 (correct?). This I do not understand and would need a more careful look...

— Reply to this email directly, view it on GitHubhttps://ddec1-0-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com%2foasys%2dkit%2fshadow3%2fissues%2f57%23issuecomment%2d1227098205&umid=443be26d-517c-4856-a28c-4833534b737b&auth=8d3ccd473d52f326e51c0f75cb32c9541898e5d5-edb2c5acc71ca05b0b418eb88a34c3a157c096e5, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATNQXHJIGYRFWXXLZRTJ4A3V25F4VANCNFSM57SGVOOQ. You are receiving this because you commented.Message ID: @.***>

---

Important: This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately; you should not copy or use it for any purpose, nor disclose its contents to any other person. Thank you.

[srio]

Yes, it is a bug. I will fix and upgrade shadow3 soon (in 1 or 2 days). Thanks a lot for reporting the problem and giving the solution...

[srio]

Fixed in shadow3 22.8.25 shadowOui 1.5.202

[91902078]

Thanks!

[91902078]

Test successfully!