New Arrival display

V1.1.6.4k64 Fixes & changes Name：K. Oide Date：2019/03/06(Wed) 22:35:14 No.939

Fixes:

1. Tracking with RAD was not properly handled at the end of QUAD and MULT to bring slightly larger energy loss, since "kinematical evaluation" was introduced.

Changes:

1. Calculate polarization rate at each element.

2. A few modification in the polarization calculation, but the results are not affected.

3. The radiation fluctuations per turn are halved for depolarization, since it is generated in the middle of one turn in average.

4. Rectified depolarization calculation.

5. Reduced the number of slices of a BEND from 0.1 photons to 1 photon per slice in emittance calculation. Also 1 photon/slice for 1 cm amplitude for MULT.

7. Set number of slices in tracking for BEND, QUAD, and MULT more consistently. Now the number of photons per slice is less than 1 (RING) ot 0.1 (TRPT), assuming r=0.02 m.

V1.1.6.3.3k64 Bugs in SOL Name：K. Oide Date：2019/02/18(Mon) 19:27:56 No.936

Fixes:

1. Bugs in optics, geometry, tracking in SOL with BEND and QUAD, after spin was included.

Changes:
The version number has jumped.

V1.1.1.6.3k64 Spin depolarization (still preliminary) Name：K. Oide Date：2019/02/13(Wed) 18:42:45 No.935

Changes:

1. Added spin depolarization calculatioin with resonance perturbation (preliminary). Currently coded up to 4th order, but routines are extendable to any order.

Re^3: problems with solenoid? Name：Akio Morita Date：2019/01/11(Fri) 13:46:06 No.923

まとめ
* SOLの仕様により、直感に反し、LN2とLN1はB1.2の幾何的な向きが異なる配置を記述している
* 一致する十分条件は、SOL1入り口で CHI3==0

Re^3: problems with solenoid? Name：Akio Morita Date：2019/01/11(Fri) 13:39:16 No.922

> Thank you. But,
> 私の使っているversionでは、
> 前の例のビームラインのVertical bend とSOL1　の間にさらに　horizontal bend を入れると、丁度90度でなくても結果がおかしくなるようです。（LN1 と LN2で結果が異なる）
>
提示されている作例では、B1.1の出口のCHI3が零でないので、SOLを挟むと以降の局所座標系定義が変更され、結果としてB1.2による軌道偏向の向きが変わる為で、SOLによる局所座標定義の仕様です

BENDのANGLEによる軌道偏向は、BENDの局所座標系で定義されている(実験室系に対する向きは、CHI1, CHI2, CHI3で定義される基底に依存している)
従って、作例ではSOLの存在の有無により、局所座標基底の変更が発生し、上流のビーム軸に対するB1.2の向きは、LN2に対してLN1は約48度回転しています

Re^2: problems with solenoid? Name：K.Kubo Date：2019/01/11(Fri) 13:21:41 No.921

Thank you. But,
私の使っているversionでは、
前の例のビームラインのVertical bend とSOL1　の間にさらに　horizontal bend を入れると、丁度90度でなくても結果がおかしくなるようです。（LN1 と LN2で結果が異なる）

SOL SOL1=(BOUND=1 BZ=0 GEO=1) SOL2=(BOUND=1 BZ=0);
MARK I1=() I2=();
DRIFT L1=(L=2.0);
BEND B1=(L=0 ANGLE=1.1);
BEND B2=(L=0 ANGLE=0.9 ROTATE=91 DEG);
! LINE LN1=(I1 B2 SOL1 L1 SOL2 B1 L1 I2);
! LINE LN2=(I1 B2 L1 B1 L1 I2);
LINE LN1=(I1 B2 B1 SOL1 L1 SOL2 B1 L1 I2);
LINE LN2=(I1 B2 B1 L1 B1 L1 I2);

FFS USE=LN1;
trpt; ins; cal;
geo1=LINE["GEO","I2"];

USE LN2;
trpt; ins; cal;
geo2=LINE["GEO","I2"];
!!!!!!!!!!
Print[geo1];
{{-.8362874400122727,3.134815502025808,-1.0499162144385719},{2.377544289773975,-.1645553477677297,-.3323464010711923}}
Print[geo2];
{{-.12124348536650054,3.402704293673355,.18887159256415886},{1.9807048644907819,.47302387509385363,-.7976160872880308}}
!!!!!!!!!!!!

Re: problems with solenoid? Name：Akio Morita Date：2019/01/11(Fri) 12:10:20 No.920

A2. NOT A BUG, Coordinate selection rule of SOL element definition

