Note that this task is currently a specification taask - i.e. we need to understand what is needed first

Email from Rogers to Dobbs:

You have Marco's g4beamline model. By my recollection and with chat to
Summer, it sounds like it's a bit more complicated than it could be. Is
the plan to continue with this model into the future? Do you foresee any
sort of interface with MAUS or equivalent?

We need to implement at least everything from TOF0 down, and we have a
collaboration between Jason Tarrant (geometry) Matt Littlefield (MAUS
interface) and Stefania Ricciardi (verification) currently collaborating
to try to make this work from TOF0 all the way through MICE channel. You
may want to get "in on it"...

Email from Dobbs to Rogers

I have been meaning to chat to you about this, as it happens. Marco's g4bl
system is complicated, and I have yet to dive in and take ownership of it.
Its higher up my list now as I have a summer school student, Rose, who is
doing a project on the effect of varying the target parameters on the MICE
particle rate. The two main difficulties are simulating the huge number of
ISIS protons needed to get meaningful statistics down our beamline, and
finding a g4bl deck which is accurately represents the beamline as it now
stands.

In addition, if maus only covers the downstream beamline it would seem
important that we don't lose our ability to simulate the upstream beamline
somehow, either by extending the scope of maus or getting g4bl into a
reliable condition (which seems the more likely of the two). If the latter
then an interface between the two regimes would also be important.

So, yes, this is something I would like to get in on. Do you have any
thoughts about a good way forward? Also do you know of any existing g4bl
decks which accurately represent the upstream beamline?

Email from Rogers to Dobbs:
I agree that we probably want to run g4beamline to TOF0.

I have a copy of Marco's deck, driven by a ~few hundred line python
script. The script is quite complicated, the functionality it offers is:-

• Automatically read in magnet currents from run conditions spreadsheet
  (but needs to be reformatted to csv format)
• Parallelisation
• Automatically split the upstream beamline; for settings with identical
  beamlines, don't rerun upstream stuff (unless you really want to)

It doesn't talk to the Configuration DB.

The way I would probably work is:-

• We put Marco's deck on bazaar to do version control and put this as a
  separate third party library. Putting the beamline deck on bazaar - I
  see this as crucial regardless of the rest.
• We include G4Beamline as a third party library in MAUS
• We write an input or mapper in MAUS to run particles through (depends
  what you want to do). This means you are bound by MAUS's release cycle,
  MAUS's quality control, etc - advantages and disadvantages to that.

The advantage is that you are automatically included in the MICE monte
carlo, you can use the MAUS configuration database interfaces, you can
use the MAUS test server. Also if we ever get round to parellelising
MAUS properly, you can take advantage of that.

Disadvantage is that you are bound by our style requirements and QA
requirements.

An alternative might be to include MAUS as a third party application and
use the cdb interface that way.

Another alternative might be to reimplement the geometry in CAD for
import in the general MICE CAD import stuff.