Dear Users,
1. One more bug was found/fixed: In DynamicApertureSurvey, it crashed when the number of particles to be tracked is larger than the value of NP, whose default is 1,000.
1. A confusion in Check to mishandle Throw or Goto is corrected. If
uncatched Throw or Goto was detected in the first argument of Catch,
they are now handled as an error.
2. A bug to store a wrong value for the phase advances with CALC6D was
corrected.
3. In MAIN, the scheme to read machine errors as a list in a form
enclosed in () has been abandoned. Now expressions starting with ( are
handled properly.
> 1. A bug was found in emittance calculation (trade.f) by our Chinese colleagues in IHEP. The radiation damping matrix was wrong for dU/dy. This bug was created by
> V1.0.10.4a06 in Jan. 2010, even before k64. This affects all magnets
> when d(v \times B)/dy, or d(v \times B)/dx for MULT or QUAD within SOL
> with K1<0, are nonzero. QUADs outside of SOL are OK. This bug only
> affects EMIT/Emittance[] and has no direct effects on tracking/CALC/GO.
>
修正したradi(6.3)の項がradi(6.1)の項と同一スカラ起源の微分だとすると、
符号間違いの表式が最初に現れたのは、src/trade.f revision 1.20では無く
revision 1.13(2009.12.06 02:36:18 UTC/V1.0.10.3.9a01)と思われます
また、SOL領域外のQUADでもあってもoffaxisビームの場合は、影響があるケースが
存在できるように見えます
One more change:
4. There has been an issue when tracking is done without CALC, as the local momentum is not yet calculated. It is partially fixed, but not perfect, since a change of parameters for CAVI is not always detected. Please do CALC before tracking if parameters that affect the local momentum are changed.
1. A bug was found in emittance calculation (trade.f) by our Chinese colleagues in IHEP. The radiation damping matrix was wrong for dU/dy. This bug was created by
V1.0.10.4a06 in Jan. 2010, even before k64. This affects all magnets
when d(v \times B)/dy, or d(v \times B)/dx for MULT or QUAD within SOL
with K1<0, are nonzero. QUADs outside of SOL are OK. This bug only
affects EMIT/Emittance[] and has no direct effects on tracking/CALC/GO.
2. A bug in FItFunction was fixed when there is no fit conditions given
by regular fit commands.
3. File mapping is applied for input files by OpeRead/Get/GetMAIN. Thus
no limitation on the length of an input line.
追加する必要があるパッケージ
sudo apg-get install gcc
sudo apg-get install gfc
sudo apg-get install make
sudo apg-get install bison
所外の方向け：sad.confサンプル
SAD_ROOT=$(HOME)/SAD
# Enable 2GB limit workaround for mmap(2) on Linux/x86_64
ifeq ($(CPU_ARCH),AMD64)
COPT+=-DUSE_MMAP_FOR_MALLOC -DTRY_SAD_MAP_ADDR32
endif
# Refer libffi-dev package
LIBFFI_INCDIR_AMD64=/usr/include/x86_64-linux-gnu
LIBFFI_INCDIR_i386=/usr/include/i386-linux-gnu
LIBFFI_INCDIR=$(LIBFFI_INCDIR_$(CPU_ARCH))
# Refer libopenblas-dev package(Does not work with Ubuntu 14.04.05LTS)
#USE_BLAS=OpenBLAS
書いてみました！
原田の知っている範囲では、漢字で「しょない」はNGワードです。
しょないネットとか、しょないの人は見られるとか、しょないという
単語を使いたい場合は、ひらがなにしましょう。
どうしてこれがNGワードなのか、全く理解できません。
No.223
http://afsad1.kek.jp/redmine/projects/oldsad-trunk/wiki/SAD_on_Win10
> >:~/oldsad/script$ ~/oldsad/bin/gs bench2.sad
> *** Welcome to SAD Ver.1.0.10.5.14a4 built at 2017-03-21 12:43:23 +0900 ***
> *** Today: 12:45:53 Tuesday 03/21/2017 ***
> cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1793
> OFF LOG ECHO;READ 77 ; 23
> cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1793
> cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1792
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
> lmalloc4: allocated chunk offset is out of range
> base=0x117dd0 heap=0x7f50c3740010 offset=0xfea186c5048
> Memory Full, request: 4000001 1 2044367
> STOP talocp@italoc.f
>
> というエラーで止まってしまいます。解決法がありますでしょうか？
sad.confをまともに設定してください
Web上にまとめを書いたど、URLを記述すると投稿できないので、これ以上なにもする気が起きません
>:~/oldsad/script$ ~/oldsad/bin/gs bench2.sad
*** Welcome to SAD Ver.1.0.10.5.14a4 built at 2017-03-21 12:43:23 +0900 ***
*** Today: 12:45:53 Tuesday 03/21/2017 ***
cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1793
OFF LOG ECHO;READ 77 ; 23
cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1793
cpu time= 1.5625E-02(sec) dt= 15.625(msec) free area:: 1792
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c1940010 offset=0xfea18305048
lmalloc4: allocated chunk offset is out of range
base=0x117dd0 heap=0x7f50c3740010 offset=0xfea186c5048
Memory Full, request: 4000001 1 2044367
STOP talocp@italoc.f
というエラーで止まってしまいます。解決法がありますでしょうか？
なお、デフォルトから追加で
sudo apt-get install make
sudo apt-get install cc
sudo apt-get install fcc
sudo apt-get install bison
をインストールしてコンパイルを完結させました。
MAIN trunk V1.0.10.5.14a4にて、64bit WSL環境でのコンパイルと基本動作の確認を実施
* 動作が確認できたもの
** script/bench2.sad
** script/amida.sad
** devel/FFICall拡張モジュール
** devel/FFTW拡張モジュール
** devel/LAPACK拡張モジュール + liblapack-dev package
* コンパイル段階で問題が発生するもの
** devel/LAPACK拡張モジュール + libopenblas-dev package (OpenBLASと正しくリンクできない)
環境構築メモを置いたURLは、禁則により投稿不能のようです
表題の通りWindows Subsystem for Linux上にSADをホストするケースの検証を行いました
一部制約がある点以外、ベアメタルのUbuntu Linuxと同程度にSADが動作することを確認できました
拡張機能のダイナミックロードなど、cygwinよりも良好な結果が得られています
検証時に見つかった問題の修正を反映した MAIN trunk V1.0.10.5.14a4以降であれば、
ある程度動くと期待できます(それ自体は未検証)
Dear Users,
1. Due to the previous change in TrackParticles, a bug was created in V1.1.0.3k64, to prevent tracking for one element-by-element case.
2. Unnecessary print-out was generated during tracking.
Dear Users,
1. Another bug was found for Emittance[Matrix->True], not returning the transfer matrix for the end of line. By the way, TransferMatrix function is more recommended for this purpose, usable issuing CALC/GO with CALC6D.
Dear Users,
1. There has been an issue in TrackParticles if it starts at an element with nonzero OFFSET and the ends at a location earlier than the effective start point. It is corrected to return {start, coords} without tracking in such a case.
Dear Users,
1. A bug was found in qfraccomp (qtwiss.f) to determine the orientation of an element in a wrong way. It has been there since V1.1k64.
> SAD上でcagetのオプションをつける方法ってありますでしょうか？
> コマンドラインでcagetだけで取ってくると"Illigal Value"になり、SADでも
> 同様、コマンドラインではcagetにオプションとして"-n"をつけると値が取って
> こられる、というレコードをSADから値を取りたいのです。
>
caget -n しただけなら、Get["!caget -n ..."]とか (fp = OpenRead["!caget -n ..."]; r = Read[fp, String]; Close[fp]; r)で解決な気も…
SADのEPICS CA実装は複数有り、呼び出し関数・改版状態により内部実装・動作が違います
従って、上手く動かないとされる実行形式に対応するsource revisionと呼び出した関数を
特定しないと調べようがありません
問題の cagetの -n オプションは、DBF_ENUMなレコードに関するものなので、
MAIN trunkの”最新版”から関連する動作を抜き出すと以下の通り
* CaMonitor系(src/CaSearch2.c)
** DBR_TIME_LONGでca_add_masked_array_eventする
* CaRead/CaGet/CaWrite/CaPut系(src/CaSearch_.c)
** DBR_TIME_ENUMでca_array_getする
*** struct dbr_time_enumのvalue要素の値を realへ型変換
*** dbr_enum_t型は、epicsUInt16型なので整数値が返ると思われる(caget -nの動作に近いと思うのですが…)
** こちらの内部実装は、2016.02.17に大規模な改修が行われている
*** 以前の実装は、DBR_TIME_DOUBLEで ca_array_getしている
SAD上でcagetのオプションをつける方法ってありますでしょうか？
コマンドラインでcagetだけで取ってくると"Illigal Value"になり、SADでも
同様、コマンドラインではcagetにオプションとして"-n"をつけると値が取って
こられる、というレコードをSADから値を取りたいのです。
Dear Users,
1. A bug was found in the optics/emittance for MULT with acceleration. The rf phase was wrongly handled since V1.0.10.9k64.
Dear Users,
1. A new keyword DVOLT will be added to CAVI and MULT in the next version, 1.1.0.3k64. DVOLT is to be added to VOLT without affecting the design momentum p0(s).
2. A bug was there in CALC/GO with CALC6D with acceleration and TRPT. The normalization of orbit according to p0(s) has been applied twice.
Dear Users,
1. The next version 1.1.0.3k64 brings a few new options in Graphics: FrameFontScale, LegendFontScale. These specify a relative sizes of FrameLabel and Legend. FrameFontScale (also TickFontScale) accepts a real number or a list of real numbers. If it is a real number, it is applied to all frames. If it is a list, it is applied in the order of bottom, left, top, right in the same way as FrameLabel. If its length is shorter than 4, 1's are supplemented to the right.
2. OpticsPlot accepts an option RemoveOverlap. If it is not "L$NAME", the overlapping of the labels of the lattice is unsolved.
PSPAC: Apply space charge effect on particles at SPCH elements defined in the lattice. Please ask Ohmi-san for the usage and parameter settings. Tracking only.
SPAC: Apply space charge effect on particles at each DRIFT, extrapolating to nearby other elements. Any distribution of the beam is accepted and a circular beam pipe is assumed. It assumes an electrostatic model and solves Laplace equation at each location. Tracking only.
WSPAC: It assumes 6D Gaussian distribution of the beam, then calculates the space charge force semi analytically. The beam pipe is ignored. Valid for tracking, emittance, and calc/go (either with CALC4D or CALC6D).
See below in the text also.
I have not tested them in recent years with k64, so any issues may be there.
> As described in the manual, three flags, SPAC, WSPAC and PSPAC, which will take space charge into account when do tracking. In my preliminary understanding, SPAC + 'SELFCOD' could calculate space charge based on a cylindrical symmetry chamber, referring to the current center of beam but not orbit given by emit. Meanwhile, "WSPAC" could consider space charge with assuming Gaussian distribution in the all dimensions, corresponding to number of particles in beam (PBUNCH). As for "PSPAC" use the PIC method to decide space charge ( which should be relative to the number of macro-particles?).
Both SPAC and PSPAC use PIC, in different algorithms.
>
> However, I truly confuse of "SPAC" on the space charge is simulated according to the number of particles in beam or number of macro-particles?
SPAC just uses the macro particles currently tracked, whose initial number is given by NPART.
>
> Many thanks!
Dear Users,
1. A bug was found that the keyword SIGMAZ in LINE, forMARK, did not work.