(WP 1.2)
Content:
Use Case: Model Performance analysis
Use Case: Model adaptation for grid environment
Use Case: Simulation procedure
Use Case: Simulation preparation
Use Case: Simulation execution
Use Case: Visualization of simulation results
Use Case: Input data identification and preparation
Use Case: Cascade of Simulations
|
Identifier |
ModelDebugging |
|
Goals in Context |
Localize bugs in model code |
|
Actors |
Developer |
|
Triggers |
Needs to consult user who submitted bug report |
|
Included Use Cases |
Grid login, job submission, job cancel use cases. Grid application development tools use cases. |
|
Specialised Use Cases |
|
|
Pre-conditions |
The developer has a valid account on User Interface grid component and access to grid application development tools (application monitor, MPI code verification tools). Development tools should support programming language of model. The developer can submit jobs directly to grid resources available for development. |
|
Post-conditions |
Developer can update model in model repository. |
|
Basic Flow |
1. Developer performs changes in the model source code that are required for use of tools needed for localization of particular type of bug 2. Developer starts a debugging tool 3. Developer starts the application and performs necessary steps for bug localization 4. Developer depending on success of bug localization: a. eliminates bug b. continues from 1. 5. Developer updates model in model repository
|
|
Devious Flow(s) |
|
|
Importance and Frequency |
High importance. Frequency depends on the continuity of model development and frequency of occurrence of bugs. If the development of model continues, new version may contain new bugs that will affect Grid version. |
|
Additional Requirements |
|
|
Identifier |
ModelPerfAnalysis |
|
Goals in Context |
Localize performance bottlenecks of model |
|
Actors |
Developer |
|
Triggers |
|
|
Included Use Cases |
Grid login, job submission. Grid application performance analysis tools use cases. |
|
Specialised Use Cases |
|
|
Pre-conditions |
The developer has a valid account on User Interface grid component and access to grid application performance analysis tools (grid enabled performance analyser, application monitor, MPI profiling tools). Development tools should support programming language of model. |
|
Post-conditions |
Developer can update model in model repository. |
|
Basic Flow |
1. Developer performs changes in the model source code that are required for use of tools needed for performance analysis and/or MPI profiling 2. Developer starts a performance analysis tool 3. Developer starts the application and performs necessary steps for localization of performance bottlenecks
|
|
Devious Flow(s) |
|
|
Importance and Frequency |
High importance. Frequency depends on the continuity of model development. |
|
Additional Requirements |
|
|
Identifier |
ModelGridAdaptation |
|
Goals in Context |
Prepare model code for running in the Grid environment. |
|
Actors |
Developer |
|
Triggers |
|
|
Included Use Cases |
Grid login, job submission, debugging, performance analysis |
|
Specialised Use Cases |
|
|
Pre-conditions |
The developer has a valid account on User Interface grid component and access to grid application development tools. Development tools should support programming language of model. |
|
Post-conditions |
Developer can store and update model in model repository. |
|
Basic Flow |
1. If the model is not available for computing platforms present in VO, developer ports the model on selected platform. 2. Developer performs performance analysis of model and identifies most time consuming parts 3. Developer prepares Grid version of the model. 4. Developer tests the model in Grid environment and debugs it if necessary 5. Developer performs performance analysis of model in Grid environment and identifies performance bottlenecks 6. If possible, developer solves performance problems and continues from 4. 7. Based on performance analysis, developer prepares the list of requirements for the model 8. Developer stores model in model repository. |
|
Devious Flow(s) |
|
|
Importance and Frequency |
High importance. Frequency depends on the continuity of model development. |
|
Additional Requirements |
|
|
Identifier |
SimulProcedure |
|
Goals in Context |
Performing a simulation |
|
Actors |
Operator, Expert |
|
Triggers |
Need to run a simulation |
|
Included Use Cases |
Simulation preparation, simulation executions, visualizations of simulation results |
|
Specialised Use Cases |
|
|
Pre-conditions |
Data set needed for simulation are ready The expert have adequate knowledge about models |
|
Post-conditions |
All files needed (scripts files, definition files, input files) for submit job to Grid |
|
Basic Flow |
1. Simulation preparation (See simulation preparation use case) 2. Simulation execution (See simulation execution use case) 3. Visualization of simulation results (See visualization use case) 4. Experts check if the simulations results are valid based on their knowledge and experiences (non-Grid) 5. Storing simulations results to permanent storage if needed (Storage Elements, Grid FTP) |
|
Devious Flow(s) |
|
|
Importance and Frequency |
Very important and high frequency |
|
Additional Requirements |
|
|
Identifier |
SimulPreparation |
|
Goals in Context |
Preparing necessary files for submitting simulations to Grid |
|
Actors |
Operator, Expert |
|
Triggers |
Need to run a simulation |
|
Included Use Cases |
|
|
Specialised Use Cases |
|
|
Pre-conditions |
Data set needed for simulation are ready The expert have adequate knowledge about models |
|
Post-conditions |
All files needed (scripts files, definition files, input files) for submit job to Grid |
|
Basic Flow |
1. Actor choose model going to used via portal using application plug-in (App Portal, App Container, App Plug-in) 2. Actor choose input data for the model via portal using application plug-in (App Portal, App Container, App Plug-in) 3. Actor may set some simulation parameters via portal using application plug-in (App Portal, App Container, App Plug-in) 4. The application plug-in generates scripts for submitting job (App Plug-in) 5. The application plug-in does pre-processing input files if needed (App Plug-in) 6. The application plug-in generate definitions files for models (model dependent) (App Plug-in) |
|
Devious Flow(s) |
Input data are not found |
|
Importance and Frequency |
Very important and high frequency |
|
Additional Requirements |
|
|
Identifier |
SimulExecution |
|
Goals in Context |
Executing simulation in Grid |
|
Actors |
Operator, Expert |
|
Triggers |
Need to run a simulation |
|
Included Use Cases |
|
|
Specialised Use Cases |
|
|
Pre-conditions |
Simulation definitions files are generated |
|
Post-conditions |
Output data from simulations |
|
Basic Flow |
1. Actor submit job to Grid using scripts from simulation definitions (Application Portal Sever, Roaming Access Sever, Scheduling Agent) 2. The RMS should return expected response time, so actor can cancel the job if they have to wait too long (Scheduling Agent) 3. The scripts are executed a. Check if the model executable code is ready on target CE, if not, copy the code to the CE. (Replica Manager, Replica Catalogue, Grid FTP) b. The input data are copied to the CE (Replica Manager, Replica Catalogue, Grid FTP) c. Models are executed (using mpi run) (MPI) d. When the simulation finishes, the output data are copied to storage (Replica Manager, Replica Catalogue, Grid FTP) 4. During simulations, the actor can monitor status of simulations (Scheduling Agent, Job Monitoring) |
|
Devious Flow(s) |
Input data are not found |
|
Importance and Frequency |
Very important and high frequency |
|
Additional Requirements |
|
|
Identifier |
SimulVisualization |
|
Goals in Context |
Show simulation results in visual form |
|
Actors |
Operator, Expert, Consumer |
|
Triggers |
Actor need to see the results of simulation in visual form |
|
Included Use Cases |
|
|
Specialised Use Cases |
|
|
Pre-conditions |
Output data of simulation are created |
|
Post-conditions |
Images, scheme, diagram shown in portal |
|
Basic Flow |
1. Actor define parameters of visualization tools (sizes of images, locations, zoom levels, time length, …) via portal using app plug-in (App Portal, App Container, App Plug-in) 2. The visualization tools generate visual data (images, diagrams, video sequences) (App Portal, App Container, App Plug-in) 3. The data are shown in portal (App Portal, App Container, App Plug-in) 4. The actor can change the parameters by repeat step 1 |
|
Devious Flow(s) |
Output data from simulations are not found |
|
Importance and Frequency |
Very important and high frequency |
|
Additional Requirements |
|
|
Identifier |
SimulDataPreparation |
|
Goals in Context |
Preparation of data for model |
|
Actors |
Expert |
|
Triggers |
|
|
Included Use Cases |
|
|
Specialised Use Cases |
|
|
Pre-conditions |
Expert can access data catalogue |
|
Post-conditions |
|
|
Basic Flow |
· Expert identifies data needed for model (non-Grid) · Expert searches catalogue for available data (App Portal, Replica Manager, Replica Catalogue) · Expert prepares missing input data (non-Grid) · Expert upload the created input data (App Portal, Replica Manager, Replica Catalogue, Grid FTP) |
|
Devious Flow(s) |
|
|
Importance and Frequency |
|
|
Additional Requirements |
To this file new measured data will be appended and never removed. Historical values can be re-used when needed. |
|
Identifier |
ModelCalibration |
|
Goals in Context |
To calibrate model using historical data |
|
Actors |
Expert |
|
Triggers |
Decision to calibrate model |
|
Included Use Cases |
Simulation process |
|
Specialised Use Cases |
|
|
Pre-conditions |
Calibration data prepared |
|
Post-conditions |
Model parameters set |
|
Basic Flow |
1. Preparation of calibration scenario – first guess of calibrated parameters (non-Grid) 2. Make changes in model parameters (See Simulation preparation use case) 3. Simulation run (See Simulation execution use case) 4. Compare result with desired values (non-Grid) 5. If not satisfied, go back to 2 6. Save parameters (App plug-in) |
|
Devious Flow(s) |
|
|
Importance and Frequency |
|
|
Additional Requirements |
|
|
Identifier |
ModelValidation |
|
Goals in Context |
Test correctness of model on various data |
|
Actors |
Expert |
|
Triggers |
|
|
Included Use Cases |
Simulation process |
|
Specialised Use Cases |
|
|
Pre-conditions |
Input data files prepared, model calibrated |
|
Post-conditions |
Model validated |
|
Basic Flow |
1. Run simulation with validation data (See simulation procedure use case) 2. Compare result with desired values (non-Grid) 3. If not satisfied, recalibrate or mark model as unusable (See model calibration use case) |
|
Devious Flow(s) |
|
|
Importance and Frequency |
Done after calibration. |
|
Additional Requirements |
|
|
Identifier |
SimulCascade |
|
Goals in Context |
Get new forecast for the pilot site – flood warning, alert etc. |
|
Actors |
Operator, Expert |
|
Triggers |
Need to get new forecast. |
|
Included Use Cases |
Simulation procedure, Simulation preparation, Simulation execution, Visualizations of simulation results |
|
Specialised Use Cases |
|
|
Pre-conditions |
Input data are ready |
|
Post-conditions |
New simulation results are available |
|
Basic Flow |
1. Meteorological simulation preparation – choose boundary conditions (for which time/date) and model configuration file, set command line parameters (See simulation preparation use case) 2. Hydrological simulation preparation (See simulation preparation use case). Adjusting post-processing of meteo-output - partial meteo-results (‘hourly files’, 48 pieces) can be immediately (before whole meteo-simualtion finishes) post-processed, visualized and hydrological simulations can be started (non-Grid scripts –> see simulation execution use case, visualization of simulation results use case) 3. Meteorological simulation execution (See simulation execution use case) In case of scripts are waiting for meteo-results, on-line visualization and/or automatic hydrology simulation can start 4. Experts check if the simulations (meteo- and hydro-) results are valid based on their knowledge and experiences (non-Grid) 5. Expert chooses if last simulation in cascade (hydraulic-2D) is needed (non-Grid), if yes: a. Hydraulic simulation procedure (See simulation procedure use case) |
|
Devious Flow(s) |
File not found, … |
|
Importance and Frequency |
Very important. Frequency depends on probability of flood event occurrence. |
|
Additional Requirements |
|