I would expect to find a directory called bin at top level with executables in, though I guess might be a bit of a misnomer if they weren't binary executables (rather python scripts)

it's more how you do the user/approved split. the most naive way is by having a user and approved directory in both components and macros (we can always change that name)

my tabs didn't appear in my last post...

Thinking about it some more:-

So I want new users to see a ${MAUS_ROOT_DIR}/bin/ with applications
where stupid users who just want to run a beam through some lattice
and get some sensible output can do

${MAUS_ROOT_DIR}/bin/beam_maker input_parameters.py
${MAUS_ROOT_DIR}/bin/simulation input_parameters.py
${MAUS_ROOT_DIR}/bin/digitization input_parameters.py
${MAUS_ROOT_DIR}/bin/space_point_recon input_parameters.py
${MAUS_ROOT_DIR}/bin/track_recon input_parameters.py
${MAUS_ROOT_DIR}/bin/event_display input_parameters.py

or whatever, where "whatever" should be defined.

• I think the directory should be called bin because that's more-or-less
  standard across different linux packages.
• I think the bin directory should have only "approved" applications in
  it so that our poor users don't have to figure out whether to use
  digitisation, Digitization, tofDigitization or kekDigitization2007 or
  whatever else there is.
• examples directory should have sample input_parameters.py and
  presumably some sample geometries.
• this basic effort to run a beam through a lattice and do some
  reconstruction should be documentable in one line or so - that means
  that we have a sensible interface. Not all users know (or want to know)
  python. They just want something that works.

We can have some sample geometries and input_parameters.py files in
examples directory.

--

This clean interface is not so important when we get to "components"
because already the folks who make it that far are implicitly saying
they want to write code, even if it's a stupid script - and thus must be
prepared to read documentation. Then it's up to our release management
to make sure that components are suitably documented, etc.

What do you think?

Cheers,
Chris

mice-server@stfc.ac.uk wrote:

Issue #311 has been updated by Tunnell, Christopher.

it's more how you do the user/approved split. the most naive way is by having a user and approved directory in both components and macros (we can always change that name)

my tabs didn't appear in my last post...
----------------------------------------
Bug #311: Macros
http://micewww.pp.rl.ac.uk:8080/issues/311

Author: Rogers, Chris
Status: Open
Priority: Normal
Assigned to: Tunnell, Christopher
Category: Macros
Target version: MAUS-v1.0

I would like to enforce that macros contains only "approved" executables, something like:

beam generation
simulation
digitization
space point reconstruction
track reconstruction
online monitoring
event display
one calibration application per detector
optics

We could, alternatively, make a new directory that had this in. I think G4MICE's habit of having multiple apps that do different or the same things is very destructive. We, as a group, lose focus on what we are trying to deliver and new users get confused.

We can add more things, but I think it is not satisfactory to have tests, demo apps, 'proper applications', etc all in one place.

--
ASTeC Intense Beams Group

tel: +44 (0)1235 44 6983
fax: +44 (0)1235 44 5607

Building R2,
Rutherford Appleton Laboratory,
Harwell Science and Innovation Campus,
Didcot.
OX11 0QX

probably worth a quick face to face to discuss? The bin thing sounds fine but I'd like to get this right from the start...

I'm just hanging out in R1 about to add numpy/xboa as a reducer since there aren't many reducer examples I've put in.

MAJOR CHANGE OF FILE STRUCTURE. Head is potentially unstable.