Gosia2 brute force error estimation

[hayes]

Thanks, Liam and Christopher.

I will work on changing this as soon as I can in Rachel. It shouldn't take long. Liam, if you're held up at all, I can make a quick patch for you, since it's very unlikely to create a new bug in this case.

It's very strange that I don't see this error myself, since you both see it in different calculations, but I'm sure you're correct.

Thanks again for finding the cause and letting me know!

Adam

[C.Bauer]

Maybe first a comment about the error:
I couldn't avoid it even with varying the mean angles! Everytime I try to put OP,MAP before OP,MINI it gives that error, so I do the 3 steps, no problem so far.

About the target detection problem, it's getting tricky. The kinematics is A=140 on A=48 with Q=0.774MeV (2+ excitation of Nd), target particles are detected between 27.82 and 51.77 degrees. Unfortunately I am not sure how to include figures, but looking at the kinematics it's clear that this covers both solutions for the scattered projectiles! I can separate them via the rings (theta) of the CD, of course. But now, when defining experiments with the projectile angle (to be able to proper normalize them to each other) I will get experiments covering the same angles, but different CM angles, so different Coulex behind it!

I think the solution is to go back from OP,INTI to OP,INTG and select the correct kinematics with the IKIN=0,1 flag for each experiment. OP,INTI was nice so far, just defining the detected target, but then I have the normalization limitation!

Right now I am quite confused about this procedure but I hope it will work. If somebody sees a problem, please let me know.

[hayes]

Maybe first a comment about the error:
I couldn't avoid it even with varying the mean angles! Everytime I try to put OP,MAP before OP,MINI it gives that error, so I do the 3 steps, no problem so far.

I wonder if this is somehow platform-dependent, but I can't imagine why it would be. Since it never happens on my machine--so strange--I didn't realize that it's urgent to fix it in Rachel. Thanks again!

EDIT: Now I think I know what's going on. This must have to do with the order of operations in Gosia2. I'm not sure why you're getting this particular error, but this would explain why I almost never get it with Gosia 1.

About the target detection problem, it's getting tricky. The kinematics is A=140 on A=48 with Q=0.774MeV (2+ excitation of Nd), target particles are detected between 27.82 and 51.77 degrees. Unfortunately I am not sure how to include figures, but looking at the kinematics it's clear that this covers both solutions for the scattered projectiles! I can separate them via the rings (theta) of the CD, of course. But now, when defining experiments with the projectile angle (to be able to proper normalize them to each other) I will get experiments covering the same angles, but different CM angles, so different Coulex behind it!

Is this a problem? Selecting the IKIN flag is meant to select the proper CM angles. If you have enough counts to make the experiment into two, one for each solution, then you have a standard Gosia calculation.

In all of this, converting from projectile to target scattering angles can raise accuracy questions because of the Q-value and energy loss through the target, since usually both particles aren't detected in this type of experiment.

I think the solution is to go back from OP,INTI to OP,INTG and select the correct kinematics with the IKIN=0,1 flag for each experiment. OP,INTI was nice so far, just defining the detected target, but then I have the normalization limitation!

Will changing to OP,INTG help in the way you want it to?

You can use projectile detection in the same way with OP,INTI and select either kinematic solution--the only difference is when using the target-detection choice.

If I understand you, it sounds like you'd have to sum the two solutions, which can't be done automatically (hence the necessity of OP,INTI.)

One tactic that was discussed at the Gosia Workshop in Warsaw is to integrate once for each solution and then sum the two, but we later decided that this is tedious and presents other troubles with the contribution to the Coulex near the maximum scattering angle being too important to ignore in that particular case. Now that we have OP,INTI, I suppose that you could integrate over the target-detection range to create the corrected-yields file by hand and then run the fit, which uses a point calculation, with projectile detection specified, so that you can normalize experiments.

Right now I am quite confused about this procedure but I hope it will work. If somebody sees a problem, please let me know.

If what I said doesn't make sense, then please let me know your questions about procedure.

Best,
Adam

[C.Bauer]

Thanks Adam, it makes perfectly sense fore me, it was late yesterday... so of course, I still can use OP,INTI and select the the right CoM angle regime when defining projectile angles. I don't need to sum up 2 solutions as I have them separated by the target angle. I was just using OP,INTI with target detection so far, that's why I mixed it up and thought to use OP,INTG.

It might be a good idea also to compare the integrated yields when defining the target angles and when doing the projectile angle business, then I can see if I get accuray problems! I will report on that later...

[hayes]

Thanks Adam, it makes perfectly sense fore me, it was late yesterday...

I know the feeling.

so of course, I still can use OP,INTI and select the the right CoM angle regime when defining projectile angles. I don't need to sum up 2 solutions as I have them separated by the target angle.

It sounds like you have enough data from each solution, which makes things much easier.

I was just using OP,INTI with target detection so far, that's why I mixed it up and thought to use OP,INTG.
It might be a good idea also to compare the integrated yields when defining the target angles and when doing the projectile angle business, then I can see if I get accuray problems! I will report on that later...

I think that this is a very smart check that you aren't missing an important part of the cross section, since you will have to trim the scattering angle range a little around the maximum scattering angle. Check Nigel's description of this problem in the Gosia manual section on kinematics, if it is unclear.

Best,
Adam

[warr]