* SOL境界でローカル座標系を切替える際の座標系の選び方に「CHI3=0となる局所座標系を選ぶ」というSOL elementの仕様があるため、CHI3パラメータがリセットされSOL領域下流の主偏向ベクトルの向きがビーム軸に対して回転する
* Eular角(CHI1, CHI2, CHI3)は鉛直方向を向いた際に CHI1/CHI3にパラメータ縮退が発生(同一の直交基底に対して複数の表現が存在する)するため、演算誤差の範囲で同一の直交基底に対して異なるEular角表現が割り当てられるが、上記の接続ルールに基づきCHI3が零と成るようにビーム軸方向に回転した局所座標系が選択される結果、定義パラメータ摂動に対して局所座標系定義が不連続となっている
* ANGLE/ROTATEを 90度ちょうどから若干外す(例えば91deg)とamorita branch/k64 branch含めて再現する

Re: problems with solenoid? Name：Akio Morita Date：2019/01/10(Thu) 21:06:12 No.919

Comment 2. Latest MAIN trunk(V1.0.10.10.1a / revision 6436) makes same results
Print[geo1];
{{-1.414213562373095,1.4142135623730951,-2},{2.356194490192345,-6.123233995736766e-17,-1.5707963267948966}}
Print[geo2];
{{0,2,-2},{1.5707963267948968,0,-1.5707963267948966}}

something wrong...

Comparision of DISP G between MAIN trunk VS amorita branch
MAIN trunk:
Element Gx Gy Gz s Length Value Chi1 Chi2 Chi3 #
I1 .000000 .000000 .000000 .000000 .000000 0 .000000 .000000 .000000 1
B2 .000000 .000000 .000000 .000000 .000000 1.5707963 .000000 .000000 .000000 2
SOL1 .000000 .000000 .000000 .000000 .000000 .0000000 45.000000 -90.000000 -45.000000 3
L1.1 .000000 .000000 .000000 .000000 2.000000 2.0000000 45.000000 -90.000000 -8.1554E-15 4
SOL2 1.22465E-16 1.22465E-16 -2.000000 2.000000 .000000 .0000000 45.000000 -90.000000 -8.1554E-15 5
B1 1.22465E-16 1.22465E-16 -2.000000 2.000000 .000000 1.5707963 45.000000 -90.000000 .000000 6
L1.2 1.22465E-16 1.22465E-16 -2.000000 2.000000 2.000000 2.0000000 135.000000 -3.5084E-15 -90.000000 7
I2 -1.414214 1.414214 -2.000000 4.000000 .000000 0 135.000000 -3.5084E-15 -90.000000 8
$$$ -1.414214 1.414214 -2.000000 4.000000 .000000 0 135.000000 -3.5084E-15 -90.000000 9

amorita branch:
Element Gx Gy Gz s Length Value Chi1 Chi2 Chi3 #
I1 .000000 .000000 .000000 .000000 .000000 0 .000000 .000000 .000000 1
B2 .000000 .000000 .000000 .000000 .000000 1.5707963 .000000 .000000 .000000 2
SOL1 .000000 .000000 .000000 .000000 .000000 .0000000 .000000 -90.000000 .000000 3
L1.1 .000000 .000000 .000000 .000000 2.000000 2.0000000 .000000 -90.000000 .000000 4
SOL2 1.22465E-16 .000000 -2.000000 2.000000 .000000 .0000000 .000000 -90.000000 .000000 5
B1 1.22465E-16 .000000 -2.000000 2.000000 .000000 1.5707963 .000000 -90.000000 .000000 6
L1.2 1.22465E-16 .000000 -2.000000 2.000000 2.000000 2.0000000 90.000000 -3.5084E-15 -90.000000 7
I2 1.22465E-16 2.000000 -2.000000 4.000000 .000000 0 90.000000 -3.5084E-15 -90.000000 8
$$$ 1.22465E-16 2.000000 -2.000000 4.000000 .000000 0 90.000000 -3.5084E-15 -90.000000 9

Re: problems with solenoid? Name：Akio Morita Date：2019/01/10(Thu) 20:35:45 No.918

Comment 2. My latest version(amorita branch revision 5469) makes following different results
Print[geo1];
{{1.2246467991473532e-16,2,-2},{1.5707963267948966,-6.123233995736766e-17,-1.5707963267948966}}
Print[geo2];
{{1.2246467991473532e-16,2,-2},{1.5707963267948966,-6.123233995736766e-17,-1.5707963267948966}}

Re: problems with solenoid? Name：Akio Morita Date：2019/01/10(Thu) 20:28:11 No.917

