From Alexandre.PinhoDosSantosSouza at inl.gov Tue Oct 3 23:32:22 2023 From: Alexandre.PinhoDosSantosSouza at inl.gov (Alexandre Pinho Dos Santos Souza) Date: Tue, 3 Oct 2023 21:32:22 +0000 Subject: [mcstas-users] Obsolete components Message-ID: Hello McStas team, My name is Alexandre Pinho, and I have been a McStas user since 2018. I'd like to say that I was able to research and make good work using McStas. It's been a very useful tool; however, I'd like to ask you about those components that became obsolete during the current versions. Mainly those that import sources from MCNP, i.e., PTRAC and RSSA files with components Virtual_mcnp_input and Virtual_mcnp_ss_input, respectively. Why are they obsolete in those new versions? In addition, I have tried to download and use version 2.5, but it's not functioning. Is part of the installation package unavailable or something? Thanks a lot for your attention! Sincerely, Alexandre Pinho dos Santos Souza, Ph.D. (he/him/his) BEA Staff | Imaging & Diffraction Alexandre.PinhoDosSantosSouza at inl.gov | O: 208-533-8884 | C: 208-607-1391 Idaho National Laboratory | 1955 Fremont Ave. | Idaho Falls, ID | 83415 ___________________________________________________________________ [cid:image001.png at 01D9F60E.CD263AB0] ___________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 169087 bytes Desc: image001.png URL: From pkwi at dtu.dk Wed Oct 4 12:06:43 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Wed, 4 Oct 2023 10:06:43 +0000 Subject: [mcstas-users] Obsolete components In-Reply-To: References: Message-ID: Dear Alexandre, On 3 Oct 2023, at 23.32, Alexandre Pinho Dos Santos Souza wrote: My name is Alexandre Pinho, and I have been a McStas user since 2018. I'd like to say that I was able to research and make good work using McStas. It's been a very useful tool; however, I'd like to ask you about those components that became obsolete during the current versions. Good to hear that, and sure I can elaborate on the reasons for obsoletion. Mainly those that import sources from MCNP, i.e., PTRAC and RSSA files with components Virtual_mcnp_input and Virtual_mcnp_ss_input, respectively. Why are they obsolete in those new versions? As you outline, a number of import mechanisms from MCNP existed in the past more precisely 1) Originally the Virtual_mcnp_input to function with PTRAC 2) Virtual_mcnp_ss_input to function via ?source surface files?, better than the PTRAC option but with the caveat of depending on Fortran snippets. 3) We finally implemented the ?successor? MCPL_input that is based on https://mctools.github.io/mcpl/, developed by Thomas Kittelmann at ESS. MCPL files can be generated from MCNP SSW files, and McStas comes bundled with the tool ssw2mcpl that can do the conversion for you. One of the main advantages of using MCPL is that you keep better track of the information flow (e.g. the original deck can be embedded and may contain info on the NPS used) and there are command-line tools to both filter on the content of an MCPL file (e.g. ?neutrons only and throw away energies above 1eV) and merge multiple MCPL files to one input for McStas. In addition, I have tried to download and use version 2.5, but it's not functioning. Is part of the installation package unavailable or something? Thanks a lot for your attention! If you need a 2.x version these days, please go for 2.7.2 - and I further recommend migrating to 3.x. Best, Peter Willendrup 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From Lukas.Vogl at frm2.tum.de Wed Oct 18 22:44:52 2023 From: Lukas.Vogl at frm2.tum.de (Lukas Vogl) Date: Wed, 18 Oct 2023 22:44:52 +0200 Subject: [mcstas-users] resonant spin echo flipper in McStas 3.4 Message-ID: <68cc547a-b9fc-4ed7-8a7a-d333345c5e01@frm2.tum.de> Hi McStas Team, At the neutron resonance spin echo instrument RESEDA (FRM II), we are working on implementing a virtual clone of the instrument, which combines our instrument control software with a McStas simulation in the background. At the heart of the instrument are radio frequency spin flippers in a longitudinal field geometry. The static field is parallel for the neutron fight path and the rotating RF-field perpendicular to it. The build-in McStas functionality for neutron spin evolution seems to work up to circular frequencies of 2pi*500 1/s. We want to perform simulations with frequencies in the MHz range. The particular problem we see, is that the spin is no longer flipped by Pi for higher frequencies, and only a partial polarisation in the opposite direction after the flipper is seen. I have attached the necessary files to reproduce this problem. pol-lib.c, pol-lib.h and Pol_Bfield.comp have to be placed in the corresponding folders (share, resp. optics) of the McStas installation version 3.4. pol-lib.* and Pol_Bfield.comp are modified to implement a rotating B-field, which is not yet present in the current McStas version. I already have tried to change the threshold condition for the time step calculation to allow smaller time steps but this did not help. Changing the length of the flipper does seem to influence the performance which should also not happen. Thus our question is, if the current McStas spin propagation code is at all capable to handle RF-fields with such frequencies and if so what we have to change in our implementation. Best Regards Lukas Vogl Working student at RESEDA - FRM II -------------- next part -------------- A non-text attachment was scrubbed... Name: pol-lib.h Type: text/x-chdr Size: 4558 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pol-lib.c Type: text/x-csrc Size: 17898 bytes Desc: not available URL: -------------- next part -------------- /************************************************************************** * * McStas, neutron ray-tracing package * Copyright 1997-2006, All rights reserved * Risoe National Laboratory, Roskilde, Denmark * Institut Laue Langevin, Grenoble, France * * Component: Pol_Bfield * * %I * Written by: Erik B Knudsen, Peter Christiansen and Peter Willendrup * Date: July 2011 * Origin: RISOE * * Magnetic field component. * * %D * * Region with a definable magnetic field. * * The component is nestable if the concentric flag is set (the default). This means that it may have a * construction like the following: * // START MAGNETIC FIELD * COMPONENT msf = * Pol_Bfield(xwidth=0.08, yheight=0.08, zdepth=0.2, Bx=0, By=-0.678332e-4, Bz=0) * AT (0, 0, 0) RELATIVE armMSF * * // OTHER COMPONENTS INSIDE THE MAGNETIC FIELD CAN BE PLACED HERE * * // STOP MAGNETIC FIELD * COMPONENT msf_stop = Pol_simpleBfield_stop(magnet_comp_stop=msf) * AT (0, 0, 0) RELATIVE armMSF * * Note that if you have objects within the magnetic field that extend outside it you may get * wrong results, because propagation within the field will then possibly extend outside, e.g. * when using a tabled field. The evaluated field will then use the nearest defined field point * _also_ outside the defintion area. If these outside-points have a non-zero field precession will * continue - even after the neutron has left the field region. * * In between the two component instances the propagation routine * PROP_DT also handles spin propagation. * The current algorithm used for spin propagation is: * SimpleNumMagnetPrecession * in pol-lib. * * Example: Pol_Bfield(xwidth=0.1, yheight=0.1, zdepth=0.2, Bx=0, By=1, Bz=0) * Pol_Bfield(xwidth=0.1, yheight=0.1, zdepth=0.2, field_type=1) * * Functions supplied by the system are (the number is the ID of the function to be given as the field_type parameter: * 1. Constant magnetic field: Constant field (Bx,By,Bz) within the region * 2. Rotating magnetic_field: Field is initially (0,By,0) but after a length of zdepth * has rotated to (By,0,0) * 3. Majorana magnetic_field: Field is initially (Bx,By,0) with By< Field volume == 0.\n",NAME_CURRENT_COMP); } if(shape == NONE) { printf("Warning (%s): Magnetic field has no geometry. Full Z=0-plane is used as boundary.\n",NAME_CURRENT_COMP); } %} TRACE %{ double t0,t1; int hit; enum shapes {NONE=0, BOX, WINDOW, CYLINDER, SPHERE, ANY}; /*enter through whatever object we are*/ switch (shape){ case BOX: hit=box_intersect(&t0,&t1,x,y,z,vx,vy,vz,xwidth,yheight,zdepth); /*terminate neutrons which miss the component*/ if(!hit) ABSORB; /*If we do hit - propagate to the start of the field unless the neutron is already there.*/ if(t0>FLT_EPSILON) { PROP_DT(t0); t1-=t0; }else if (t0<-FLT_EPSILON && concentric){ PROP_DT(t1); } break; case CYLINDER: hit=cylinder_intersect(&t0,&t1,x,y,z,vx,vy,vz,radius,yheight); /*terminate neutrons which miss the component*/ if(!hit)ABSORB; /*If we do hit - propagate to the start of the field unless the neutron is already there.*/ if(t0>FLT_EPSILON) { PROP_DT(t0); t1-=t0; }else if (t0<-FLT_EPSILON && concentric){ PROP_DT(t1); } break; case WINDOW: PROP_Z0; if (2*x>xwidth || 2*x<-xwidth || 2*y>yheight || 2*y<-yheight){ /*terminate neutrons which miss the component*/ ABSORB; } break; default: PROP_Z0; } mcmagnet_push(_particle, field_type,&(ROT_A_CURRENT_COMP),&(POS_A_CURRENT_COMP),0,Bprms); #ifdef MCDEBUG mcmagnet_print_stack(); #endif /*does the field "close/stop" itself*/ if (!concentric){ switch (shape){ case BOX: PROP_DT(t1); break; case CYLINDER: PROP_DT(t1); break; case WINDOW: PROP_Z0; /*terminate neutrons which miss the exit window*/ if (2*x>xwidth || 2*x<-xwidth || 2*y>yheight || 2*y<-yheight){ ABSORB; } break; default: PROP_Z0; } mcmagnet_pop(_particle); } %} MCDISPLAY %{ enum shapes {NONE=0, BOX, WINDOW, CYLINDER, SPHERE, ANY}; switch (shape){ case BOX: box(0,0,0,xwidth,yheight,zdepth); break; case CYLINDER: circle("xz",0, yheight/2.0,0,radius); circle("xz",0,-yheight/2.0,0,radius); line(-radius,-yheight/2.0,0,-radius,yheight/2.0,0); line( radius,-yheight/2.0,0, radius,yheight/2.0,0); line(0,-yheight/2.0,-radius,0,yheight/2.0,-radius); line(0,-yheight/2.0, radius,0,yheight/2.0, radius); break; case SPHERE: circle("xz",0,0,0,radius); circle("xy",0,0,0,radius); circle("yz",0,0,0,radius); break; case WINDOW: rectangle("xy",0,0,0,xwidth,yheight); break; } %} END -------------- next part -------------- /* vim: set filetype=c: */ DEFINE INSTRUMENT rf_flipper ( ) DECLARE %{ #define GAMMA_N 1.83247185e+08 /* rad/(Ts), value from: boost/units/systems/si/codata/neutron_constants.hpp */ double lam; double dlam; double vel; double B_rf; double B0; double freq; double coillen; double omega; %} INITIALIZE %{ coillen = 0.02; lam = 6; dlam = 0.6; freq = 450; omega = freq * 2*M_PI; B0 = omega /(GAMMA_N); vel = K2V*(2*PI/lam); B_rf =-PI * vel /(GAMMA_N*coillen); printf("coil: B_0=%g\n B_rf=%g\n freq=%g\n vel=%g\n", B0, B_rf, freq,vel); %} TRACE COMPONENT Origin = Progress_bar() AT (0,0,0) ABSOLUTE COMPONENT Source = Source_simple( yheight = 0.01, xwidth = 0.01, focus_xw = 0.01, focus_yh = 0.01, dist = 5.0, lambda0 = lam, dlambda = dlam, gauss = 0) AT (0, 0, 0) RELATIVE Origin EXTEND %{ sx = 0.; // sy = 0.; // setting the polarization to z sz = -1.; // %} COMPONENT Pol_monitor_before = PolLambda_monitor( xwidth = 0.1, yheight = 0.1, nL = 200, npol = 61, mx = 0, my=0,mz=1, restore_neutron = 1, filename = "pre.pol", Lmin = lam-dlam, Lmax = lam+dlam) AT (0, 0, 0.5) RELATIVE Origin COMPONENT stationary_bfield = Pol_Bfield( field_type=1, concentric = 1, Bx=0,By=0,Bz=B0, xwidth=0.05,yheight=0.05, zdepth=coillen) AT (0, 0, 1) RELATIVE Origin COMPONENT rf_bfield = Pol_Bfield( field_type=7, concentric = 0, Bx=B_rf,By=omega,Bz=0, xwidth=0.05,yheight=0.05, zdepth=coillen) AT (0, 0, 1) RELATIVE Origin COMPONENT stationary_bfield_end = Pol_Bfield_stop() AT (0,0,1+coillen) RELATIVE Origin COMPONENT Pol_monitor_after = PolLambda_monitor( xwidth = 0.1, yheight = 0.1, nL = 200, npol = 201, mx = 0, my=0,mz=1, restore_neutron = 1, filename = "post.pol", Lmin = lam-dlam, Lmax = lam+dlam) AT (0, 0, 2) RELATIVE Origin FINALLY %{ %} END From ryoichi.kajimoto at j-parc.jp Mon Oct 23 13:29:19 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Mon, 23 Oct 2023 20:29:19 +0900 Subject: [mcstas-users] TOFRes_sample Message-ID: 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 From pkwi at dtu.dk Mon Oct 23 20:07:09 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Mon, 23 Oct 2023 18:07:09 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: Message-ID: 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://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 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://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From pkwi at dtu.dk Mon Oct 23 20:16:31 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Mon, 23 Oct 2023 18:16:31 +0000 Subject: [mcstas-users] resonant spin echo flipper in McStas 3.4 In-Reply-To: <68cc547a-b9fc-4ed7-8a7a-d333345c5e01@frm2.tum.de> References: <68cc547a-b9fc-4ed7-8a7a-d333345c5e01@frm2.tum.de> Message-ID: Dear Lukas Vogl, Thank you for reporting this issue. With my current understanding of the precession algorithm, there shouldn?t be any explicit limitation preventing relatively high-frequency fields, but you may have run into an implicit one. As you point out, there are thresholds for ?field change? and time-resolution available which ?should? allow to circumvent such resolution issues. /*Threshold below which two magnetic fields are considered to be * in the same direction.*/ #ifndef mc_pol_angular_accuracy #define mc_pol_angular_accuracy (1.0*DEG2RAD) #endif /*The maximal timestep taken by neutrons in a const field*/ #ifndef mc_pol_initial_timestep #define mc_pol_initial_timestep 1e-5; #endif I will looking further into the details within the next coming weeks - and potentially contact you off-list for more detailed discussions. Best, Peter Willendrup On 18 Oct 2023, at 22.44, Lukas Vogl wrote: Hi McStas Team, At the neutron resonance spin echo instrument RESEDA (FRM II), we are working on implementing a virtual clone of the instrument, which combines our instrument control software with a McStas simulation in the background. At the heart of the instrument are radio frequency spin flippers in a longitudinal field geometry. The static field is parallel for the neutron fight path and the rotating RF-field perpendicular to it. The build-in McStas functionality for neutron spin evolution seems to work up to circular frequencies of 2pi*500 1/s. We want to perform simulations with frequencies in the MHz range. The particular problem we see, is that the spin is no longer flipped by Pi for higher frequencies, and only a partial polarisation in the opposite direction after the flipper is seen. I have attached the necessary files to reproduce this problem. pol-lib.c, pol-lib.h and Pol_Bfield.comp have to be placed in the corresponding folders (share, resp. optics) of the McStas installation version 3.4. pol-lib.* and Pol_Bfield.comp are modified to implement a rotating B-field, which is not yet present in the current McStas version. I already have tried to change the threshold condition for the time step calculation to allow smaller time steps but this did not help. Changing the length of the flipper does seem to influence the performance which should also not happen. Thus our question is, if the current McStas spin propagation code is at all capable to handle RF-fields with such frequencies and if so what we have to change in our implementation. Best Regards Lukas Vogl Working student at RESEDA - FRM II _______________________________________________ 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 [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From ryoichi.kajimoto at j-parc.jp Tue Oct 24 07:20:35 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Tue, 24 Oct 2023 14:20:35 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: Message-ID: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> 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://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 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://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 > From pkwi at dtu.dk Tue Oct 24 09:12:50 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Tue, 24 Oct 2023 07:12:50 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> Message-ID: <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> 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 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://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 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://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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From ryoichi.kajimoto at j-parc.jp Tue Oct 24 09:40:56 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Tue, 24 Oct 2023 16:40:56 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> Message-ID: 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 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://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 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://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 > > > 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 > From pkwi at dtu.dk Tue Oct 24 09:43:42 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Tue, 24 Oct 2023 07:43:42 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> Message-ID: Hello again, That indeed does not seem right. I will look into the details while working on the other part of the issue. Best, Peter On 24 Oct 2023, at 09.40, Ryoichi Kajimoto wrote: 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 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://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 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://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 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From lefmann at nbi.ku.dk Tue Oct 24 10:34:12 2023 From: lefmann at nbi.ku.dk (Kim Lefmann) Date: Tue, 24 Oct 2023 08:34:12 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk>, Message-ID: <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> 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 on behalf of Ryoichi Kajimoto 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 ] 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 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://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 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://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 > > > 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://mailman2.mcstas.org/mailman/listinfo/mcstas-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryoichi.kajimoto at j-parc.jp Tue Oct 24 11:14:59 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Tue, 24 Oct 2023 18:14:59 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> Message-ID: 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 on behalf of Ryoichi Kajimoto > *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 ] > > 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 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%7Cb52ac353b82e4c14d09308dbd465222d%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337303059366922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WbUFhkUT%2FTKid1%2FBSD%2B1UlpfjrvKW%2B1dkcO3Z0AW%2B%2BU%3D&reserved=0 and will implement the needed changes as soon as time allows. >> >> >> Best, >> Peter Willendrup >> >> On 23 Oct 2023, at 13.29, Ryoichi Kajimoto 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%7Cb52ac353b82e4c14d09308dbd465222d%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337303059366922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wyieFsw%2BwoETaKCZ17Xe6WHmryFeJ2fAil4%2F%2B5IlnNg%3D&reserved=0 >> >> >> 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> >> >> >> 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%7Cb52ac353b82e4c14d09308dbd465222d%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C638337303059366922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wyieFsw%2BwoETaKCZ17Xe6WHmryFeJ2fAil4%2F%2B5IlnNg%3D&reserved=0 From lefmann at nbi.ku.dk Tue Oct 24 11:58:23 2023 From: lefmann at nbi.ku.dk (Kim Lefmann) Date: Tue, 24 Oct 2023 09:58:23 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk>, Message-ID: 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 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 ] 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 on behalf of Ryoichi Kajimoto > *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 ] > > 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 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://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 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://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> >> >> >> 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://mailman2.mcstas.org/mailman/listinfo/mcstas-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.dalgliesh at stfc.ac.uk Tue Oct 24 15:43:42 2023 From: robert.dalgliesh at stfc.ac.uk (Robert Dalgliesh - STFC UKRI) Date: Tue, 24 Oct 2023 13:43:42 +0000 Subject: [mcstas-users] Mcstas on WSL 2 Message-ID: Hi Peter, I?ve just been trying mcstas 3.4 on windows 10 using the WSL and found some things that could do with being updated in the documentation. I found that if you make sure that you are running wsl 2 instead of wsl 1 you can run the x-windows apps ?natively?. i.e. you don?t need to run Xming which is, to be honest, pretty awful. I found that x-windows disappear when the machine switches of screens etc. The steps I used were. Enable these 2 windows features from control panel Virtual Machine Platform (this may require VM activity to be enabled in the BIOS) Windows subsystem for linux Open an administrator level command prompt/power shell Force the update to wsl 2 by default wsl --set-default-version 2 Install Ubuntu from the windows store. If you have already installed a distro. Update to wsl 2 using something like wsl --set-version Ubuntu-22.04 2 Fire up an Ubuntu terminal, install mcstas as described and run mcgui. All the best Rob ======================================= Dr. Robert Dalgliesh Small Angle Scattering Group Leader ISIS Neutron and Muon Source Science and Technology Facilities Council Building R3 1.29, Rutherford Appleton Laboratory??, ?Harwell Campus, Didcot ?Oxfordshire, OX11 0QX. UK Tel: +44(0)1235-445687 Email: Robert.dalgliesh at stfc.ac.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwillendrup at gmail.com Tue Oct 24 17:03:09 2023 From: pwillendrup at gmail.com (Peter Willendrup) Date: Tue, 24 Oct 2023 17:03:09 +0200 Subject: [mcstas-users] Mcstas on WSL 2 In-Reply-To: References: Message-ID: <85E201C0-0A5A-4868-8EA8-A4B0956352BC@gmail.com> Hi Rob, You are absolutely right in pointing out that the WSL hints are not up to date. I also agree that running the built-in WSL X server is much better! :-) Thanks for reporting the hints to mcstas-users! (And lovely to still have a day with a bit of mailinglist traffic ~ 25 years after McStas 1.0 was released. :-) ) Cheers Peter > On 24 Oct 2023, at 15.43, Robert Dalgliesh - STFC UKRI wrote: > > Hi Peter, > I?ve just been trying mcstas 3.4 on windows 10 using the WSL and found some things that could do with being updated in the documentation. > > I found that if you make sure that you are running wsl 2 instead of wsl 1 you can run the x-windows apps ?natively?. > i.e. you don?t need to run Xming which is, to be honest, pretty awful. I found that x-windows disappear when the machine switches of screens etc. > > The steps I used were. > Enable these 2 windows features from control panel > Virtual Machine Platform (this may require VM activity to be enabled in the BIOS) > Windows subsystem for linux > > Open an administrator level command prompt/power shell > Force the update to wsl 2 by default > wsl --set-default-version 2 > > Install Ubuntu from the windows store. > If you have already installed a distro. Update to wsl 2 using something like > wsl --set-version Ubuntu-22.04 2 > > Fire up an Ubuntu terminal, install mcstas as described and run mcgui. > > All the best > > Rob > > ======================================= > Dr. Robert Dalgliesh > Small Angle Scattering Group Leader > ISIS Neutron and Muon Source > Science and Technology Facilities Council > Building R3 1.29, > Rutherford Appleton Laboratory??, > ?Harwell Campus, > Didcot > ?Oxfordshire, > OX11 0QX. > UK > Tel: +44(0)1235-445687 > Email: Robert.dalgliesh at stfc.ac.uk > > _______________________________________________ > mcstas-users mailing list > mcstas-users at mcstas.org > https://mailman2.mcstas.org/mailman/listinfo/mcstas-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryoichi.kajimoto at j-parc.jp Wed Oct 25 08:04:03 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Wed, 25 Oct 2023 15:04:03 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> Message-ID: <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> 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 > *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 ] > > 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 on behalf of Ryoichi Kajimoto >> *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 > ] >> >> 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 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 > and will implement the needed > changes as soon as time allows. >>> >>> >>> Best, >>> Peter Willendrup >>> >>> On 23 Oct 2023, at 13.29, Ryoichi Kajimoto 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 > >>> >>> >>> 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>> >>> >>> >>> 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 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: cylinder.png Type: image/png Size: 37347 bytes Desc: not available URL: From pkwi at dtu.dk Wed Oct 25 15:28:00 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Wed, 25 Oct 2023 13:28:00 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> Message-ID: 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 Best, Peter On 25 Oct 2023, at 08.04, Ryoichi Kajimoto 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 *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 ] 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 on behalf of Ryoichi Kajimoto *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 > ] 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 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 > and will implement the needed changes as soon as time allows. Best, Peter Willendrup On 23 Oct 2023, at 13.29, Ryoichi Kajimoto 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 > 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>> 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 > _______________________________________________ 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 [cid:1ada288c-ac1f-43be-9068-dc263f5154c3 at EURP192.PROD.OUTLOOK.COM] Technical University of Denmark [cid:9280f90f-d200-482b-975d-5d2eaf161eb4 at EURP192.PROD.OUTLOOK.COM] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Test_TOFRes_sample.instr Type: application/octet-stream Size: 2840 bytes Desc: Test_TOFRes_sample.instr URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TOFRes_monitor.comp Type: application/octet-stream Size: 12452 bytes Desc: TOFRes_monitor.comp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TOFRes_sample.comp Type: application/octet-stream Size: 11832 bytes Desc: TOFRes_sample.comp URL: From ryoichi.kajimoto at j-parc.jp Thu Oct 26 12:16:05 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Thu, 26 Oct 2023 19:16:05 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> Message-ID: <040bce6a-8e00-4f56-8177-c9dd7b377b52@j-parc.jp> 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 > > > Best, > Peter > > >> On 25 Oct 2023, at 08.04, Ryoichi Kajimoto 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 >>> *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 ] >>> 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 on behalf of Ryoichi Kajimoto >>>> *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 > ] >>>> >>>> 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 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 >>>> > and will implement the needed >>> changes as soon as time allows. >>>>> >>>>> >>>>> Best, >>>>> Peter Willendrup >>>>> >>>>> On 23 Oct 2023, at 13.29, Ryoichi Kajimoto 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 > >>>>> >>>>> >>>>> 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>> >>>>> >>>>> >>>>> 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 > >> _______________________________________________ >> 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 > From pkwi at dtu.dk Fri Oct 27 10:05:29 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Fri, 27 Oct 2023 08:05:29 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <040bce6a-8e00-4f56-8177-c9dd7b377b52@j-parc.jp> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> <040bce6a-8e00-4f56-8177-c9dd7b377b52@j-parc.jp> Message-ID: <6B89E3C8-296C-4912-9455-527BCCCD62E5@dtu.dk> Dear Ryoichi, Having now investigated further, I can confirm your findings. This part of the issue seems to be more of a structural nature - and is on the ?receiving end?, i.e. in (TOF)Res_monitor.comp. I know what needs doing and may be able to send a corrected component your way later today. Best and thank you, Peter On 26 Oct 2023, at 12.16, Ryoichi Kajimoto wrote: 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 Best, Peter On 25 Oct 2023, at 08.04, Ryoichi Kajimoto > 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 > *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 ] 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 > on behalf of Ryoichi Kajimoto > *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 > ] 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 > 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 > and will implement the needed changes as soon as time allows. Best, Peter Willendrup On 23 Oct 2023, at 13.29, Ryoichi Kajimoto > 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 > 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>> 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 > _______________________________________________ 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 _______________________________________________ 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 [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From pkwi at dtu.dk Fri Oct 27 10:28:40 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Fri, 27 Oct 2023 08:28:40 +0000 Subject: [mcstas-users] TOFRes_sample In-Reply-To: <6B89E3C8-296C-4912-9455-527BCCCD62E5@dtu.dk> References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> <040bce6a-8e00-4f56-8177-c9dd7b377b52@j-parc.jp> <6B89E3C8-296C-4912-9455-527BCCCD62E5@dtu.dk> Message-ID: Hello again, It turns out that this original line in the Res_monitor (taking the fraction pf / pi) was lost during structural conversion between the McStas 2.x and 3.x format. Vars.ct = p/s->pi; This has now been fixed in the attached. I attach both Res_monitor and TOFRes_monitor as both of these components in McStas 3.x have the issue. Best and thank you again for reporting the issue. Peter On 27 Oct 2023, at 10.05, Peter Willendrup wrote: Dear Ryoichi, Having now investigated further, I can confirm your findings. This part of the issue seems to be more of a structural nature - and is on the ?receiving end?, i.e. in (TOF)Res_monitor.comp. I know what needs doing and may be able to send a corrected component your way later today. Best and thank you, Peter On 26 Oct 2023, at 12.16, Ryoichi Kajimoto wrote: 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 Best, Peter On 25 Oct 2023, at 08.04, Ryoichi Kajimoto > 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 > *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 ] 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 > on behalf of Ryoichi Kajimoto > *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 > ] 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 > 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 > and will implement the needed changes as soon as time allows. Best, Peter Willendrup On 23 Oct 2023, at 13.29, Ryoichi Kajimoto > 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 > 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>> 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 > _______________________________________________ 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 _______________________________________________ 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 Peter Kj?r Willendrup Forskningsingeni?r, Specialkonsulent DTU Physics [cid:c127f7f0-c367-49e3-91da-26dd079f978a at EURP192.PROD.OUTLOOK.COM] Technical University of Denmark [cid:b96717ea-59e5-4c3a-b6e3-a1ae4cb2c79d at EURP192.PROD.OUTLOOK.COM] 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Res_monitor.comp Type: application/octet-stream Size: 12409 bytes Desc: Res_monitor.comp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TOFRes_monitor.comp Type: application/octet-stream Size: 12477 bytes Desc: TOFRes_monitor.comp URL: From ryoichi.kajimoto at j-parc.jp Fri Oct 27 12:58:14 2023 From: ryoichi.kajimoto at j-parc.jp (Ryoichi Kajimoto) Date: Fri, 27 Oct 2023 19:58:14 +0900 Subject: [mcstas-users] TOFRes_sample In-Reply-To: References: <5b5aec6e-5fc1-47fd-9349-e1b1341622ff@j-parc.jp> <26A5C791-68C8-4701-8D53-D5AF5C62D2F0@dtu.dk> <12e5ab051fe74b808d1665122b101001@nbi.ku.dk> <9c1e412e-f3bc-40f7-a380-215ad42bcc3d@j-parc.jp> <040bce6a-8e00-4f56-8177-c9dd7b377b52@j-parc.jp> <6B89E3C8-296C-4912-9455-527BCCCD62E5@dtu.dk> Message-ID: <6907436d-fbfa-4782-ad6c-c79ffeab2d77@j-parc.jp> Dear Peter, I used the modified comp files and got a reasonable result. Thank you again! Best regards, Ryoichi Peter Kj?r Willendrup wrote on 2023/10/27 17:28: > Hello again, > > > It turns out that this original line in the Res_monitor (taking the fraction pf / pi) was lost during structural conversion between the McStas 2.x and 3.x format. > > Vars.ct = p/s->pi; > > This has now been fixed in the attached. I attach both Res_monitor and TOFRes_monitor as both of these components in McStas 3.x have the issue. > > > Best and thank you again for reporting the issue. > > Peter > > > > On 27 Oct 2023, at 10.05, Peter Willendrup wrote: > > Dear Ryoichi, > > > Having now investigated further, I can confirm your findings. This part of the issue seems to be more of a structural nature - and is on the ?receiving end?, i.e. in (TOF)Res_monitor.comp. > > I know what needs doing and may be able to send a corrected component your way later today. > > Best and thank you, > > Peter > > > > On 26 Oct 2023, at 12.16, Ryoichi Kajimoto wrote: > > 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 > > > Best, > Peter > > > On 25 Oct 2023, at 08.04, Ryoichi Kajimoto > 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 > > *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 ] > 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 > on behalf of Ryoichi Kajimoto > > *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 > ] > > 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 > 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 > > and will implement the needed > changes as soon as time allows. > > > Best, > Peter Willendrup > > On 23 Oct 2023, at 13.29, Ryoichi Kajimoto > 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 > > > > 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>> > > > 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 > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > > Peter Kj?r Willendrup > Forskningsingeni?r, Specialkonsulent > > DTU Physics > [cid:c127f7f0-c367-49e3-91da-26dd079f978a at EURP192.PROD.OUTLOOK.COM] > > > > Technical University of Denmark > > > [cid:b96717ea-59e5-4c3a-b6e3-a1ae4cb2c79d at EURP192.PROD.OUTLOOK.COM] > > > > 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 > From aalqais2 at asu.edu Sun Nov 5 21:52:02 2023 From: aalqais2 at asu.edu (Ahmad Alqaisi) Date: Sun, 5 Nov 2023 15:52:02 -0500 Subject: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas Message-ID: Dear McStas team, I'm new to McStas simulations. I would like to ask about the complex part of the optical potential of Neutrons U=V-i*W* Is it included in the reflectivity calculations for Neutron Guides? If not, is there a way to add it to McStas? Can the complex part be added as an additional formula to McStas? for example by adding a formula like the one attached to this email If you can provide me with a guidance on the script lines that would achieve such a goal, that would be great Best, Ahmad Alqaisi, Student Researcher at Indiana University Bloomington, US -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2023-11-05 153856.png Type: image/png Size: 15441 bytes Desc: not available URL: From lefmann at nbi.ku.dk Sun Nov 5 22:38:01 2023 From: lefmann at nbi.ku.dk (Kim Lefmann) Date: Sun, 5 Nov 2023 21:38:01 +0000 Subject: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas In-Reply-To: References: Message-ID: <881921d9799f4a3190f2eeb83a9f83da@nbi.ku.dk> Dear Ahmad, The short reply is: no, this is not included. Neutron guide reflectivities are calculated from fitted experimental data, not from reflectivity equations. To implement this, you would need to come up with the full reflectivity curve, R(q), for a given surface. One of the former reflectivity samples could take as input exactly a file of this sort and use it for the purpose, but I think this is no longer a part of the distribution. There is also the Multilayer_Sample, which is a contributed component by Robert Dalgliesh. You could look into that and/or contact Robert. This is likely the closest we get to something that fit your needs. best, Kim ________________________________ From: mcstas-users on behalf of Ahmad Alqaisi Sent: Sunday, November 5, 2023 9:52:02 PM To: mcstas-users at mcstas.org Cc: Snow, William Michael Subject: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas You don't often get email from aalqais2 at asu.edu. Learn why this is important Dear McStas team, I'm new to McStas simulations. I would like to ask about the complex part of the optical potential of Neutrons U=V-iW Is it included in the reflectivity calculations for Neutron Guides? If not, is there a way to add it to McStas? Can the complex part be added as an additional formula to McStas? for example by adding a formula like the one attached to this email If you can provide me with a guidance on the script lines that would achieve such a goal, that would be great Best, Ahmad Alqaisi, Student Researcher at Indiana University Bloomington, US -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.dalgliesh at stfc.ac.uk Mon Nov 6 15:50:21 2023 From: robert.dalgliesh at stfc.ac.uk (Robert Dalgliesh - STFC UKRI) Date: Mon, 6 Nov 2023 14:50:21 +0000 Subject: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas In-Reply-To: <881921d9799f4a3190f2eeb83a9f83da@nbi.ku.dk> References: <881921d9799f4a3190f2eeb83a9f83da@nbi.ku.dk> Message-ID: Hi Both, The model in the multi-layer sample is a very simple one and doesn't include the complex part. I wrote the component for simple sample consisting of 1 or 2 layers of material. Everything was done for speed so as to not introduce a really complicated calculation into the simulation. I guess that this could be pre-calculated and then interpolation used to be more efficient having read the simulated data from a file. It would be easy enough for someone to write a new version of the multi-layer to use the more complicated expressions using a similar setup to the one I wrote as the routine calls the gsl to do the complex maths. It just needs somebody to take a day or two to work it out. The biggest problem you will find will be how to input the parameters required to set up the simulation of the model but I guess you could make use of a setup file somewhere to do this in a similar way to the files used for the crystallographic samples. Rob From: mcstas-users On Behalf Of Kim Lefmann Sent: Sunday, November 5, 2023 9:38 PM To: Ahmad Alqaisi ; mcstas-users at mcstas.org Cc: Snow, William Michael Subject: Re: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas Dear Ahmad, The short reply is: no, this is not included. Neutron guide reflectivities are calculated from fitted experimental data, not from reflectivity equations. To implement this, you would need to come up with the full reflectivity curve, R(q), for a given surface. One of the former reflectivity samples could take as input exactly a file of this sort and use it for the purpose, but I think this is no longer a part of the distribution. There is also the Multilayer_Sample, which is a contributed component by Robert Dalgliesh. You could look into that and/or contact Robert. This is likely the closest we get to something that fit your needs. best, Kim ________________________________ From: mcstas-users > on behalf of Ahmad Alqaisi > Sent: Sunday, November 5, 2023 9:52:02 PM To: mcstas-users at mcstas.org Cc: Snow, William Michael Subject: [mcstas-users] Including the complex part of the optical potential of Neutron in McStas You don't often get email from aalqais2 at asu.edu. Learn why this is important Dear McStas team, I'm new to McStas simulations. I would like to ask about the complex part of the optical potential of Neutrons U=V-iW Is it included in the reflectivity calculations for Neutron Guides? If not, is there a way to add it to McStas? Can the complex part be added as an additional formula to McStas? for example by adding a formula like the one attached to this email If you can provide me with a guidance on the script lines that would achieve such a goal, that would be great Best, Ahmad Alqaisi, Student Researcher at Indiana University Bloomington, US -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkwi at dtu.dk Tue Nov 21 10:32:49 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Tue, 21 Nov 2023 09:32:49 +0000 Subject: [mcstas-users] McStas marked 25 year anniversary on November 16th Message-ID: <98A6DBF9-B2B4-4425-B367-080EBAA668B5@dtu.dk> Dear all, The 25th-anniversary celebration of the McStas collaboration took place on the afternoon of November 16th, co-hosted by ESS DMSC and DTU Physics. Commencing its journey at Ris? National Laboratory in the spring of 1997, the McStas software commemorated its 25th year since the release of version 1.0 in October 1998. Over the years, the project expanded into an international collaboration, with notable contributions from institutions such as Institut Laue-Langevin (ILL) and The Paul Scherrer Institute (PSI). In 2007, Ris? became part of DTU, and since 2012, the ongoing development of McStas found a new home at DTU Physics, actively collaborating with the Niels Bohr Institute, ILL, PSI, and ESS. As an open-source software, McStas has benefited from widespread contributions by individual researchers from facilities and universities globally, enriching the codebase with new features and functionality. McStas has evolved into the leading software globally for neutron scattering simulations, particularly in the realms of instrument design, optimization, and virtual experiments. Notably, the software played a crucial role in designing and optimizing most of the ESS instruments currently under construction in Lund, Sweden. During the anniversary event, Peter Willendrup, the lead developer and technical-scientific support for the McStas user community since 2002, provided a comprehensive overview of the 25-year development journey, highlighting key contributions from various contributors. Peter is Senior Research Engineer at DTU Physics and ESS DMSC. Mads Bertelsen, the author of McStasScript, guide_bot, and Union presented his work on these significant developments. Mads is recently appointed to a permanent position as Scientist at ESS DMSC. Several event participants delivered short speeches in honor of the McStas collaboration, including Kurt Clausen, originator of the "simulation framework" idea and grant holder of the first EU funding for McStas, Kim Lefmann founder and member of the McStas team since the start , Kristian Nielsen, the computer scientist who engineered the initial code-generator technology, and Thomas Holm Rod, head of the ESS DMSC. Another important guest was Emmanuel Farhi from Synchrotron SOLEIL, long time contributor to McStas and now the lead on McXtrace. Please follow the link to https://mcstas.org for links to the presentations and pictures from the event! On behalf of the McStas team Peter Willendrup Ps.: Thanks to the colleagues at ORNL who sent us a nice birthday card! :-) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: From pkwi at dtu.dk Wed Nov 29 18:02:25 2023 From: pkwi at dtu.dk (=?utf-8?B?UGV0ZXIgS2rDpnIgV2lsbGVuZHJ1cA==?=) Date: Wed, 29 Nov 2023 17:02:25 +0000 Subject: [mcstas-users] (Experimental) McStas packages have hit conda-forge Message-ID: <04BD1406-ED34-44F7-9083-77AC676E2130@dtu.dk> Dear all, Thanks to help from Thomas Kittelmann (ESS DMSC), McStas is now available on conda-forge! (See https://github.com/conda-forge/mcstas-suite-feedstock/tree/main ) Initially we support only support Unix platforms Linux and macOS Intel, but macOS Silicon should come shortly. The version tag of the packages is "3.4.7" meaning functionality-wise like McStas 3.4 but with minor improvements. For next official McStas release everything should match between our classical binary-distributed platforms and conda-forge. Should you experience problems, please write up a GitHub Issue at https://github.com/McStasMcXtrace/McCode/issues In preparation for forthcoming McStas 3.5 we are very much open to contributions: Hence, if you have nice new component developments or new instrument files to contribute, please fork the our repo and open a pull request adding the files at https://github.com/McStasMcXtrace/McCode/pulls Regards on behalf of the McStas team, 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 dtu.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 58 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1055 bytes Desc: image002.gif URL: