***** EXP(A) EXPANSION FAILURE! *****

[rfgarciar]

Dear Gosia Users

I am trying to use GOSIA2, up to now I have had a problem using GOSIA2: when I try to use the cubic spline routine, adding the option SPL,1 in my input, I get a error in the output. There is not problem when I run the option OP,CORR or OP,MAP, but when I run the minimization with the option OP,MINI I get:

***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (2,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (3,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (4,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (5,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (6,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (7,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (8,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (9,1)
***** EXP(A) EXPANSION FAILURE! *****
EXPERIMENT 1 NEW SUBDIVISION (*,1)
***** EXP(A) EXPANSION FAILURE! *****
.
.
.
.
.

I can avoid this problem if I change SPL,1 to SPL,2. What does this number (1 or 2) mean?

I will appreciate any help you can provide me.


Best regards,
Ronald

[hayes]

Hi Ronald,

Can you attach your set of files in a "tar" archive? This error usually is related to inconsistencies such as including data for transitions that do not have a matrix element, so it would be helpful to see the inputs.

Best,
Adam

[warr]

SPL,0 selects the lagrangian interpolation method. SPL,1 selects the spline interpolation method. I suspect that SPL,X where X is neither 0 nor 1, does horrible things. Possibly functions are not being called, so it might turn off the message, but it is probably not the right solution.

This interpolation is used in OP,INTG or OP,INTI to do the interpolation over energy loss in the target. It is also used for conversion coefficients if you don't use the BRIC method. I can't see straight away why it would have any effect on minimization though.

If you let us have the input, we can see what is happening.

[rfgarciar]

Hi Adam and Warr
Thanks for your reply.
Let us see the case of 78Se on Mg, in the attachment (GOSIA2_78SeonMg.zip) are my input files.
Other thing, when I use the BRIC method for conversion coefficients, with the same input files, I get the following error:
Unable to find conversion coefficients for 4.238 MeV
STOP Missing conversion coefficients statement executed

Best Regards,
Ronald

[hayes]

Hi Ronald,

I am still not sure about the spline problem. I can look into it in a few days, and maybe Nigel Warr will have some comment.

The second problem sounds like a bug in OP,BRIC for gosia2. Maybe the conversion coefficients for one nucleus are overwriting the ones for the other nucleus? I will copy this post to the bug reports forum.

Adam

[hayes]

Hi Ronald,

Is one of your target/beam corrected yields files empty when you get this error in the fit? This usually explains the error you quoted. I think there could be a file number specification that is different between version gosia2_20080414.f and the latest gosia2 version. I haven't narrowed it down further than that.

The attached input is not for your nuclei, but it should run under gosia2_20080414.f and just give an empty target.cor and target.out file on the latest version.

You can experiment with gosia2_20080414.f if you get time and let me know if you get this to run with either/both.

Here is the download:
http://www.ikp.uni-koeln.de/~warr/gosia ... 20080414.f

Edit: This is just a test to narrow down the problem. The relativistic correction is in the wrong direction in this version.

Adam

[warr]

I also got empty files when I tried to run this test case. I don't have much time at the moment because I'm at CERN setting up Miniball, but I suggest checking OP,FILE carefully in the two input files. I don't recall us ever having changed the file numbers in gosia2, but there are differences between gosia and gosia2 because gosia2 needs to read for both the investigated and non-investigated nucleus. Perhaps they are the wrong way round somewhere and it is overwriting something?

Nigel

[warr]

Mea culpa. It seems I introduced this bug last April. Adam found it. I've put a new version on my webpage, which reverts the change which I think causes the problem. Sorry about that. It seems that while I was applying a bug fix for the relativistic correction, I accidently let something through which should have only been in my test version. The latest version has the fix for the bug in the relativistic correction with inverse kinematics but not the bug that you discovered and Adam tracked down.

http://www.ikp.uni-koeln.de/~warr/gosia ... 81208.12.f

Nigel