A1. CAVI element in the solenoid region IS NOT SUPPORTED
and CAVI elements in such region IS DISCARDED.
Use MULT type element instead of CAVI.

problems with solenoid? Name：K.Kubo Date：2019/01/10(Thu) 15:10:44 No.915

I have two problems with solenoid (SOL)

Problem 1:
Beam line length of accelerating structure (CAVI) in Solenoid (SOL) becomes zero.
e.g.
!!!!!
SOL SOL1=(BOUND=1 BZ=0 GEO=1) SOL2=(BOUND=1 BZ=0);
MARK I1=() I2=();
CAVI CA1=(L=2.0 VOLT=0 FREQ=1.3e9 PHI=-1.570796);
LINE LN1=(I1 SOL1 CA1 SOL2 I2);
FFS USE=LN1;
trpt; ins; cal;
Print[LINE["S","*"]];
!!!!!
gives
"{0,0,0,0,0,0}"
(orbit length is zero)
!!!!!!!!

Problem 2:
Geometry of design orbit (given by "GEO") seems incorrect downstream of solenoid (SOL).
e.g.
!!!!!!
SOL SOL1=(BOUND=1 BZ=0 GEO=1) SOL2=(BOUND=1 BZ=0);
MARK I1=() I2=();
DRIFT L1=(L=2.0);
BEND B1=(L=0 ANGLE=1.5707963267948966);
BEND B2=(L=0 ANGLE=1.5707963267948966 ROTATE=90 DEG);
LINE LN1=(I1 B2 SOL1 L1 SOL2 B1 L1 I2);
LINE LN2=(I1 B2 L1 B1 L1 I2);
FFS USE=LN1;
trpt; ins; cal;
geo1=LINE["GEO","I2"];
USE LN2;
trpt; ins; cal;
geo2=LINE["GEO","I2"];
Print[geo1];
Print[geo2];
!!!!!!!
gives
Print[geo1];
{{-1.4142135623730947,1.4142135623730951,-2},{2.356194490192345,-6.123031769111886e-17,-1.5707963267948966}}
Print[geo2];
{{0,2,-2},{1.5707963267948968,0,-1.5707963267948966}}
!!!!!!!
Do I misunderstand something?
Is the SAD version (SAD Ver.1.0.10.5.3a10 built at 2012-01-30 16:19:56) too old?

V1.1.1.6.2k64 Fixes Name：K. Oide Date：2019/01/10(Thu) 05:20:36 No.914

Dear Users,

Fixes:

1. Corrected handling of spin in emittance calculation, esp. in the slicing of tsolque and texchg.

2. Fixed a mistake on rotation in tchge.

V1.1.1.6.1k64 Linear spin depolarization (wrong) Name：K. Oide Date：2019/01/08(Tue) 08:31:41 No.913

Dear Users,

Again, this is an experimental version, and do not use seriously.

Changes:

1. Added a linear spin depolarization calculation in emit/Emittance[]. However, it does not look right yet, and not consistent with tracking.

2. The number of parallel processes is determined by NPARA, number of particles and the length of the beamline.

Re: V1.1.1.6k64 Thank you and have a happy new year! Name：Akio Morita Date：2018/12/26(Wed) 14:43:41 No.907

> Changes:
> 1. Use S. Yamada's patch on utils.c to avoid piling up of temp files. He saids that using a pipe instead of a file was better to receive results of shell commands, but it has not been included so far, due to a bad experience of mine on pipe in an old system, probably HP-UX.
>
この"bad experience"というのは、backgroundな sub-processでは無く、foreground sub-processの出力先にpipeを使ったケースではないでしょうか？

pipeへのwrite(2)は、kernelのI/O bufferが埋まるとreader側が読みにくるまでblocking waitに入るので、foreground sub-processの出力をpipeへ向けた場合、write(2)のblockingによりsub-processが終了しないために、pipeのreaderである main-processも進行せずにデッドロックします

MAIN trunk系の実装は、sub-processがforeground時はunlink済みのファイル記述子、sub-processがbackground時はpipe(2)が生成するファイル記述子を使って実装しています(参考までに)

V1.1.1.6k64 Thank you and have a happy new year! Name：K. Oide Date：2018/12/26(Wed) 05:19:30 No.906

Dear colleagues.

A new version has been checked in into svn and GitHub devel repositories. Several fixes pointed out by A. Morita, S. Yamada and others have been included. Besides them major changes are going on in tracking (classical spin tracking and radiation calculation) and emittance (a kinematical algorithm). This version will be much buggier than usual, so please do not use this seriously yet. We need more time to debug.

Fixes:
1. A bug in qsol to have used qcopymat instead of qcopymatg (pointed out by A. Morita). An acceleration in SOL by MULT has been wrong.

