“Design for Usability”
Before an EASAP may begin processing, a User will need to enter data as input.
Input fields to an EASAP should well organized, easy to understand, and intuitive.
An Author should use DATA PROCESSING objects to modify User input into a format required by the underlying software.
Consider an EASAP which runs a structural analysis which depends on the material properties of type of material being used.
We would like to be able to allow a User to select a material type and have each property of that material substituted where needed.
This example is a continuation of the example found in Material Property Database Example where a CHOICE LIST is populated from a file containing several types of material's properties, below.
Here we want to substitue a material's 'Modulus of Elasticity' and 'Poisson ratio' once a material name is selected by a User.
Use the values of the two MAP's as direct input into the template batch file for the structural analysis software.
Integer value flags are used to designate various states of an analytic model. We want to insulate a User from needing to know the actual flag values and instead let them choose among several text descriptions.
In our example from the Advanced Batch Tutorial, a structural analysis code needs to have the support conditions specified for a loading analysis of a beam or plate. The three possible conditions are ‘free’, ‘pinned’ or ‘fixed’, but the code uses flags to represent these settings in its input file. Namely, these flags are: 0 for free, 1 for pinned, and 2 for fixed. The steps for accomplishing the necessary data manipulation are as follows:
Any software applications that make use of finite difference, finite element, finite volume or similar numerical methods will need to somehow divide the geometry of the object or area being analyzed into smaller, discrete pieces. Making a whole into a sum of smaller discrete pieces is also known as gridding or meshing. These types of software applications will require inputs defining how the meshing or gridding process should take place.
In general, authors should avoid requesting gridding or meshing specific inputs from users. One of the benefits of an EASAP should be the capturing of best practices, and EASAP.
Authors are expected to be expert users of the underlying software applications. Therefore, where possible, authors should make the determination of how the meshing of a particular problem should be performed. Users should only be asked for geometric information and maybe in addition an indication of their accuracy and turn around time expectations. From this information, an author can then determine the settings for the meshing performed in the underlying software applications.
For this example, we’ll look at the analysis of a flat rectangular plate. The analysis software expects two inputs per side of the rectangle to govern the meshing process:
It does not expect the full dimension of the side. However, the full dimensions of the rectangle are exactly what the user should be asked to supply. The steps for accomplishing the necessary data manipulation are as follows:
Often in an analysis application User input values will specify a physics model.
In structural analysis stress will cause either elastic or plastic deformation. In fluid mechanics flow may be laminar or turbulent, a fluid itself may be compressible or in-compressible.
We want the regime selection (ie. the underlying physics model) to automatically derive from the values the User has entered.
In this example we demonstrate how input GUI objects, COMPUTE, and MAP may combine to create an EASAP that uses the correct regime, either laminar or turbulent for fluid flow in a pipe.
As an alternative to steps 10 and 11 two input files created, one laminar the other turbulent; use Run If: in separate PROCESS's.