One of the most requested features for Rappture is a ''service'', a short calculation which runs independently of the '''Simulate''' button. A service could be an ''input service'', which runs automatically in response to user input, before '''Simulate''' is clicked, or an ''output service'', which runs as the user analyzes results of the main simulation, launched when the user clicks '''Simulate'''. == Input service example: MaterialDB == As an example, consider the following tool: [[BR]] [[Image(pic1.png)]] [[BR]] This tool needs 3 inputs, a lattice constant, a dielectric constant, and a band gap, which are properties of the material chosen in the selector at the top. Using the current capabilities of Rappture, the user would need to input each of the 3 values separately (obviating the need for the Material selector). The MaterialDB (an entirely separate project) calculates these material properties (and many others) from functional expressions. For example, the dielectric constant for !GaAs is {{{ 12.40*(1.0+1.20E-4*T) }}} where T is the temperature. The details of the MaterialDB are not relevant to this proposal, except to say that by using it material parameters can be calculated on the fly. Running MaterialDB as an ''input service'' then, Rappture could populate the lattice constant, dielectric constant, and band gap inputs of the tool above based solely on the value of the Material selector. The core idea of this proposal is a method of connecting the input and output of tools with Rappture interfaces; to that end, we also need a Rappture GUI for the MaterialDB, like the following: [[BR]] [[Image(pic2.png)]] [[BR]] This tool takes a material name and parameter name and returns the requested material parameter from the MaterialDB. The tool.xml file for this tool is very simple. {{{ MaterialDB Service Rappture service interface to the Purdue MaterialDB tclsh @tool/matdb_service.tcl @driver wizard 30x1 Enter material name here 30x1 Enter parameter name here Value returned from MaterialDB }}} Now we have two Rappture tools, the top level tool which needs material parameters and the MaterialDB tool which provides the parameters. The following tool.xml for the top level tool illustrates some ideas about how to describe calling the MaterialDB tool as an ''input service''. {{{ Material Parameter Lookup Quick reference for material parameters ruby @tool/matref.rb @driver wizard Choose a semiconductor material GaAs select input.choice(material).current input.string(material_name).current PhysChem:a_lattice input.string(parameter).current output.string(result).current input.number(lattice_constant).current input.choice(material).current input.string(material_name).current PhysChem:epsilon_dc input.string(parameter).current output.string(result).current input.number(dielectric_constant).current input.choice(material).current input.string(material_name).current BandEdge:C_Gamma:Eg input.string(parameter).current output.string(result).current input.number(band_gap).current Length of conventional unit cell edge, in Angstroms A 1.0 Relative permittivity of a material (dimensionless) 1.0 Band gap at the gamma point (eV) eV 1.0 }}} [[BR]] The tag specifies which GUI actions launch the ''input service''. The tags delimit a specific, automatic invocation of the MaterialDB tool; each time the ''input service'' runs, it invokes the MaterialDB service once for each tag. The tags describe the connections between GUI elements in the two tools. In some cases, the value of a Rappture GUI element in one tool is mapped to a Rappture GUI element in another tool (the GUI element in the second tool takes the current value of the GUI element in the first tool). In other cases, a GUI element in the second tool may require a literal value, like {{{ BandEdge:C_Gamma:Eg }}} in the syntax of the MaterialDB. === Issues === * Multiple tags per service invocation vs. a single call * Having multiple tags adds complexity to the tool.xml which invokes the ''service''; the ''service'' tool Rappture interface could be customized to take only the material name and calculate the specific parameters (lattice constant, dielectric constant, and band gap in this example) in one calculation. * The tradeoff is the cost of changing the call to the ''service'' tool (e.g. requesting a fourth parameter, such as effective mass), which would involve changes to both the top level tool.xml and the ''service'' tool. * The proposal above does not distinguish between Rappture GUI element paths (e.g. input.number(band_gap).current) and literal strings (e.g. the BandEdge:C_Gamma:Eg above). Both could be sent to or received from the ''service'' tool. * Conversion: mapping Rappture GUI elements between two tools would require checking the type of each element to prevent nonsensical conversions (e.g. string to sequence) but allow sensible conversions (e.g. number to string).