Automatic Validation Package from the Web

• Description: A web site is being developed that will allow a user to upload their model files and "stock" version files. It will run "sanity" tests on them and allow the user to run various processes on them and compare between versions and between MEG's. It will be much easier to use than the Mathematica validations we have been running. Also, the user will not have to install all the MEG's. That will be taken care of by the web validation maintainers. In the first version, I envision it being useful to us (FR developers). In a later version (next year), I envision it being ready for the public and possibly part of a "model database".
• Names: Neil, Claude, Benj, Christian.
• Status: Code necessary for developers essentially done.
• Done:
  • Full FR model can be uploaded.
    • One subtelty is that all model files have to be loaded directly by LoadModel. They can't load each other.
    • Another subtelty is that if the model is implemented in Feynman gauge, it must be turned on by default.
    • Unfold must be applied appropriately.
  • Restriction files and (LHA) parameter files can be uploaded.
  • User inputs the name of the Lagrangian used for their model. Lagrangian terms can be put in curly brackets if desired (as in {LGauge,LFermion,...}).
  • User inputs one 2->2 process which will be used to test that the resulting code can be compiled.
  • User can choose current or development FR. Currently, only development works. "Current" ready for next release.
  • User chooses whether 4-scalar vertices should be calculated for their model.
  • Site creates dir for model, stores model files there in tar.gz format.
  • Site creates entries in database for model.
  • Site starts condor jobs to:
    • Load model files
    • Load restriction files.
    • Load parameter files.
  • When these tests are done, the user can choose next step among: Choose restriction-parameter combinations, upload stock models, and create validations.
  • Restriction file - parameter file combinations:
    • Since the model could have many restriction files and many parameter files, it does not seem reasonable to automatically check every combination.
    • Also some models have default values and other do not.
      • When the model did not have default values, it previously crashed. This is another reason for this.
    • Some combinations may not be intended.
    • The user now chooses which combinations they would like to validate.
    • User can choose none for each which means to use the default values in the model files.
    • When a restriction-parameter combination is chosen, the following happen:
      • The FeynRules interfaces run on it.
      • If the FeynRules interfaces succeed, then the MEG runs on the resulting code.
• Stock Models:
  • User can choose "stock" models.
  • Precompiled models that ship with the MEG can be chosen from drop down menu.
  • User can upload their own "stock" model, but this is harder and only seems to work with CalcHEP.
  • User must also upload "particle translation" file.
  • User can upload 1 or more parameter files.
  • Site tests that particle translation file and parameter files work and that the test process compiles.
  • If tests passed, then this model can be used in validations.
• Validations:
  • Once a restriction-parameter combination is chosen, a validation using it can be created.
  • The first step is to generate the processes using a set of restrictions on the particle content in the processes.
    • If no restrictions are chosen, then _all_ 2->2 processes are generated.
    • User can restrict to certain kinds of fields (fermions, vectors,...)
    • User can restrict on indices and charges.
    • All 2->2 processes that meet the restrictions are generated.
  • They can choose the MEG they want to test (among the ones that pass the previous tests).
  • User can choose which "stock" models to run (and which parameter files for them.)
  • The processes are run on Condor.
    • Currently 6 parallel nodes. Seems pretty fast.
    • Each job runs 10 processes.
    • Adds 30 jobs to the queue at a time. This allows multiple users and validations to be run at the same time and make progress at the same time.
    • User can refresh their browser to see the progress. Each process and MEG that is finished will show up as they are finished.
  • User can rerun processes choosing new MEG's and new stock models if they like.
  • User can add new MEG's and remove some and just finish the parts that are not done yet.
  • Validation tables are split into groups to improve browser response.
  • Differences are histogrammed and the histogram is automatically updated and shown.
• User can create multiple validations.
• Multiple validations can be run concurrently. Condor handles this.
• Multiple users can run at the same time. Condor handles this.
• Users can delete models. (But only when no condor jobs are running for this model.)
• Users can delete validations. (But only when this validation is not being run.)
• Users can delete stock models. (But only when not in use.)
• Security:
  • All user code is run on condor jobs and no where else.
  • All mysql operations are run on head node as POST scripts and are not mingled with user code. This allows all network connections to be closed on condor jobs (except those initiated by condor).
  • Home dir has been unmounted from condor jobs. So, user code does not have access to any dir other than in their virtual env.
  • Users do not control condor. They can only use web form to start jobs and see the outcome.
• Some other properties:
  • Test whether a Mathematica license is available. If not, wait and try again.
  • Users can stop condor jobs.

• To-do (soon):
  • Get FR-SH working. This shouldn't be difficult. The scaffolding is there. Benj said he might be willing to do this?
  • Get FR-MG5 working. Olivier?
• To-do (not gauranteed for this summer but hopefully by summer of 2011):
  • Versions of all software used (partly done).
  • Add links moving around model database. Partially done.
  • Add history (if model changes, then keep the old model with versioning. Do the same for validations, etc..)
  • Finish other pages of model database web site. Login, etc...
  • Allow the user to modify part of their model (currently have to delete model and start over).
    • Intelligently only run pieces that are modified.
  • Support phase space tests.
  • Support 1->2 decay tests.
  • Support 1->3 decay tests.
  • Support 2->3 processes?
  • Support scans over energy for individual procs.
  • Support other model info of interest. Authors, urls, ...
  • Connect username and password with wiki username and password?
  • Set up other Condor nodes at other institutions to run jobs.
    • LLN would be the main node which would host the website and submit the jobs to Condor.
    • Condor would run jobs on one of the nodes which would exist at:
    • LLN
    • Maybe UW?
    • Maybe Strasbourg?
    • This seems harder than I hoped.
• Security:
  • Generate strong random password for user.
  • Keep the last login date + ip of the user, date user creation, valid email, who created this user...
  • https for user password.
  • Could be connected with FeynRules wiki. User could register and log in to FeynRules wiki. Invisible variable used for whether they have permission to use web validation / model database.
  • Add find /var/tmp/. /tmp/. -user $USER | xargs rm -rf to scripts?
  • Test that the web forms do not allow the user to perform any nasty actions (no user commands should be performed.)
  • Test that nothing can be written outside of condor job dir.
  • Test that condor job cannot do any network connections _except_ certain database updates.
  • Control time, memory and disk space available to condor jobs (admin side).
  • Only allow transfer back of certain files. Don't let user overwrite important files... This is done for the cs computations but not for the Mathematica sessions. The reason is that if it fails to produce model files and it is set to explicitly transfer the model files back then Condor will restart the job. A work around is to create the empty directory at the beginning. Then, it will always have something to transfer back even if empty.
  • deactivate the possibility to run code when turbogears crash
  • avoid to generate process if no ME are valid or if the code is not valid
  • supress files which fails to pass tests
• Add admin pages for...
• Create script which installs software (CalcHEP, etc.) to the nodes. Automize.
• Split long tables up into smaller tables (say every 50 lines) to improve the speed of rendering.
• Give the user more information.
  • Create links to the model files.
  • Automatically generate the LaTeX output and link it.
• Validations:
  • Store MC errors and use in chi^{2 analysis.}
  • Allow user to see MC error when they hover over cs.
  • Histogram chi^2.
  • Allow user to see FR and MC output.
  • Only show ~100 procs at a time with arrows that allow user to see other procs.
  • Allow user to order by another column?
• Create collaborator entries that allow others to see model.
• Create "public" that determines whether a model is public.
• Fix public view.
• Popup when delete "Are you sure you want to delete...?"
• When validation job finishes, update differences (and chi^{2) so that it does not need to be redone every time the page is loaded.}
• etc, etc, etc....