I suspect a lot of the problems are due to the way OP,INTI was tacked on by me a few of years ago rather than being properly integrated into Gosia, which would have required a major rewrite. This was needed because with OP,INTG, if you go over the angle where IKIN changes, when you integrate, you have a problem because this flipping angle is energy dependent and this occurs within the integration over energy loss in the target. This means you have to integrate in two parts and add them up, but you can't go right up to this critical angle in either case. You have to leave a gap. This is why I wrote OP,INTI, which automatically calculates IKIN for each angle and energy meshpoint. Note that this means that whereas for OP,INTG, the user must set IKIN explicitly, for OP,INTI, it is the code that does this, though IKIN may still be used by other options. For more details on the justification behind OP,INTI see:

http://www.ikp.uni-koeln.de/~warr/gosia ... matics.pdf

Now, there are two known issues with OP,INTI.

1) OP,INTI has to transform between target recoil and projectile angles, calculate IKIN and then use a copy of the OP,INTG code. There are, however, two solutions and OP,INTI picks one of them. The other solution is the one with VERY low energy particles emitted in the direction of the particle detector. For most applications, I think they are low enough that they won't get out of the target, through the dead layer of the particle detector and be detected, especially given the rather high thresholds we have for Miniball. So this is something for people doing unusual things to worry about, but shouldn't be a problem for you.

2) If you hit an angle for a meshpoint very close to the critical angle, where IKIN flips, numerical errors might result in problems. The code has to calculate first in one direction and then the other. The functions are not trivial to invert, so there will be some inaccuracy in the transformation. This is too small to make a difference for the result, but it can cause the error you saw to occur. This happens because the calculated value when inverting the calculation ends up on the other side of the IKIN divide to the original value. The workaround is to shift the meshpoint a little. It shouldn't need too much.

I am not aware of anything happening due to using OP,MAP in conjunction with OP,INTI. You should just set IKIN appropriately for the mean angle and make sure this mean angle avoids the critical point where IKIN flips. "Avoid" in this context shouldn't mean a big change. I seem to recall a change of about 0.1 degrees was enough. Of course, it could always be a new problem, that I am not aware of.

Note, that there was a bug in OP,INTI that it changed IKIN and left it in whatever state it happened to finish in. This was fixed three years ago in gosia_20081208.3 and gosia2_20081208.4 so I assume you don't have such an old version.

[LPGaffney]

Hi again,

To be more clear, I see this error all of the time when using OP,MAP and OP,MINI at the same time. Changing meshpoints DOES NOT solve the situation. If I run OP,MAP and OP,MINI in two separate gosia commands, there is no error, regardless of the number and values of the meshpoints (that I have tried so far)...

Also, OP,MAP takes quite a considerable time for me and so it is easier to run it separately, especially when one wants to run OP,MINI many times using OP,REST in between iterations.

Cheers,
Liam

P.S. Adam: I am using standard gosia at the moment as I can change things more easily to suit my needs (I think this is just because I am so used to working on my data set and have many "saved commands"). However, I do use rachel to build OP,INTI and to automatically calculate the stopping powers with SRIM... This is a very useful addition!!

[hayes]

Well, I'm stumped then about the exact cause, but I will stop doing MAP and MINI at the same time. (Maybe a race condition in the operating system? I get it when you don't, you get it when I don't--very strange.)

Thanks for the feedback about the stopping power server. You're using the server for the best accuracy, right? The built-in Elast has some problems. If you have any other feedback, it would help!

Adam

[C.Bauer]

Hi everybody, I got back to the analysis now and can report that what we discussed about the accuracy around the flipping at the maximum angle is indeed a problem. But I want to use projectile angles to be able to normalize the experiments to each other (limitation of Gosia when target recoils are detected) so I define the experiments such, that I throw out the angles around that point and define 1 experiment before and 2 after the maximum scattering angle, that looks fine.

Now, Rutherford cross-section and integrated yields look rather the same no matter which angles I define. But then, I had another surprise: The corrected yields are different! Shouldn't they be similar at least? The corrected yields refer to the point yields, so I checked it with the simple command:

Code: Select all

OP,POIN
0,0
OP,EXIT


There is a huge difference in the point yields between projectile and target detection, is this correct? Here are also the 2 EXPT inputs, where the input files differ:

Target detection:

Code: Select all

EXPT
3,60,140
-22,48,360.,-19.61,3,1,0,0,360,0,1
-22,48,360.,-19.33,3,1,0,0,360,1,1
-22,48,360.,-17.86,3,1,0,0,360,1,1


Projectile detection:

Code: Select all

EXPT
3,60,140
-22,48,360.,19.61,3,1,0,0,360,0,1
-22,48,360.,19.33,3,1,0,0,360,1,1
-22,48,360.,17.86,3,1,0,0,360,1,1


I am a little confused about these differences, don't know which calculations one can trust so.

[hayes]

Hi Liam and/or Christopher,

About the OP,MAP-OP,MINI error, running them in the same Gosia input--

To be more clear, I see this error all of the time when using OP,MAP and OP,MINI at the same time. Changing meshpoints DOES NOT solve the situation. If I run OP,MAP and OP,MINI in two separate gosia commands, there is no error, regardless of the number and values of the meshpoints (that I have tried so far)...

I am just about to finally fix this in the "GUI." Maybe you said it before, but does this error happen in Gosia 1 also?

Also, OP,MAP takes quite a considerable time for me and so it is easier to run it separately, especially when one wants to run OP,MINI many times using OP,REST in between iterations.

That seems really unusual. I'm a tiny bit suspicious that something is wrong, because OP,MAP usually takes a fraction of a second for me, even with many matrix elements. Maybe your case is just different and more complicated for Gosia.

I guess everything is ok if you find a real minimum.

Adam