Changes:
1. Use S. Yamada's patch on utils.c to avoid piling up of temp files. He saids that using a pipe instead of a file was better to receive results of shell commands, but it has not been included so far, due to a bad experience of mine on pipe in an old system, probably HP-UX.

2. DROTATE for BEND has been implemented in a more precise way without approximation, in both tracking and emittance/optics.

3. Tracking of classical spin vectors has been implemented. It is usable by TrackParticles with 8 variables under the flag POL. The 7th variable represent the phase angle of (s_x, s_z) and the 8th is s_z. s_{x,y,z} must be in the range [-1, 1]. These new variables are symplectic ones. Currently no algorithm like SLIM has not been implemented yet.

4. Added Nominal spin tune and Nominal polarization time to emitttance output. They are accessible by Emittance[], too.

5. Changed the algorithm to calculate radiation effects in tracking and emittance calculation by a kinematical method in all elements including fringes and multipoles. This algorithm can calculate radiations without knowing the detailed information on the field, and has been already applied to the tracking. However, several effects such as F1 of a dipole are not yet nicely included. It is under development and we shoud wait for the next year.

Corrected Name：K. Oide Date：2018/11/27(Tue) 13:13:38 No.895

Repositories have been recovered, I hope.

> Dear Users,
>
> Something has been wrong in the SVN and Git repositories for k64. Several files have been reset to very old ones, probably by my mistake. Please suspend to use them until further notice.

Something wrong in repositories Name：K. Oide Date：2018/11/27(Tue) 12:32:09 No.894

Dear Users,

Something has been wrong in the SVN and Git repositories for k64. Several files have been reset to very old ones, probably by my mistake. Please suspend to use them until further notice.

Re: Linux port status of MAIN trunk Name：Akio Morita Date：2018/11/19(Mon) 13:57:40 No.889

> ビルドが失敗する環境
> * RHEL7系(CentOS 7 etc)
> ** Base repositoryの GCC 4.8.5は古すぎてコンパイル出来ない
> ** おそらくglibcが古すぎて、新しいglibc features.hの推奨設定に対して前方互換性が無い?
> ** devtoolsetのGCCは、multilib対応になっていない?(最新版は未確認)
>
これらの問題は、2019年リリース予定のRHEL8で解決する見込み
RHEL8 public betaによれば、Linux kernel 4.18/GCC 8.2/glibc 2.28とFedora 29と同等の構成が予定されている

SAD Update V1.1.1.5.4k64 Name：K. Oide Date：2018/11/09(Fri) 20:15:46 No.886

Fixes:
1. Maintained optics calculation with TWAKE/LWAKE, which has been ignored for a long time.
2. Nested Get might have been causing "damaged buffer" error. Inserted \n after the previous record.
3. Fixed something like LINE["GEO","nnn+0.1"].
4. Wrong handling of a variable linep to cause "buffer damaged".
5. DROTATE becomes effective for MULTwith ANGLE=0.

Changes:
1. Location of img for SADHelp changed to Documents/SADHelp_img .
2. Fine adjustment of tespl in temits.f .
3. An error message in tfeval1.f.
4. The number of radial modes has minimum (15) in SynchroBetaEmittance.
5. tfCrypt_.c includes crypt.h if it exists.
6. gs.in to run sad1.exe in the same directory as gs. Also several environments are modified to use from the same root.
7. Avoid loading some .n files such as TopDrawer, D, etc., unless necessary.

Added:
1. A new function FFS$SHOW. FFS$SHOW[] returns the same result as FFS["SHOW"].

Linux port status of MAIN trunk Name：Akio Morita Date：2018/11/02(Fri) 11:21:38 No.883

MAIN trunkのLinux port状況(r6396)

ABI=32ビルド及び基本動作確認が出来た環境

* Ubuntu Desktop 18.04 LTS(GCC 7.3.0/glibc 2.27)
* Ubuntu Desktop 18.10(GCC 8.2.0/glibc 2.28)
* Fedora 29(GCC 8.2.1 20181011/glibc 2.28)

ビルドが失敗する環境
* RHEL7系(CentOS 7 etc)
** Base repositoryの GCC 4.8.5は古すぎてコンパイル出来ない
** おそらくglibcが古すぎて、新しいglibc features.hの推奨設定に対して前方互換性が無い?
** devtoolsetのGCCは、multilib対応になっていない?(最新版は未確認)

SAD Update V1.1.1.5k64 SynchroBetaEmittance, etc. Name：K. Oide Date：2018/10/07(Sun) 14:13:32 No.875

