Dear Didier,
I'm doing some calculations about the ESS DTL. I've observed that the DTL_CEL line is somehow different respect to the GAP line, i.e.:
DTL line on TraceWin:
DTL_CEL 75.23682 25.0 24.6445 0.00999151 -59.9444 0.0 176192.0 -35.0 10.0 3.0 0.0884558 0.780607 -0.378458 -0.163516 ; Relative phase-35
Q+D+GAP+D+Q line on v87_nom_2.dat:
QUAD 25 -59.9444 10
DRIFT 12.6084 10
GAP 176192 -35 10 3 0 0.0884558 0.780607 -0.378458
DRIFT 12.9839 10
QUAD 24.6445 0 10 ; Relative phase-35
So, why there is a 0 after (may be beta_s ?) the number 3 in the gap line ? Why is missing the terms k2T'' on the gap line ?
I attach the whole project.
My Best Regards,
Michele Comunian
DTL_CEL vs GAP
Re: DTL_CEL vs GAP
Dear Michele,
There is indeed a problem, and it lies in the reading of DTL_CEL, where the code interprets "3.0", the parameter indicating the phase type, which is supposed to be an integer, as an integer:3 and a double:0, causing a shift in the reading of the following parameters.
Replacing "3.0" with "3" solves the problem, but this is frankly dangerous, especially since TraceWin puts "3.0" when it creates the new_xxxx.dat file. This is clearly a bug, which has now been fixed.
In other words, the simulations with DTL_CEL & GAP were both wrong, without this being a real problem.
The correction fixes the problem of shifted data, but you will never get a perfect match between DTL_CEL & GAP because there are small differences in the processing.
Regards,
Didier
There is indeed a problem, and it lies in the reading of DTL_CEL, where the code interprets "3.0", the parameter indicating the phase type, which is supposed to be an integer, as an integer:3 and a double:0, causing a shift in the reading of the following parameters.
Replacing "3.0" with "3" solves the problem, but this is frankly dangerous, especially since TraceWin puts "3.0" when it creates the new_xxxx.dat file. This is clearly a bug, which has now been fixed.
In other words, the simulations with DTL_CEL & GAP were both wrong, without this being a real problem.
The correction fixes the problem of shifted data, but you will never get a perfect match between DTL_CEL & GAP because there are small differences in the processing.
Regards,
Didier