When running D2K headless, standard user interface modules that subclass
UIModule will not run. If such a module enables during a headless D2K
run, an error message will be displayed.
To circumvent this problem, wherever possible user interface modules
should subclass HeadlessUIModule rather than UIModule.
Even though a default implementation of the doit() method is
provided in this superclass, if a user interface can perform a
useful operation without a gui, it should provide the code to do
so in the doit() method.
When D2K encounters a HeadlessUIModule subclass during
headless itinerary execution, it will run that module in the same way
it runs any other computation module. D2K will schedule it to run
along with all the other modules, and will execute the doit()
method in turn.
For example, the ChooseAttributes module allows the user to select
which of the attributes in a tabular data set are to be the inputs
and outputs of a supervised learning algorithm. This module presents
a user interface like the one shown below:
Two lists are presented, each list containing each of the attribute names. The list on the left is used to select the input attributes, the list on the right is used to select the output attributes.
For this module, the inputs and outputs the user selects could be
saved in properties. Then when the itinerary is run in headless mode,
the list of input and output attributes last selected could be determined.
Such a doit() method might look like this:
public void doit () throws Exception {
Table table = (Table) this.pullInput (0);
// Map each column name to an index for the columnHashMap
colindices = new HashMap ();
for (int i = 0; i < table.getNumColumns(); i++) {
String label = table.getColumnLabel(i);
colindices.put (label, new Integer(i));
}
// Create the input feature index array.
Object[] selected = this.getSelectedInputs ();
int[] inputFeatures = new int[selected.length];
for (int i = 0; i < selected.length; i++) {
String s = (String) selected[i];
Integer ii = (Integer) colindices.get (s);
inputFeatures[i] = ii.intValue ();
}
// Create the output features array
selected = this.getSelectedOutputs ();
int[] outputFeatures = new int[selected.length];
for (int i = 0; i < selected.length; i++) {
String s = (String) selected[i];
Integer ii = (Integer) colindices.get (s);
outputFeatures[i] = ii.intValue ();
}
// Create the example table and push it.
ExampleTable et = table.toExampleTable();
et.setInputFeatures (inputFeatures);
et.setOutputFeatures (outputFeatures);
this.pushOutput(et, 0);
}
This method first adds the index of each attribute to a hashmap keyed on the attribute name. It is from this hashmap that we will get the indices of all the columns containing the inputs attributes and the output attributes. Obviously, it is necessary to save the names of the inputs and output attributes to pull this off. This is very easy, when the itinerary is run with a gui, and the user makes a selection from the dialog described above. The results of these selections is stored as a property of the module. This requires methods which adhere to the getter/setter design pattern like so:
Object[] selectedInputs;
public Object[] getSelectedInputs () {
return selectedInputs;
}
public void setSelectedInputs (Object[] nsi) {
selectedInputs = nsi;
}
Object[] selectedOutputs;
public Object[] getSelectedOutputs () {
return selectedOutputs;
}
public void setSelectedOutputs (Object[] nsi) {
selectedOutputs = nsi;
}
These properties do not show up in the property editor since they are not a primitive data type that the system knows how to edit. However, these properties are still saved when the itinerary is saved. The itinerary is run with a gui, the user makes the selections from the dialog, then the results are saved and are available to be used when the itinerary is run headless.
Here is an example batch file that runs the Apriori itinerary three times with different support values.
# !/bin/csh # the classpath includes dom4j which is used to parse XML, # antlr to parse the source codes and the jini stuff, log4j for logging. set CP=/Users/foobar/projects/modules3/core/lib/dom4j-full.jar:/Users/foobar/tmp/anto/antlr-2.7.1:/Users/foobar/projects/lib/jini-core.jar:/Users/foobar/projects/lib/jini-ext.jar:/Users/foobar/projects/lib/log4j-1.2.5.jar:classes # create the script file. echo "set 'Apriori' minimumSupport '35.0'" > script java -server -Xmx256M -Xms256M -cp $CP ncsa.d2k.batch.CommandLineD2K -load headless.itn -script script # create the script file. echo "set 'Apriori' minimumSupport '30.0'" > script java -server -Xmx256M -Xms256M -cp $CP ncsa.d2k.batch.CommandLineD2K -load headless.itn -script script # create the script file. echo "set 'Apriori' minimumSupport '25.0'" > script java -server -Xmx256M -Xms256M -cp $CP ncsa.d2k.batch.CommandLineD2K -load headless.itn -script script
In this batch file (Unix csh script), the Java classpath is first configured. For each run, a script file is generated by simply echoing the command that will change the support value property in the Apriori module. This command is described in the previous section. With this single command in the script file, D2K is run specifying the -nogui option to turn off the Toolkit GUI, the -load option including the itinerary to load, and the -script option that runs the generated script.
The minimumSupport property is changed to 35 for the first run, 30 for the second run, and 25 for the last run. None of these scripted modifications alter the saved itinerary. They only operate on the loaded itinerary.
Following is the output of the runs:
Setting minimumSupport in Apriori to 35.0 Apriori: Identified 131 frequent itemsets with 2 items that met the support criteria. Apriori: Identified 310 frequent itemsets with 3 items that met the support criteria. Apriori: Identified 379 frequent itemsets with 4 items that met the support criteria. Apriori: Identified 250 frequent itemsets with 5 items that met the support criteria. Apriori: Identified 84 frequent itemsets with 6 items that met the support criteria. Apriori: A total of 1154 frequent itemsets were found that met the specified Minimum Support of 35.0%. Apriori: Elapsed wallclock time was 6.331 seconds Compute Confidence: Beginning to compute confidence for frequent itemsets containing 2 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 3 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 4 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 5 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 6 attributes. Compute Confidence: A total of 59 rules were found that met the specified Minimum Confidence of 80.0%. Error: Can't run headless Can't run RuleAssocReport without a gui, it must subclass HeadlessUIModule. Compute Confidence: Elapsed Wallclock time was 0.704 Seconds Unused inputs in RuleAssocReport on input #0 Apriori: Total Elapsed Wallclock Time was 7.17 Seconds Agenda execution complete, elapsed time : 7184 Setting minimumSupport in Apriori to 30.0 Apriori: Identified 163 frequent itemsets with 2 items that met the support criteria. Apriori: Identified 455 frequent itemsets with 3 items that met the support criteria. Apriori: Identified 725 frequent itemsets with 4 items that met the support criteria. Apriori: Identified 712 frequent itemsets with 5 items that met the support criteria. Apriori: Identified 441 frequent itemsets with 6 items that met the support criteria. Apriori: A total of 2496 frequent itemsets were found that met the specified Minimum Support of 30.0%. Apriori: Elapsed wallclock time was 10.323 seconds Compute Confidence: Beginning to compute confidence for frequent itemsets containing 2 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 3 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 4 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 6 attributes. Compute Confidence: A total of 477 rules were found that met the specified Minimum Confidence of 80.0%. Error: Can't run headless Can't run RuleAssocReport without a gui, it must subclass HeadlessUIModule. Compute Confidence: Elapsed Wallclock time was 1.835 Seconds Unused inputs in RuleAssocReport on input #0 Apriori: Total Elapsed Wallclock Time was 12.182 Seconds Agenda execution complete, elapsed time : 12231 Setting minimumSupport in Apriori to 25.0 Apriori: Identified 241 frequent itemsets with 2 items that met the support criteria. Apriori: Identified 749 frequent itemsets with 3 items that met the support criteria. Apriori: Identified 1323 frequent itemsets with 4 items that met the support criteria. Apriori: Identified 1433 frequent itemsets with 5 items that met the support criteria. Apriori: Identified 1005 frequent itemsets with 6 items that met the support criteria. Apriori: Elapsed wallclock time was 19.583 seconds Compute Confidence: Beginning to compute confidence for frequent itemsets containing 2 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 3 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 4 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 5 attributes. Compute Confidence: Beginning to compute confidence for frequent itemsets containing 6 attributes. Compute Confidence: A total of 967 rules were found that met the specified Minimum Confidence of 80.0%. Error: Can't run headless Can't run RuleAssocReport without a gui, it must subclass HeadlessUIModule. Compute Confidence: Elapsed Wallclock time was 2.966 Seconds Unused inputs in RuleAssocReport on input #0 Apriori: Total Elapsed Wallclock Time was 22.689 Seconds Agenda execution complete, elapsed time : 22701
Notice that errors were generated. The itinerary that was run included a UIModule
that did not support headless execution. UIModules that do not subclass
HeadlessUIModule are ignored during itinerary execution. In this case, it
did not affect itinerary execution.
|