Use of the function computeRBGGE

[Nagaoka]

Hello,

I would like to use the function "computeRBGGE" available in elegant. To do so, I followed the example provided for a similar function "computeCBGGE" and modified the script "make_GGE" found for this example as follows:

# Make the generalized gradient expansion for a magnet having rectangular boundaries

fundamental=0
multipoles=6

magnet=dipole3T

file_xminus=dipole3T_xminus.sdds
file_xplus=dipole3T_xplus.sdds
file_yminus=dipole3T_yminus.sdds
file_yplus=dipole3T_yplus.sdds

rootN=dipole3T
rootS=dipole3T_skew

computeRBGGE -yminus=dipole3T_yminus.sdds -yplus=dipole3T_yplus.sdds~ -xminus=dipole3T_xminus.sdds -xplus=dipole3T_xplus.sdds \
-normal=$rootN.gge -skew=$rootS.gge -derivatives=10 -multipoles=$multipoles -fundamental=$fundamental \
-autotune=minimize=rms,verbose,logfile=$root.ggeLog,incr

Running this script, I get an error message "Error: Sort the input file dipole3T_yplus.sdds with sddssort -col=z -col=y -col=x", the meaning of which is not clear to me (please allow me I am a new elegant user ...). I would appreciate being instructed what to do. The four input data files were prepared by following again the provided example (the data file "Q5-cylinderFields.sdds"). To be clear, please let me attach one of the four files ("dipole3T_yplus.sdds").

Thanking you in advance for your kind help

[michael_borland]

You just need to sort the four files using the sddssort command. In bash, you can do

Code: Select all

for file in dipole3T_[xy]plus.sdds dipole3T_[xy]minus.sdds ; do 
 sddssort $file -column=z -column=y -column=x
 \rm ${file}~
done

--Michael

[Nagaoka]

Hello Michael,

I thank you for your quick reply.
So I included your block of commands in my script "make_RBGGE" and executed it, but strangely "computeRBGGE" kept on complaining with exactly the same message "Error: Sort the input file dipole***.sdds with sddssort -col=z -col=y -col=x".

I must therefore conclude that there is something fundamentally not compatible with elegant in the four sdds data files that I prepared. On my side, I have tried a number of different formatting including adjusting the number of lines per page to the total number of different z-values we have for a given (x, y) values, but the results were all the same and elegant kept complaining with the same error message.

On my side, one possible effective way to overcome this problem would be to test "computeRBGGE" with the example files that your could provide me with (as the example case provided for "computeCBGGE"), so that I can follow the formatting convention found in those files.

Thanking you again for your kind feedback

[michael_borland]

Can you upload the four files? I can check to see what the problem might be.

--Michael

[Nagaoka]

Michael,

Please let me upload the four original files prior to applying the command "sddssort -col=z -col=y -col=x".

Thanking you very much in advance for your precious help!

Ryutaro
(Please let me know if there was a problem in the file upload ... I encountered some anomaly in the process)

[michael_borland]

Ryutaro,

I don't see the uploaded files.

It might help to make a zip or other archive file, then upload that.

--Michael

[Nagaoka]

Michael,

I am sorry for this additional problem.
I am uploading a zip file.

Hoping that it goes well now.
Ryutaro

[michael_borland]

Ryutaro,

The problem is that the data was spread across multiple pages. You can fix this using these commands

Code: Select all

for file in dipole3T_[xy]*.sdds ; do  sddscombine $file m$file -merge ; done

Also, the x, y, and z data values appear to be in mm, but the definition is m. You can fix this with

Code: Select all

for file in m*.sdds ; do  sddsprocess $file -convert=col,[xyz],m,m,1e-3 ; done

Now you can plot the data as a check, e.g.,

Code: Select all

sddscontour -shade -xyz=z,y,By mdipole3T_xplus.sdds

However, the results look odd to me. See below.

There may be issues converting into SDDS. The program plaindata2sdds is a good choice for performing the conversion.

--Michael

[Nagaoka]

Michael,

I thank you so much for having spent your time diagnosing my problem and the numerical data (including detection of my error on the unit)! I shall follow your suggestions and redo the datafile production properly using your sdds commands.

Ryutaro

[Nagaoka]

Hello Michael,

First of all, many thanks once again for your help that allowed me to set up a procedure (using the SDDS commands you indicated) to prepare the SDDS data files needed. I finally managed to make the GGE decomposition with the magnet data set that you saw.

In doing so, I used the option -autotune=${mag3Ddata}.sdds, minimize=rms with the original 3D volume magnetic field data I got from my magnet colleague as ‘mag3Ddata’.

The results I got on the GGE decomposition output files ('***.gge) for normal and skew components both showed that the multipole value is limited to m=2 and no multipoles higher or equal to sextupole are given. I first thought that this is due to the too coarse grid of 2 mm that I used, so I asked my colleague to reduce the grid size to 0.25 mm, which was also the value I saw in the example case you provided in "ccbend1". Repeating the whole procedure with the new datafile, however, the limitation in 'm' remained the same, though I did see overall improvement in the fit level.

So, I wonder if the limitation in the m values (and in d values as well I think) comes from the fact that the 3D rectangular volume in my case is defined in a non-symmetric manner with respect to x = 0, as you very well pointed it out by showing me the four colored plots of By. Showing those plots to my magnet colleague, I could confirm that they are correct. However, as you saw he defined the horizontal extension to be -0.026 m <= x <= +0.010 m. So without any further specification, I suppose the GGE is done at x = -0.008 m instead of x = 0. Since the treated magnet is a transverse-gradient dipole on the outer parts and a longitudinal-gradient dipole at the center, we cannot make the GGE along the beam trajectory which is curved. However I suppose that the GGE better be done on an axis which is closest to the curved trajectory. Here I wish to have your opinion. I saw in the elegant manual that one could also define the decomposition axis using 'xCenter' and 'yCenter'. However, these parameters do not seem to appear in the description of 'computeRBGGE' so please let me also ask you if there is a way to do so without redefining the rectangular boundaries.

I thank you very much in advance for your help.
Ryutaro