EASAPs generated with a focus on the user will have a higher likelihood for success. With this idea in mind, an author will most likely need to request data and information from users in an EASAP in a different form than what is required by the underlying software applications. The task is then to be able to convert the data supplied through user inputs into a form that is compatible with the inputs for the software applications. The Data Processing objects are available for you to complete the necessary manipulation of user input data. The remainder of this section on manipulating user inputs will be dedicated to providing examples of how the various data processing objects can be applied to the manipulation of user input data.
This section contains a few examples of typical scenarios in which you will need to manipulate user inputs. In these examples, you will see how the DATA PROCESSING Child objects can be put to use to achieve the desired data manipulation.
It is very likely that an EASAP may be analyzing something made out of some sort of material, and subsequently, software applications used in the analysis will need to have the material properties specified. Many software applications can pull this information from an existing database knowing only a material name, but many times software applications expect to receive the individual material properties as input.
From the users’ perspective, authors should avoid asking them for individual material properties and ask only for the material name. The author should then take on the responsibility for ‘mapping’ the material choice into the appropriate material property values. This example is a continuation of the example found in Material Property Database Example in which data extracted from a materials database file has been used to populate a CHOICE LIST as shown below:
The goal here is to determine the appropriate value for the Modulus of Elasticity and Poisson ratio for the material selected by the user. The steps for accomplishing this type of data manipulation are as follows:
Use the values of the two MAP's as direct input into the template batch file for the structural analysis software.
To keep input file sizes smaller and to simplify reading of inputs, many software applications make use of ‘flags’ within their input files. Flags are typically integer numbers that represent a certain setting e.g. 1 for the first possible setting value, 2 for the second setting value, etc. Here is another instance where users of an EASAP should not be asked to supply exactly what the underlying software requires. Instead, a more descriptive, literal set of choices should be provided to the user, and again the author should then map the choices to the appropriate flags expected by the software applications. For this example, let’s say 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. This discretization of a whole into a sum of smaller 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 analysis software applications, certain assumptions must be specified up front about the problem to be analyzed in order for the application to produce sensible results. A common situation that results in assumptions being made is when there are multiple ‘regimes’ governing the mathematics or physics of a problem. Examples of these regimes are for instance in structural analysis, elastic vs. plastic deformation, and in fluid flow analysis, laminar vs. turbulent flow or incompressible vs. compressible flow. Typically, software applications need to have a single regime specified at the outset of the analysis in the input files.
Following the common theme of not exposing the needs of the underlying software applications to the user, Authors should avoid asking the user to specify a regime for the analysis performed by an EASAP. There are two ways to avoid the regime question:
Pick a single regime that the EASAP will operate within, and then design the data entry objects and any bounds checking on these objects such that user’s inputs can only specify a problem within the chosen regime.
Determine the regime to be analyzed based on user inputs and vary the regime specification in the template batch files accordingly.
The example of regime selection to be provided below uses the second method, in which the regime is determined based on user inputs. In this example, the problem to be analyzed involves fluid flow in a pipe, and the regime selection is between laminar or turbulent flow. The regime will be determined from the user inputs of pipe diameter, fluid type, and volumetric flow rate. The procedure for the required data manipulation is as follows:
Note: An alternative to performing steps 10 and 11 in Example 4 would be to have two separate input files created, one set up for laminar flow and the other set up for turbulent flow. Then, all you would need to do is use the ‘Run if:’ parameter in the separate PROCESS's.