using Jinja templates allows us to nicely create the runscripts without nasty conditionals.

Setting the reschedule flag should probably go through the RESTful PUT method rather than a dedicated reschedule method in html service.

Might be worth looking for way to have a single session with sub transaction contexts instead

Proposed structure, still needs fleshing out. Will require the database to handle the links between different parts of production chain. E.g each part of chain has a parent/child id that links to previous part

/lz/data/ - real system data

/lz/simulation/ - LUXSim/BACCARAT/DER Output
E.g /BACCARAT-{version}-geant4.{version}/DER-{version}/{macro_name}
(Do we even need the nested directories if information is available in database?)

/lz/lzap/ - TDRAnalysis/LZap Output*
(How do we identify rqs from data vs simulation? Through the database? )
E.g /LZap-{version}/Physics-{version}/{macro_name}

/lz/test/ - temp space for test jobs/processing

The following is an email extract from Elena:

I have a question. LZ people plan to change some parameters in macros.
I know that you use a tag version of TDRAnalysis to choose a macro to run.

Is it possible to change some parameters in macro on fly?
I think it can be done in a similar mode as it is done for beamOn events and Seed.

I don't know at the moment which parameters will be changed.

Hi,

At the last review, we were asked whether it was possible to set relative job priorities so that a normal user couldn't accidentally swamp out important production with their own jobs.

DIRAC JDL (and other interfaces) has an option to set a Priority. The field is literally just called "Priority" and takes an integer in the range 0..10, it defaults to 1 if unset. Larger numbers are higher priorities.

My suggestion would be to add a field to the request page which passes this value through, defaulting to 3 or something like that. That way particularly important production (MDC2?) can be run with a higher value. (I guess the exact behaviour should be up to LZ people).

Regards,
Simon

delimit the macro name and seed with an underscore or hyphen

Hi Alex,

Can you please add the "-ddd" flag(s) to the dirac-dms-add-file commands at the end of the script and also do an ls -l *.root just before them so that we can debug any future upload problems? (This is also discussed in a recent e-mail).

Regards,
Simon

make the output paths as follows:

SIM: /lz/data/${app}_release-${app_ver}_geant${g4_version}/$(basename $MACRO_FILE _parametric.mac)

REDUCTION: /lz/data/${app}_release-${app_ver}_geant${g4_version}/reduced_v${reduction_version}/$(basename $MACRO_FILE _parametric.mac)

e.g.
/lz/data/BACCARAT_release-1.1.0_geant4.9.5.p02/reduced_v4.1.1/lz_scintillator_U_an_early_neutron

This will likely have to be done in two phases:

• Use the format above with the /lz/user/l/lzproduser.grid.hep.ph.ic.ac.uk root for testing

• When ready migrate the root to /lz/data

Appears to be sorting by month instead of day

Currently macro files are pulled from the TDRAnalysis master branch, and no user-defined macros can be run. This change would give users the ability to design their own macro through drop-downs on the interface or upload/copy-paste their own macro file. The latter is probably more flexible and could be extended to running not just background simulations but also analysis scripts.

inserts don't need a query

tags can represent for e.g. MDC1 etc.

Two steps are needed for this issue, as below:

• Store emails in user db
• Add gravitar image based on stored email

Hi Alex,

They would like to know the specification of the RESTful interface that would make the job details available to the USDC... I can talk to you about this more on Thursday, but it would be good to get a draft of this ready for the last week of the month.

Regards,
Simon

requests API changed in python 2.7 to no longer allow separate cert/key args but rather an SSL context. This change will need to be made along the same lines as I did for Dirac ic-hep/GridPPDIRAC#38

time delay between "submitting request 1" and "submitting parametricjob 1"

Seems that this doesn't work for macros with multiple jobs

this will allow us to have better isolation for the different steps of the job

This may allow easy replacement of the scripts directory content. It may also allow for easy plugin management.

E.g searching 'tpc' does not match any macro

Requests with multiple macros selected are not being adding to the requests table

see http://docs.cherrypy.org/en/latest/basics.html#logging

specifically http://docs.cherrypy.org/en/latest/basics.html#play-along-with-your-other-loggers

Add a dropdown selection of site to run at to the new requests page. options should be any or IC

When resubmitting, check status goes to submitted not requested.

Otherwise if all but one job succeeds it looks depressing that the job is in state failed.