Incorporating a Module into the FRAMEwork System (FRAMES)


Title Page
Legal Notice
Table of Contents
Introduction
Example
STEP 1
STEP 2
STEP 3
STEP 4
STEP 5
APPENDIX A
APPENDIX B
APPENDIX C
APPENDIX D
 

Step 3: Describing the Invocation Model

One of the more powerful features of the FRAMES 2.0 system is that you no longer are required to provide a user interface for your module. In FRAMES 1.x you not only needed to deliver a wrapped module that matched the specifications of the system, you also needed to provide an executable that would get all input from the user and store it in the module input dataset. This was found to be an additional effort that many module developers did not want to take on. So in FRAMES 2.0 utlizes a General Module User Interface (GMUI) through the Data Client Editor (DCE). The DCE is also used to retrieve data from disparate databases. In both roles, it allows the user to view and edit datasets.

If you choose the DCE as your user interface, you should be able to populate input and run your model. Note, however, that the rules for completeness in the DCE are very general. So if there are interesting interdependencies between parameters that must be ensured, you will want to include a custom user interface. Currently the DCE enforces that scalar values must be populated, vectors can be empty, and arrays with indices must have the same number of elements as the indices. In general the DCE checks that all the values are populated in accordance with their indices.

All FRAMES 2.0 modules are passed three arguments on the command-line. These arguments tell the module which invocation (because there could be many) the module is supposed to process, what simulation files the invocation is part of, and where the files are to be located. The model passes this information into the OpenIO function. This function gets you connected to the FRAMES 2.0 IO system. You can think of this as the model registering itself with the IO system as a consumer/producer of information. Unfortunately, the method for getting the command-line arguments is not standardized among languages. The following example shows how to get the command line arguments in a Lahey F95 compiler and the final call to OpenIO:

   call getCL(commandline)   ! get the commandline handed the program
   READ(commandline,*) path,simulation,moduleId
   WRITE(*,*)TRIM(Path)," ",TRIM(Simulation)," ",TRIM(moduleid)
   READ(*,*)ierr
 pid=OpenIO(path,simulation,moduleId)

Check that the program id (pid) you get back from the OpenIO function is positive. A negative pid indicates that the FRAMES 2.0 system could not register the model as a consumer/producer. The pid is used in all subsequent calls to the API and can be thought of as a way to state who is making changes or reading datasets.

If your model needs additional arguments passed to it, you can also do this in FRAMES. The additional arguments are passed before the path, simulation, and module name. So if an additional argument of "/fast" was needed by your module when it is invoked, the arguments would be something like the following:

yourModule.exe /fast "c:\program files\framesv2" mytestsim.sim mymod

The quotes around the path are needed because the name of the directory "program files" has a space in it; sometimes such naming conventions cause problems between different versions of MS-Windows. There is no limit to the number of additional arguments passed to your module (other than a MS-Windows limit), but your module needs to find the path, simulation, and module name correctly.

Step 1: Add Units and Measures
Step 2: Define model inputs and boundary conditions
Step 4: Provide a description of the model
Step 5: Categorize the model

Battelle Logo
Home | Security and Privacy | Contact Us