Changes between Version 22 and Version 23 of WebValidation
- Timestamp:
- Nov 16, 2010, 11:05:48 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WebValidation
v22 v23 6 6 * ''Done'': 7 7 * Full FR model can be uploaded. 8 * Restriction files and (LHA) parameter files can be uploaded. 9 * 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,...}). 10 * User inputs one 2->2 process which will be used to test that the resulting code can be compiled. 8 11 * User can choose current or development FR. Currently, only development works. "Current" ready for next release. 12 * User chooses whether 4-scalar vertices should be calculated for their model. 9 13 * Site creates dir for model, stores model files there in tar.gz format. 10 14 * Site creates entries in database for model. … … 12 16 * Load model files 13 17 * Load restriction files. 14 * Run CH, FA, MG, SH, WO interfaces. 15 * Run CH & MG on resulting code. 16 * Each of these condor jobs relies on previous ones. If a necessary previous step fails, then the next job is not run. This is controlled by a "DAG" script. 17 * User can choose "stock" models. There are 2 choices: 18 * Load parameter files. 19 * When these tests are done, the user can choose next step among: Choose restriction-parameter combinations, upload stock models, and create validations. 20 * Restriction file - parameter file combinations: 21 * Since the model could have many restriction files and many parameter files, it does not seem reasonable to automatically check every combination. 22 * Some combinations may not be intended. 23 * The user now chooses which combinations they would like to validate. 24 * User can choose none for each which means to use the default values in the model files. 25 * When a restriction-parameter combination is chosen, the following happen: 26 * The FeynRules interfaces run on it. 27 * If the FeynRules interfaces succeed, then the MEG runs on the resulting code. 28 * Stock Models: 29 * User can choose "stock" models. 18 30 * Precompiled models that ship with the MEG can be chosen from drop down menu. 19 * User can upload their own "stock" model, but this is harder .31 * User can upload their own "stock" model, but this is harder and only seems to work with CalcHEP. 20 32 * User must also upload "particle translation" file. 21 33 * User can upload 1 or more parameter files. 22 * Site tests that particle translation file and parameter files work .34 * Site tests that particle translation file and parameter files work and that the test process compiles. 23 35 * If tests passed, then this model can be used in validations. 24 * If 1 or more MEG passes, the user is allowed to run 2->2 cs processes.25 * They can choose the MEG they want to test (among the ones that pass the previous tests).26 * User can choose "restrictions" on 2->2processes.36 * Validations: 37 * Once a restriction-parameter combination is chosen, a validation using it can be created. 38 * The first step is to generate the processes using a set of restrictions on the particle content in the processes. 27 39 * If no restrictions are chosen, then _all_ 2->2 processes are generated. 28 40 * User can restrict to certain kinds of fields (fermions, vectors,...) 29 41 * User can restrict on indices and charges. 30 * After processes are generated, user can run them. 31 * User can choose from restrictions and parameters. 32 * User can choose which MEGs to run. 42 * All 2->2 processes that meet the restrictions are generated. 43 * They can choose the MEG they want to test (among the ones that pass the previous tests). 33 44 * User can choose which "stock" models to run (and which parameter files for them.) 34 45 * The processes are run on Condor. 35 * Currently 4 parallel nodes. Seems pretty fast. 36 * Adds 10 jobs to the queue at a time. Each job has ~5 processes. This allows multiple users and validations to be run at the same time and make progress at the same time. 46 * Currently 6 parallel nodes. Seems pretty fast. 47 * Each job runs 10 processes. 48 * 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. 37 49 * User can refresh their browser to see the progress. Each process and MEG that is finished will show up as they are finished. 38 50 * User can rerun processes choosing new MEG's and new stock models if they like. 51 * User can add new MEG's and remove some and just finish the parts that are not done yet. 52 * Validation tables are split into groups to improve browser response. 53 * Differences are histogrammed and the histogram is automatically updated and shown. 39 54 * User can create multiple validations. 40 55 * Multiple validations can be run concurrently. Condor handles this. … … 42 57 * Users can delete models. (But only when no condor jobs are running for this model.) 43 58 * Users can delete validations. (But only when this validation is not being run.) 44 * Users can delete stock models. 59 * Users can delete stock models. (But only when not in use.) 45 60 * Security: 46 61 * All user code is run on condor jobs and no where else. … … 48 63 * Home dir has been unmounted from condor jobs. So, user code does not have access to any dir other than in their virtual env. 49 64 * Users do not control condor. They can only use web form to start jobs and see the outcome. 50 * ''To-do'' (for this summer): 51 * Get FR-SH working. This shouldn't be difficult. The scaffolding is there. 52 * Test whether a Mathematica license is available. If not, wait and try again. 65 * Some other properties: 66 * Test whether a Mathematica license is available. If not, wait and try again. 67 * Users can stop condor jobs. 68 * ''To-do'' (soon): 69 * Get FR-SH working. This shouldn't be difficult. The scaffolding is there. Benj said he might be willing to do this? 70 * Get FR-MG5 working. Olivier? 53 71 * ''To-do'' (not gauranteed for this summer but hopefully by summer of 2011): 54 72 * Versions of all software used (partly done). 55 * Add links moving around model database. 73 * Add links moving around model database. Partially done. 56 74 * Add history (if model changes, then keep the old model with versioning. Do the same for validations, etc..) 57 75 * Finish other pages of model database web site. Login, etc... 58 76 * Allow the user to modify part of their model (currently have to delete model and start over). 59 77 * Intelligently only run pieces that are modified. 60 * Allow user to stop running Condor jobs.61 78 * Support phase space tests. 62 79 * Support 1->2 decay tests. 63 80 * Support 1->3 decay tests. 64 81 * Support 2->3 processes? 82 * Support scans over energy for individual procs. 65 83 * Support other model info of interest. Authors, urls, ... 66 84 * Connect username and password with wiki username and password? … … 71 89 * Maybe UW? 72 90 * Maybe Strasbourg? 91 * This seems harder than I hoped. 73 92 * Security: 74 93 * Generate strong random password for user. … … 88 107 * Create script which installs software (CalcHEP, etc.) to the nodes. Automize. 89 108 * Split long tables up into smaller tables (say every 50 lines) to improve the speed of rendering. 109 * Give the user more information. 110 * Create links to the model files. 111 * Automatically generate the LaTeX output and link it. 112 * Validations: 113 * Store MC errors and use in chi^2 analysis. 114 * Allow user to see MC error when they hover over cs. 115 * Histogram chi^2. 116 * Allow user to see FR and MC output. 117 * Only show ~100 procs at a time with arrows that allow user to see other procs. 118 * Allow user to order by another column? 119 * Create collaborator entries that allow others to see model. 120 * Create "public" that determines whether a model is public. 121 * Fix public view. 122 * etc, etc, etc.... 90 123
