[mcstas-users] TOFRes_sample
Ryoichi Kajimoto
ryoichi.kajimoto at j-parc.jp
Thu Oct 26 12:16:05 CEST 2023
Dear Peter,
Thank you for updating the component files. They worked with my instr file on McStas 3.4! I appreciate it.
However, I found that pf has the same value as pi, having large numbers. Previously (McStas 2.7), pf was always unity.
According to the component manual of Res_monitor, pf is "the relative neutron weight adjustment from sample to detector." I guess from this explanation that pf should be <= 1. Is the current behavior of pf correct?
Best regards,
Ryoichi
Peter Kjær Willendrup wrote on 2023/10/25 22:28:
> Dear Ryoichi,
>
>
> I believe your understanding of the component geometry is correct, and in fact there was a minor logical issue for the case of thickness=0.
> (In the attached t1 and t2 are derived from the “outer hollow” both in the case of thickness=0 or if hollow exists but is not hit - including use of || instead of &&)
>
> I have further taken the time to clean up a few lines of “dead code” and have dusted of a VERY old test instrument that I found, ported for use with 3.4.
>
> Finally I have attached a new TOFRes_monitor.comp - which for structural reasons is now needed.
> (We use a macro that makes use of the literal Res_sample / TOFRes_sample label to figure out what parameter struct needs to be probed.)
>
> In other words, Res_sample and Res_monitor is a pair, TOFRes_sample and TOFRes_monitor is a slightly different pair…. Slightly annoying.
>
> I may eventually merge the two sample components allowing two different “modes” to get rid of this new derived monitor, but that will have to wait.
>
>
> I have run a quick test with the attached files and McStas 3.4 - and produce normal “Res_monitor” like output, so I think this should be an OK solution for now.
>
> Please try it out for yourself and come back with your findings.
>
>
> All of the attached codes are also uploaded to the main branch on GitHub and any comments/further revisions are most welcome, e.g. on
> https://github.com/McStasMcXtrace/McCode/issues/1512 <https://github.com/McStasMcXtrace/McCode/issues/1512>
>
>
> Best,
> Peter
>
>
>> On 25 Oct 2023, at 08.04, Ryoichi Kajimoto <ryoichi.kajimoto at j-parc.jp> wrote:
>>
>> Dear Kim,
>>
>> To my understanding, the meaning of the code is like the attached figure. Is my understanding correct?
>> If this is correct, l_full becomes large when thickness is large, while scat_factor = 2*(radius-thickness) becomes small. Then l_full/scat_factor becomes extremely large.
>>
>> With regard to this, I found that when thickness = 0, which is default, or thickness = radius, the code does not generate an output data. (I tested this with McStas 2.7.2)
>>
>> I guess that:
>> - When thickness = 0, t1 = t0 and t3 = t2. This results in l_full = p = 0.
>> (Function cylinder_intersect(&t1, &t2, x, y, z, vx, vy, vz, radius-thickness, yheight) in line 167 is executed even when thickness = 0.)
>> - When thickness = radius, scat_factor becomes zero, and p becomes infinity (divided by zero).
>>
>> Best regards,
>>
>> Ryoichi
>>
>> Kim Lefmann wrote on 2023/10/24 18:58:
>>> Dear Ryoichi,
>>> You are right that in this case scat_factor becomes small - but so does l_full since materials thickness is small. So the fraction is in any case of the order 1.
>>> Of course if you were interested in absolute intensities, the cross section should be weighted differently, as we do in the more realistic samples.
>>> best, Kim
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> *From:* Ryoichi Kajimoto <ryoichi.kajimoto at j-parc.jp>
>>> *Sent:* Tuesday, October 24, 2023 11:14:59 AM
>>> *To:* Kim Lefmann; pkwi at dtu.dk
>>> *Cc:* mcstas-users at mcstas.org
>>> *Subject:* Re: [mcstas-users] TOFRes_sample
>>> [You don't often get email from ryoichi.kajimoto at j-parc.jp. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
>>> Dear Kim,
>>> Thank you for explaining the detail.
>>> Maybe I understand.
>>> My question is that if scat_factor = 2*(radius-thickness), it becomes very small when thickness is nearly equal to radius. Then l_full/scat_factor becomes extremely large, which seems to be unreasonable.
>>> Anyhow it may not be a problem because the absolute intensity is not important in resolution calculation.
>>> Best regards,
>>> Ryoichi
>>> Kim Lefmann wrote on 2023/10/24 17:34:
>>>> Dear Ryoichi,
>>>>
>>>> Since I wrote the code, please let me explain the logic.
>>>>
>>>> For a resolution calculation, the absolute intensity is irrelevant, since you only want to know the widths.
>>>>
>>>> The weighing using the fraction l_full/scat_factor is done to correct for the fact that the outer parts of the sample scatter differently from the center part due to different path lengths:
>>>>
>>>> l_full is exactly the path length in the sample of this neutron ray
>>>> scat_factor is the path length for a ray that hits the sample center (and is constant for the full simulation).
>>>>
>>>> The latter path length is used as normalization (and to ensure that the units are correct).
>>>>
>>>> best, Kim
>>>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>> *From:* mcstas-users <mcstas-users-bounces at mcstas.org> on behalf of Ryoichi Kajimoto <ryoichi.kajimoto at j-parc.jp>
>>>> *Sent:* Tuesday, October 24, 2023 9:40:56 AM
>>>> *To:* pkwi at dtu.dk
>>>> *Cc:* mcstas-users at mcstas.org
>>>> *Subject:* Re: [mcstas-users] TOFRes_sample
>>>>
>>>> [You don't often get email from ryoichi.kajimoto at j-parc.jp. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> <https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification>> ]
>>>>
>>>> Dear Peter,
>>>>
>>>>> Wrt. the scat_factor, since thickness is an optional parameter (default=0, parametrises an optional "inner hollow”) I believe the formula is OK.
>>>> Thanks, but there is a line in line 176:
>>>> p *= l_full/scat_factor; /* Scattering probability */
>>>> where l_full is "Length of full path through sample."
>>>>
>>>> It seems to me that p is defined as the ratio of length of full path through sample to total size of sample. However, if scat_factor is as it is, p can be larger than unity.
>>>>
>>>> Best regards,
>>>>
>>>> Ryoichi
>>>>
>>>>
>>>> Peter Kjær Willendrup wrote on 2023/10/24 16:12:
>>>>> Dear Ryochi,
>>>>>
>>>>> Once I have the edits in place and a running instrument I will send the modified component to this mailinglist thread.
>>>>>
>>>>> Wrt. the scat_factor, since thickness is an optional parameter (default=0, parametrises an optional "inner hollow”) I believe the formula is OK.
>>>>>
>>>>> Best
>>>>> Peter
>>>>>
>>>>> On 24 Oct 2023, at 07.20, Ryoichi Kajimoto <ryoichi.kajimoto at j-parc.jp> wrote:
>>>>>
>>>>> Dear Peter,
>>>>>
>>>>> Thank you for the prompt response. I hope this issue will be solved soon.
>>>>>
>>>>> I have another question regarding TOFRes_sample.
>>>>>
>>>>> On line 169 of TOFRes_sample.comp, there is a code:
>>>>> scat_factor = 2*(radius-thickness);
>>>>>
>>>>> But is this correct? I think scat_factor should be 2*radius.
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Ryoichi
>>>>>
>>>>> Peter Kjær Willendrup wrote on 2023/10/24 3:07:
>>>>> Dear Ryoichi Kajimoto,
>>>>>
>>>>>
>>>>> Thank you for reporting this issue, you are completely right in pointing out that needed modifications are missing in the McStas 3.4 version of TOFRes_sample.
>>>>> (This has gone unnoticed since a test-instrument for the said component was not defined in our test suite, sorry for this.)
>>>>>
>>>>> I have defined a GitHub issue at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMcStasMcXtrace%2FMcCode%2Fissues%2F1512&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=94nRHavpkrZdgXTsClxXqFXDpVH5DuAZ1gf9tER8tpM%3D&reserved=0 <https://github.com/McStasMcXtrace/McCode/issues/1512> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMcStasMcXtrace%2FMcCode%2Fissues%2F1512&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=94nRHavpkrZdgXTsClxXqFXDpVH5DuAZ1gf9tER8tpM%3D&reserved=0
>>>>> <https://github.com/McStasMcXtrace/McCode/issues/1512>> and will implement the needed
>>> changes as soon as time allows.
>>>>>
>>>>>
>>>>> Best,
>>>>> Peter Willendrup
>>>>>
>>>>> On 23 Oct 2023, at 13.29, Ryoichi Kajimoto <ryoichi.kajimoto at j-parc.jp> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm simulating a resolution function of a direct-geometry TOF spectrometer. I use TOFRes_sample() for the sample and Res_monitor() for the monitor.
>>>>>
>>>>> My code worked with McStas 3.1, but it cannot be compiled with McStas 3.4.
>>>>> I would appreciate if you could provide any solution.
>>>>>
>>>>> Converting the .instr file to .c with mcstas command worked fine without an error, but compiling it with gcc -O3 -lm stops with an error message attached below.
>>>>>
>>>>> I found that Res_monitor.comp and Res_sample.comp were greatly updated in McStas 3.4 but TOFRes_sample.comp was unchanged. I suspect that TOFRes_sample.comp is not compatible with Res_monitor.comp...
>>>>>
>>>>> Thank you in advance,
>>>>>
>>>>> Ryoichi Kajimoto
>>>>>
>>>>>
>>>>> ==================================
>>>>>
>>>>> SIKIResSim.c: In function ‘Table_Read_Handle’:
>>>>> SIKIResSim.c:7518:60: warning: format ‘%i’ expects argument of type ‘int’, but argument 5 has type ‘long int’ [-Wformat=]
>>>>> 7518 | fprintf(stderr,"Warning: Read_Table :%s %s Data has %i invalid lines (*****). Ignored.\n",
>>>>> | ~^
>>>>> | |
>>>>> | int
>>>>> | %li
>>>>> ......
>>>>> 7521 | count_invalid);
>>>>> | ~~~~~~~~~~~~~
>>>>> | |
>>>>> | long int
>>>>> SIKIResSim.c: In function ‘_resmonitor_setpos’:
>>>>> SIKIResSim.c:13221:6: error: ‘RSsample’ undeclared (first use in this function)
>>>>> 13221 | if(RSsample && strlen(RSsample))
>>>>> | ^~~~~~~~
>>>>> SIKIResSim.c:13221:6: note: each undeclared identifier is reported only once for each function it appears in
>>>>> SIKIResSim.c: In function ‘class_Res_monitor_init’:
>>>>> SIKIResSim.c:663:33: warning: format not a string literal and no format arguments [-Wformat-security]
>>>>> 663 | #define NAME_CURRENT_COMP (_comp->_name)
>>>>> | ~~~~~~^~~~~~~~
>>>>> SIKIResSim.c:13781:48: note: in expansion of macro ‘NAME_CURRENT_COMP’
>>>>> 13781 | if (!strcmp(filename,"\0")) sprintf(filename,NAME_CURRENT_COMP);
>>>>> | ^~~~~~~~~~~~~~~~~
>>>>> SIKIResSim.c:641:10: error: ‘_class_Res_sample_parameters’ undeclared (first use in this function); did you mean ‘_class_TOFRes_sample_parameters’?
>>>>> 641 | &( ((_class_ ## type ##_parameters *) _getvar_parameters(compname))->par )
>>>>> | ^~~~~~~
>>>>> SIKIResSim.c:13835:18: note: in expansion of macro ‘COMP_GETPAR3’
>>>>> 13835 | int *index_ptr=COMP_GETPAR3(Res_sample, res_sample_comp, compindex);
>>>>> | ^~~~~~~~~~~~
>>>>> SIKIResSim.c:641:41: error: expected expression before ‘)’ token
>>>>> 641 | &( ((_class_ ## type ##_parameters *) _getvar_parameters(compname))->par )
>>>>> | ^
>>>>> SIKIResSim.c:13835:18: note: in expansion of macro ‘COMP_GETPAR3’
>>>>> 13835 | int *index_ptr=COMP_GETPAR3(Res_sample, res_sample_comp, compindex);
>>>>> | ^~~~~~~~~~~~
>>>>>
>>>>> ==================================
>>>>>
>>>>> This is how I use TOFRes_sample() and Res_monitor():
>>>>>
>>>>> ==================================
>>>>>
>>>>> SPLIT COMPONENT RSsample = TOFRes_sample(
>>>>> thickness = sample_r-0.0001,
>>>>> radius = sample_r,
>>>>> yheight = sample_h,
>>>>> focus_xw = Wdx+0.001,
>>>>> focus_yh = Wdy+0.001,
>>>>> target_x = sample_det_x,
>>>>> target_y = sample_det_y,
>>>>> target_z = sample_det_z,
>>>>> time_bin = (ts+tsd+toffset)*1e6,
>>>>> time_width = Dtsd*1e6
>>>>> ) AT (0,0,L1) RELATIVE mod
>>>>>
>>>>> COMPONENT det_pos = Arm()
>>>>> AT (sample_det_x,sample_det_y,sample_det_z) RELATIVE RSsample
>>>>> ROTATED (0,atan(sample_det_x/sample_det_z)*RAD2DEG,0) RELATIVE RSsample
>>>>>
>>>>> COMPONENT resmonitor = Res_monitor(
>>>>> res_sample_comp = RSsample,
>>>>> options = "cylinder",
>>>>> xwidth = Wdx, yheight = Wdy,
>>>>> filename = "resmonitor.dat"
>>>>> ) AT (0,0,0) RELATIVE det_pos
>>>>> _______________________________________________
>>>>> mcstas-users mailing list
>>>>> mcstas-users at mcstas.org
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman2.mcstas.org%2Fmailman%2Flistinfo%2Fmcstas-users&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v%2FzSDXQAZGU0cX2pdVG7nQgqZfCVuwdDig1alrUoZhw%3D&reserved=0 <https://mailman2.mcstas.org/mailman/listinfo/mcstas-users> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman2.mcstas.org%2Fmailman%2Flistinfo%2Fmcstas-users&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v%2FzSDXQAZGU0cX2pdVG7nQgqZfCVuwdDig1alrUoZhw%3D&reserved=0 <https://mailman2.mcstas.org/mailman/listinfo/mcstas-users>>
>>>>>
>>>>>
>>>>> Peter Kjær Willendrup
>>>>> Forskningsingeniør, Specialkonsulent
>>>>>
>>>>> DTU Physics
>>>>> [image001.gif]
>>>>>
>>>>>
>>>>> Technical University of Denmark
>>>>>
>>>>>
>>>>> [image002.gif]
>>>>>
>>>>>
>>>>> Department of Physics
>>>>> Fysikvej
>>>>> Building 307
>>>>> DK-2800 Kongens Lyngby
>>>>>
>>>>> Main office at
>>>>> ESS DMSC
>>>>> COBIS, Ole Maaløes vej 3, 2200 København N, Denmark
>>>>>
>>>>> Direct +45 2125 4612
>>>>> Mobil +45 2125 4612
>>>>> Fax +45 4593 2399
>>>>> pkwi at fysik.dtu.dk<mailto:pkwi at fysik.dtu.dk <mailto:pkwi at fysik.dtu.dk <mailto:pkwi at fysik.dtu.dk>>>
>>>>>
>>>>>
>>>>> Peter Kjær Willendrup
>>>>> Forskningsingeniør, Specialkonsulent
>>>>>
>>>>> DTU Physics
>>>>> [image001.gif]
>>>>>
>>>>>
>>>>> Technical University of Denmark
>>>>>
>>>>>
>>>>> [image002.gif]
>>>>>
>>>>>
>>>>> Department of Physics
>>>>> Fysikvej
>>>>> Building 307
>>>>> DK-2800 Kongens Lyngby
>>>>>
>>>>> Main office at
>>>>> ESS DMSC
>>>>> COBIS, Ole Maaløes vej 3, 2200 København N, Denmark
>>>>>
>>>>> Direct +45 2125 4612
>>>>> Mobil +45 2125 4612
>>>>> Fax +45 4593 2399
>>>>> pkwi at fysik.dtu.dk
>>>>>
>>>> _______________________________________________
>>>> mcstas-users mailing list
>>>> mcstas-users at mcstas.org
>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman2.mcstas.org%2Fmailman%2Flistinfo%2Fmcstas-users&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v%2FzSDXQAZGU0cX2pdVG7nQgqZfCVuwdDig1alrUoZhw%3D&reserved=0 <https://mailman2.mcstas.org/mailman/listinfo/mcstas-users> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman2.mcstas.org%2Fmailman%2Flistinfo%2Fmcstas-users&data=05%7C01%7Clefmann%40nbi.ku.dk%7Cde77aece11cf4918c23008dbd471b476%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337357056579252%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v%2FzSDXQAZGU0cX2pdVG7nQgqZfCVuwdDig1alrUoZhw%3D&reserved=0 <https://mailman2.mcstas.org/mailman/listinfo/mcstas-users>>
>> <cylinder.png>_______________________________________________
>> mcstas-users mailing list
>> mcstas-users at mcstas.org
>> https://mailman2.mcstas.org/mailman/listinfo/mcstas-users
>
>
> Peter Kjær Willendrup
> Forskningsingeniør, Specialkonsulent
>
> DTU Physics
>
>
>
> Technical University of Denmark
>
>
>
>
>
> Department of Physics
> Fysikvej
> Building 307
> DK-2800 Kongens Lyngby
>
> Main office at
> ESS DMSC
> COBIS, Ole Maaløes vej 3, 2200 København N, Denmark
>
> Direct +45 2125 4612
> Mobil +45 2125 4612
> Fax +45 4593 2399
> pkwi at fysik.dtu.dk
>
More information about the mcstas-users
mailing list