Project

General

Profile

Bug #311

Macros

Added by Rogers, Chris over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tunnell, Christopher
Category:
bin(aries)
Target version:
Start date:
02 February 2011
Due date:
% Done:

100%

Estimated time:
Workflow:

Description

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.

#1

Updated by Tunnell, Christopher over 13 years ago

  • Category set to bin(aries)
  • Assignee set to Tunnell, Christopher
  • Target version set to MAUS-v0.0.1

Okay, so how should we set it up:

macros/
approved/
some_approved.py
another_approved.py
user/ # for user macros
demo/ # for demos
diagnostic/ # I run load tests of 1 million events

and for the components area:

components/
approved/
input
map
reduce
output
user/
input
map
reduce
output

would that work? it's more directory structure, but logical directory struceu.

#2

Updated by Rogers, Chris over 13 years ago

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)

#3

Updated by Tunnell, Christopher over 13 years ago

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...

#4

Updated by Rogers, Chris over 13 years ago

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.

Some points:
  • 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

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

#5

Updated by Tunnell, Christopher over 13 years ago

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.

#6

Updated by Tunnell, Christopher over 13 years ago

MAJOR CHANGE OF FILE STRUCTURE. Head is potentially unstable.

#7

Updated by Tunnell, Christopher over 13 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Applied in changeset r304.

Also available in: Atom PDF