Skip to content

Commit

Permalink
Fixed foil tracking when there is an offset. (#930)
Browse files Browse the repository at this point in the history
* Fixed foil tracking when there is an offset.
  • Loading branch information
DavidSagan committed Apr 24, 2024
1 parent 8838c21 commit 449730b
Show file tree
Hide file tree
Showing 17 changed files with 80 additions and 3,200 deletions.
4 changes: 2 additions & 2 deletions bmad-doc/tutorial_bmad_tao/doc/tutorial_bmad_tao.tex
Original file line number Diff line number Diff line change
Expand Up @@ -1887,8 +1887,8 @@ \subsection{Variables in Tao}
If you want to have one \tao \vn{variable} control a set of parameters, construct an \vn{overlay} or
\vn{group} element (\sref{s:control}) and then have the \tao variable control the overlay or
group. For example, the following overlay gangs the \vn{k1} parameters of elements \vn{Q1} and
\vn{Q3} together:
group. For example, the following overlay defined in the lattice file gangs the \vn{k1} parameters
of elements \vn{Q1} and \vn{Q3} together:
\begin{code}
ps1: overlay = {Q1, Q3}, var = {k1}, k1 = 0.8
\end{code}
Expand Down
135 changes: 71 additions & 64 deletions bmad/doc/lat-struct.tex
Original file line number Diff line number Diff line change
Expand Up @@ -639,7 +639,7 @@ \section{Lattice Bookkeeping}
given parameter in the lattice is changed. For example, if the accelerating gradient of an
\vn{lcavity} element is modified, the reference energy parameter of all elements downstream of the
\vn{lcavity} will need to be changed and this can also alter the transfer maps of the \vn{lcavity}
and downstream elements. \bmad divides the lattice bookkeeping into ``core'' part and everything
and downstream elements. \bmad divides the lattice bookkeeping into a ``core'' part and everything
else. The core part itself is divided into five parts:
\begin{description}
\item[Attribute bookkeeping] \Newline
Expand All @@ -660,63 +660,8 @@ \section{Lattice Bookkeeping}
\vn{ele%value(E_tot\$)} and \vn{ele%value(p0c\$)}
\end{description}

%----------------------------------------------------------------------------
\section{Intelligent Bookkeeping}
\label{s:intelligent.book}
\index{bookkeeping!automatic}
\index{bookkeeping!intelligent}
Historically, as the code for lattice bookkeeping (\sref{s:lat.book}) was being developed
calls to bookkeeping routines were added to calculational
routines such as the tracking routine \Hyperref{r:track1}{track1} and the routine for calculating
the linear transfer map \Hyperref{r:make.mat6}{make_mat6}. This ``automatic'' bookkeeping system is
inefficient since there is no good way to keep track of what element attributes have been modified
which leads to redundant bookkeeping calculations. Eventually, as \bmad developed and became more
complicated, it was found that the unnecessary bookkeeping load was generally causing a significant
slowdown in program execution time --- even in programs where no element attributes were changed. To
avoid this, an ``intelligent'' bookkeeping system was developed which could be switched on by setting
the parameter:
\begin{example}
bmad_com%auto_bookkeeper = .false.
\end{example}
To keep things back compatible with
existing programs, the automatic bookkeeping system was set as the default. However, given the fact that the
automatic bookkeeping system has known deficiencies, and given the overhead with maintaining two
bookkeeping systems, the current plan is to start phasing out the automatic bookkeeping system
sometime in the not-so-far future. Thus old programs should be converted to the new system and all
new programs should use the new bookkeeping system.

\index{bmad_common_struct!auto_bookkeeper}
To use intelligent bookkeeping, a program must set the global \vn{bmad_com%auto_bookkeepper} to
false. This must be done once at the start of the program before \vn{bmad_parser} is called.
If lattice parameters are not modified in the program, this is the only thing that needs to
be done.

When a set of attributes needs to be modified, the
\Hyperref{r:set.flags.for.changed.attribute}{set_flags_for_changed_attribute} routine must be called
for each element attribute that is set. After all the attributes have been set,
\Hyperref{r:lattice.bookkeeper}{lattice_bookkeeper} is called to do the core bookkeeping. Example
\begin{example}
type (lat_struct) lat
...
bmad_com%auto_bookkeeper = .false. ! Done once. Put this before the call to bmad_parser.
...
lat%ele(i)%value(gradient$) = 1.05e6 ! Change, say, the gradient of an RFCavity
call set_flags_for_changed_attribute (lat%ele(i), lat%ele(i)%value(gradient$))

... Set attributes of other elements ...

call lattice_bookkeeper (lat) ! Do once after all attribute sets done.
\end{example}
The argument list for \vn{set_flags_for_changed_attribute} is
\begin{example}
set_flags_for_changed_attribute (ele, attribute)
\end{example}
The \vn{attribute} argument may be either real, integer, or logical.

\index{ele!\%status}
\index{bookkeeper_status_struct}
The \vn{set_flags_for_changed_attribute} routine sets flags in the \vn{ele%status} structure. This
structure is of type \vn{bookkeeper_status_struct} and looks like
Lattice elements have a \vn{bookkeeper_status} component which is of type \vn{bookkeeper_status_struct}
which looks like
\begin{example}
type bookkeeper_status_struct
integer attributes ! Intra element dependent attribute status
Expand All @@ -728,9 +673,8 @@ \section{Intelligent Bookkeeping}
integer rad_int ! Radiation integrals cache status
end type
\end{example}
All components of this structure give the status of some lattice
bookkeeping aspect. The first five components of this structure
correspond to the five core bookkeeping parts discussed above. The
All components of this structure give the status of some lattice bookkeeping aspect. The first five
components of this structure correspond to the five core bookkeeping parts discussed above. The
other two components are discussed below.

Possible values for the status components are
Expand All @@ -755,9 +699,8 @@ \section{Intelligent Bookkeeping}
\vn{ele%status%mat6} attribute of an element set to \vn{ok\$} it knows that it should recalculate
any transfer maps that span that element.

It is guaranteed that when \vn{lattice_bookkeeper} is run,
all five core status components will not be \vn{stale\$}.
The routines used by \vn{lattice_bookkeeper} are:
It is guaranteed that when \vn{lattice_bookkeeper} is run, all five core status components will not
be \vn{stale\$}. The routines used by \vn{lattice_bookkeeper} are:
\begin{example}
\Hyperref{r:attribute.bookkeeper}{attribute_bookkeeper} ! Intra-element attributes
\Hyperref{r:control.bookkeeper}{control_bookkeeper} ! Lord/slave control
Expand All @@ -774,6 +717,70 @@ \section{Intelligent Bookkeeping}
matrix was computed has shifted. \vn{lat_make_mat6} will set the \vn{ele%status%mat6} flag to
\vn{ok\$} for all elements whose transfer matrices are recomputed.

%----------------------------------------------------------------------------
\section{Intelligent Bookkeeping}
\label{s:intelligent.book}
\index{bookkeeping!automatic}
\index{bookkeeping!intelligent}
Historically, as the code for lattice bookkeeping (\sref{s:lat.book}) was being developed
calls to bookkeeping routines were added to calculational
routines such as the tracking routine \Hyperref{r:track1}{track1} and the routine for calculating
the linear transfer map \Hyperref{r:make.mat6}{make_mat6}. This ``automatic'' bookkeeping system is
inefficient since there is no good way to keep track of what element attributes have been modified
which leads to redundant bookkeeping calculations. Eventually, as \bmad developed and became more
complicated, it was found that the unnecessary bookkeeping load was generally causing a significant
slowdown in program execution time --- even in programs where no element attributes were changed. To
avoid this, an ``intelligent'' bookkeeping system was developed which could be switched on by setting
the parameter:
\begin{example}
bmad_com%auto_bookkeeper = .false.
\end{example}
To keep things back compatible with existing programs, the automatic bookkeeping system was set as
the default. However, given the fact that the automatic bookkeeping system has known deficiencies,
and given the overhead with maintaining two bookkeeping systems, the automatic bookkeeping system
has been retired and old programs needed to be upgraded if needed. Rule: A program that does not
``directly modify'' element attributes does not have to modified. Modification of element attributes
via \bmad routines (for example, using the \vn{set_on_off} routine) is ``indirect''. A direct modification
is something like the following appearing in the program:
\begin{example}
lat%ele(ie)%value(hkick$) = ...
\end{example}

\index{bmad_common_struct!auto_bookkeeper}
To use intelligent bookkeeping, a program must set the global \vn{bmad_com%auto_bookkeepper} to
false. This only needs to be done once at the start of the program before \vn{bmad_parser} is called.
If lattice parameters are not modified in the program, this is the only thing that needs to
be done.

When a set of attributes needs to be modified, the
\Hyperref{r:set.flags.for.changed.attribute}{set_flags_for_changed_attribute} routine must be called
for each element attribute that is set. After all the attributes have been set,
\Hyperref{r:lattice.bookkeeper}{lattice_bookkeeper} is called to do the core bookkeeping. Example
\begin{example}
type (lat_struct) lat
...
bmad_com%auto_bookkeeper = .false. ! Done once. Put this before the call to bmad_parser.
...
lat%ele(i)%value(gradient$) = 1.05e6 ! Change, say, the gradient of an RFCavity
call set_flags_for_changed_attribute (lat%ele(i), lat%ele(i)%value(gradient$))

... Set attributes of other elements ...

call lattice_bookkeeper (lat) ! Do once after all attribute sets done.
\end{example}
The argument list for \vn{set_flags_for_changed_attribute} is
\begin{example}
set_flags_for_changed_attribute (ele, attribute)
\end{example}
The \vn{attribute} argument may be either real, integer, or logical.

\index{ele!\%status}
\index{bookkeeper_status_struct}
The \vn{set_flags_for_changed_attribute} routine sets flags in the \vn{ele%status} structure
\sref{s:lat.book}.

\isittrue???

%----------------------------------------------------------------------------
\section{particle_start Component}
\label{s:lat.beam.start}
Expand Down
5 changes: 3 additions & 2 deletions bmad/low_level/track_a_foil.f90
Original file line number Diff line number Diff line change
Expand Up @@ -47,8 +47,8 @@ subroutine track_a_foil (orbit, ele, param, mat6, make_matrix)

call offset_particle (ele, set$, orbit, set_hvkicks = .false., mat6 = mat6, make_matrix = make_matrix)

if (orbit%vec(1) < ele%value(x1_edge$) .or. orbit%vec(1) > ele%value(x2_edge$)) return
if (orbit%vec(3) < ele%value(y1_edge$) .or. orbit%vec(3) > ele%value(y2_edge$)) return
if (orbit%vec(1) < ele%value(x1_edge$) .or. orbit%vec(1) > ele%value(x2_edge$)) goto 8000 ! Offset back and return
if (orbit%vec(3) < ele%value(y1_edge$) .or. orbit%vec(3) > ele%value(y2_edge$)) goto 8000 ! Offset back and return

z_particle = nint(ele%value(final_charge$))
f = ele%value(f_factor$)
Expand Down Expand Up @@ -139,6 +139,7 @@ subroutine track_a_foil (orbit, ele, param, mat6, make_matrix)

!

8000 continue
call offset_particle (ele, unset$, orbit, set_hvkicks = .false., mat6 = mat6, make_matrix = make_matrix)

!------------------------------------------------------------------------------------------------------
Expand Down
1 change: 0 additions & 1 deletion bsim/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,6 @@ set (EXE_SPECS
cmake_files/cmake.tune_scan
cmake_files/cmake.dark_current_tracker
cmake_files/cmake.envelope_ibs
cmake_files/cmake.srdt_lsq_soln
cmake_files/cmake.frequency_map
cmake_files/cmake.bbu
cmake_files/cmake.dynamic_aperture
Expand Down
12 changes: 0 additions & 12 deletions bsim/cmake_files/cmake.srdt_lsq_soln

This file was deleted.

2 changes: 0 additions & 2 deletions bsim/srdt_lsq_soln/example/bmad.lat

This file was deleted.

Loading

0 comments on commit 449730b

Please sign in to comment.