The OPAL Discussion Forum

[Dragos Constantin <Dragos.Constantin AT varian.com>]

Hi Nicole,

Thank you. We figured out that the axial field is stored in the ‘STAT’ file.

 

However, I couldn’t locate “section 1.7.1” in the user manual for OPAL 2.0.0. What is the title of that section?

 

Thanks,

Dragos

 

From: Nicole Neveu <nneveu AT hawk.iit.edu>
Sent: Tuesday, December 10, 2019 3:47 PM
To: Dragos Constantin <Dragos.Constantin AT varian.com>
Cc: Christof Metzger-Kraus <christof.j.kraus AT gmail.com>; opal <opal AT lists.psi.ch>
Subject: Re: [Opal] RFCavity length and field output for OPAL-t

 

Hi Dragos, 

 

Maybe this question was answered offline...

The fields seen by the beam (in x,y, and z) are stored in the stat file, columns 34-39.

See section 1.7.1 of the OPAL manual, under the OPAL-T section.

 

Thanks, 

 

Nicole

 

On Thu, Dec 5, 2019 at 10:25 AM Dragos Constantin <Dragos.Constantin AT varian.com> wrote:

Hi Christof,

Thank you for your quick replay. It is definitely good to know that for OPAL-t the field map dimension takes precedence over the length of the RFCavity length as specified in the input file. I am not sure what the situation is with the other beamline elements.

 

From my perspective I think it would be less prone to errors if the length of the beamline elements in the input file has precedence over the field map header spatial information. Also, this will benefit a situation where one chooses to consider the length of a beamline element as a design parameter and use the built-in multi objective optimization routines.

 

I also think the code should throw a warning or an error, if there is a mismatch between the beamline length in the input file and the one specified in the corresponding field map header. For example, one could have an extra Boolean parameter added to the relevant beamline elements, let’s call it FEW = Flag for Error or Warring, which controls if the code throws a warning and continues to run or it throws and error and it stops in case of a length mismatch.

 

I believe being able to get the field as used by OPAL-t is important. This can help tremendously when debugging a model. In general one has to prepare the field maps to have the right format and in my experience being able to close the loop and verify the import/export routines is critical. I am not sure how easy it will be to have DUMPFIELDS and DUMPEMFIELDS from OPAL-cycl ported to OPAL-t, but it will be great to have these two routines available for OPAL-t.

 

Last but not least, where is the on-axis field recorded for OPAL-t, i.e. in what output file? And, do I need to specify anything in the input file to have the field exported?

 

Thanks,

Dragos

 

 

 

 

 

From: Christof Metzger-Kraus <christof.j.kraus AT gmail.com>
Sent: Thursday, December 5, 2019 2:12 AM
To: Dragos Constantin <Dragos.Constantin AT varian.com>
Cc: opal <opal AT lists.psi.ch>
Subject: Re: [Opal] RFCavity length and field output for OPAL-t

 

Hi Dragos,

 

currently the length of the RF cavity in the input file is ignored, only the length in the field map file is used. And Opal-t only outputs the on-axis field for some field types (one dimensional field maps), but not in general.

 

I could add both ideas to the issue tracker if you'd like.

 

Cheers,

christof

 

On Thu, Dec 5, 2019 at 10:53 AM Dragos Constantin <dragos.constantin AT varian.com> wrote:

Dear Colleagues,
I have some questions regarding RFCavity and field output in OPAL-t mode.

In the manual, at page 88, it is stated that the frequency of the RFCavity
card overrides the frequency defined in the FMAPFN file header. Is this true
for the length of the RFCavity as well? I mean, if I would like to change the
length of the RFCavity, do I have to edit the FMAPFN header to adjust the grid
dimension as well?

Along these lines, how do I get the fields used by OPAL-t in its calculations?
I would like to double-check that the fields used are correct. The manual
specifies only output options for OPAL-cycl as described in Chapter 11.

Thanks,
Dragos