Fixes:
1. Fixed some conflicting lines in HelpMessages.n for commit by svn or
git.

Changes:

1. Closed orbit finding by EMIT with NORFSW now finds out the orbit
with the initial momentum given at the entrance of the beam line, which
can be specified by DP0+CALC.

2. SynchroBetaEmittance function returns the projected emittances
emitxp and emityp. The returned value is a list:

{{nus, emitx, emity, emitxp, emityp, conv}, ... }

where nus, emitx, emity, emitxp, emityp, conv are the synchrotron tune,
equilibrium horizontal and
vertical emittances, horizontal and vertical projected emittances, and
the convergence, respectively.

3. The closed orbit finding in SynchroBetaEmittance or SYNCHROBETA
command has been refined to obtain more exact closed orbit for each
momentum deviation.

4. The option of ls for FileDialog is changed to -lnatL to follow
symbolic links and to show all invisible files.

5. Now a new variable Default$CanvasBG can specify the BG of the canvas
created automatically without explicit generation using Canvas
function. The default is "white".

6. Internal detection of NaN is modified to catch -NaN, etc., generated
by the compiled modules depending on the compiler. Some complier indeed
generates different NaNs depending on the routine, for instance, 0/0
and sqrt(-1) result in different NaNs.

Re: bench2 on Ryzen Threadripper Name：Akio Morita Date：2018/09/11(Tue) 18:10:42 No.869

無負荷時の Ryzen Threadripper 2950Xのベンチマーク結果

* Ryzen Threadripper 2950X(16C/32T 3.5GHz/4.4GHz)
** Function 0.83381 ± 0.00668
** Optics 0.75103 ± 0.00821
** Tracking 0.64857 ± 0.00587
** Matching 0.05030 ± 0.00066
** Overall 0.03496 ± 0.00028
** 備考無負荷状態で測定

bench2 on Ryzen Threadripper Name：Akio Morita Date：2018/09/07(Fri) 11:24:03 No.867

今時のプロセッサによるbench2.sadによるベンチマーク結果です

MAIN trunk rev.6381
GCC 7.3.0 -O3 -fno-strict-aliasing -msse3

* Ryzen Threadripper 2950X(16C/32T 3.5GHz/4.4GHz)
** Function 1.12239 ± 0.35165
** Optics 0.96794 ± 0.29356
** Tracking 0.74701 ± 0.13624
** Matching 0.06615 ± 0.02171
** Overall 0.04528 ± 0.01260
** 備考並列コンパイルによるストレステスト中に測定(load average 25〜32)

* Core i7 6700K(4C/8T 4.0GHz/4.2GHz)
** Function 0.76979 ± 0.00623
** Optics 0.78260 ± 0.00234
** Tracking 0.68483 ± 0.00105
** Matching 0.05231 ± 0.00018
** Overall 0.03416 ± 0.00015
** 備考無負荷状態で測定

Re: Cygwinサポート削除の提案 Name：Kentaro Harada Date：2018/08/22(Wed) 18:41:44 No.855

賛成です。わざわざcygwinを使う必要はもう無いと思います。

Cygwinサポート削除の提案 Name：Akio Morita Date：2018/07/26(Thu) 15:34:42 No.837

MAIN trunkにあるCygwin環境のサポートを削除することを提案します

提案理由
* WSLによるLinux環境内でフル機能のSADを動かすことが可能になっている
** タブレットを除く近代的なWindowsPCでは、WSLの導入が可能
* Cygwinビルドでは一部機能が組み込めない(環境互換性が低い)
* Cygwinビルドの継続的なメンテナンスは行われていない(現行コードの動作を期待できない)
* Cygwin環境の特殊性に起因するコードを削除することで、見通しが良くなる

Cygwinに対するWSL環境の制約
* 32bit版WindowsやWindows RTのサポートが無い
** 主に、タブレット系の実装が該当するが、操作性の問題からSAD環境としての需要は少ない？
** ドライバ等の都合で32bit版を導入している特殊環境でSADが動く必要性は低いのでは？
* 現時点では、32bit Linuxバイナリサポートが無い(ビルドは可能だが、実行出来ない)
** MAIN trunkでは、OpenShared系が動作しないなどポインタ表現に起因する制約が有る
** k64 branchを代替品として推奨するか？
* Windows7/8上でサポートされない
** ともにメインストリームサポートは終了し延長サポート中
** 延長サポート終了は、2020/2023年(Windows7/8)
** Windows7は、Windows10への移行作業を行うべき時期が来ている
** Windows8に関しては、Windows10への無償アップグレードを実施したユーザーが多いのでは？