Search/Navigation:
Related:
SLAC/EPP/HPS Public
Jefferson Lab/Hall B/HPS Run Wiki
S30XL-LESA/LDMX
Before reading these instructions, you will want to read Installing HPS Java which explains how to build or get an HPS Java distribution jar file.
The distribution jar file contains all of the project's dependencies in a distribution that can be run standalone using the java command. The distribution will have "-bin" in the name.
This jar file should be found in your copy of HPS Java once you have built it locally using Maven.
cd hps-java; ls distribution/target/hps-distribution-[VERSION]-bin.jar
The version in subsequent commands will be left out for brevity, and because it will change depending on the version of the distribution you are using. Of course, when executing commands you need to use the path to an actual jar!
Any references to hps-distribution-bin.jar in command line syntax used on this page should actually be replaced by the path to the HPS Java distribution jar.
The distribution jar can be run in two basic ways. You can run a default main method using the -jar switch, or you can use -cp to supply a list of jars in the classpath and activate any class's main method.
Using the -jar switch from the command line will run the main from the class JobManager, which is specified inside a special manifest file in the distribution jar (in case you were wondering how that works).
java -jar ./distribution/target/hps-distribution-bin.jar [args]
Without any arguments, it will print the command line options and then exit.
The default main method can be used when you are processing LCIO files using XML steering configurations.
You can also run the main method from any class in the jar.
java -cp ./distribution/target/hps-distribution-bin.jar org.hps.evio.EvioToLcio [args]
If you get "class not found" errors, then either the path to the distribution jar is not correct. This error may also occur if the class you have specified doesn't exist or does not have a main method.
A class can only be accessed from the command line if it has a valid main method.
package org.example; public class MyClass { public static void main(String[] args) { System.out.println("hello main"); } }
To be directly accessible from the command line, a class must have the following features.
Assuming that MyClass was bundled inside the distribution (which it isn't because it is just a dummy example!), it could be run from the command line via its main method as follows.
java -cp ./distribution/target/hps-distribution-bin.jar org.example.MyClass arg1 arg2 [...]
Most classes that implement a command line interface will print out help when run with no options.
java -cp ./distribution/target/hps-distribution-bin.jar org.hps.evio.Evio2Lcio
If implemented by the author, then -h is also usually used to print out a help menu.
java -cp ./distribution/target/hps-distribution-bin.jar org.hps.evio.Evio2Lcio -h
Specific command line syntax is not standardized and will depend on what was implemented in that class by the author.
mvn test -Dtest=ClassNameOfTest
Integration tests are run from the integration-tests module directory with this syntax:
mvn verify -Dit.test=ClassNameOfTest
In both cases, the class should be provided without the package name.
More information about running integration tests can be found here.
The JobManager runs a series of Drivers defined in an lcsim xml file on input events from one or more LCIO files. The XML steering file may contain lists of input file tags, or they may be (more typically) supplied with command line arguments. The job manager's class is listed in the distribution jar's manifest file, making it the default program which will run when using the java -jar command on the distribution.
[1026 $] java -jar ./hps-java-trunk/distribution/target/hps-distribution-3.6-SNAPSHOT-bin.jar Feb 18, 2016 4:02:27 PM org.lcsim.job.JobControlManager printHelp INFO: java org.lcsim.job.JobControlManager [options] steeringFile.xml usage: -b,--batch Run in batch mode in which plots will not be shown. -D,--define <arg> Define a variable with form [name]=[value] -d,--detector <arg> user supplied detector name (careful!) -e,--event-print <arg> Event print interval -h,--help Print help and exit -i,--input-file <arg> Add an LCIO input file to process -n,--nevents <arg> Set the max number of events to process -p,--properties <arg> Load a properties file containing variable definitions -r,--resource Use a steering resource rather than a file -R,--run <arg> user supplied run number (careful!) -s,--skip <arg> Set the number of events to skip -w,--rewrite <arg> Rewrite the XML file with variables resolved -x,--dry-run Perform a dry run which does not process events
Switch | Description | Notes |
---|---|---|
-b | Activates batch mode plotting so plots will not be shown when running job. | This switch can be used to suppress plot display even if an AIDA plotter's show method is called from a driver. |
-D | Add a variable definition that applies to the input steering file. | All variables in the XML input file must be resolved using this switch or an error will occur. |
-d | Set the name of the detector model. | This should be a valid detector model defined in detector-data/detectors of HPS Java. |
-e | Print out an informational message every N events. | Replaces EventMarkerDriver. When left out no information is printed about event numbers during the job. |
-h | Print help and exit. | Using this with other arguments will still cause immediate help print and exit. |
-i | Add an LCIO input file. | This switch can be used multiple times. |
-n | Maximum number of events to run in job. | Leave this unset to run all events in the input files; internally -1 is used to indicate unlimited events. |
-p | Load a properties file containing steering file variable definitions. | The input properties file should define name: value for each variable that needs to be defined. |
-r | Treat the supplied steering as a classpath resource rather than a file. | These are typically resources from org/hps/steering in the steering-files module of HPS Java. |
-R | Set the run number to be used when initializing the conditions system. | This has the side effect of "freezing" the conditions system, as the run numbers from the input events will be ignored. |
-s | Skip N events at the beginning of the job. | |
-w | Rewrite the XML steering file with the variables resolved. | This can be used as a simple template engine or for saving the values that were used for a job. |
-x | Execute in dry run mode which means actual job will not execute. | Can be used to check for initialization errors. |
The steering file is supplied as an extra argument rather than with a command switch.
Here is an example using many of these command line arguments together. (This specific command will not work!)
java -jar ./hps-java-trunk/distribution/target/hps-distribution-bin.jar -b -DoutputFile=output -d HPS-EngRun2015-Nominal-v3 -e 100 -i input.slcio \ -n 1000 -p myvars.prop -r -R 5772 -s 10 -w myjob.xml -x /org/hps/steering/dummy.lcsim
If a detector name and run number are both supplied as arguments from the command line, the conditions system will be initialized and frozen, meaning that subsequent event numbers from data will be ignored.
The EvioToLcio tool converts EVIO to LCIO events and optionally can run a steering file job on the in-memory events. This allows the conversion and reconstruction to run in the same job/process for efficiency.
[1037 $] java -cp ./distribution/target/hps-distribution-3.6-SNAPSHOT-bin.jar org.hps.evio.EvioToLcio EvioToLcio [options] [evioFiles] usage: -b enable headless mode in which plots will not show -d <arg> detector name (required) -D <arg> define a steering file variable with format -Dname=value -f <arg> text file containing a list of EVIO files -h print help and exit -L <arg> log level (INFO, FINE, etc.) -l <arg> path of output LCIO file -m <arg> set the max event buffer size -M use memory mapping instead of sequential reading -n <arg> maximum number of events to process in the job -r interpret steering from -x argument as a resource instead of a file -R <arg> fixed run number which will override run numbers of input files -t <arg> specify a conditions tag to use -v print EVIO XML for each event -x <arg> LCSim steeering file for processing the LCIO events
Switch | Description | Notes |
---|---|---|
-b | Activates batch mode plotting so plots will not be shown when running job. | |
-d | Set the name of the detector model. | |
-D | Add a variable definition that applies to the input steering file. | |
-f | Text file containing list of input EVIO files. | |
-L | Set log level. | DEPRECATED Use logging config file or class instead. |
-l | Path of output LCIO file. | |
-m | Set the max event buffer size. | Experts only. |
-M | Use memory mapping in EVIO reader instead of sequential access. | Experts only. |
-n | Maximum number of events to process in the job. | |
-R | Set the run number to be used when initializing the conditions system. | |
-t | Specify a conditions tag for filtering conditions records. | |
-v | Print out EVIO converted to XML for every event. | For verbose debugging of events. |
-r | Interpret steering file from -x as a classpath resource rather than a file. | |
-x | Steering file | Could be resource or file depending on if -r switch is used. |
Here is an example showing how to use most of these command line options.
java -jar ./hps-java-trunk/distribution/target/hps-distribution-bin.jar -b -DoutputFile=output -f evio_files.txt -l lcio_file_output -m 50 \ -v -M -n 1000 -d HPS-EngRun2015-Nominal-v3 -R 5772 -t pass1 -r -x /org/hps/steering/dummy.lcsim
Some of these arguments are similar to the job manager, but the steering file is supplied in a different way. Evio2Lcio uses a command switch to specifiy the steering whereas the job manager expects this as an extra argument without a command switch.
Run scripts that wrap a number of HPS Java command line utilities are generated when building the distribution.
After the build completes, they should be found in this HPS Java directory.
distribution/target/appassembler/bin/
For instance, the EvioToLcio utility can be run using this script.
distribution/target/appassembler/bin/evio2lcio.sh [...]
These scripts have several advantages over running the java commands yourself.
Using symlinks to these scripts works fine e.g.
ln -s distribution/target/appassembler/bin/evio2lcio.sh ./evio2lcio.sh
When using these scripts, you cannot directly supply Java system properties, so the JAVA_OPTS variable should be used instead.
export JAVA_OPTS="-DdisableSvtAlignmentConstants=true"
The full list of Java system properties to be used should be included in this variable. You should not set the options -Xmx or -Djava.util.logging.config.class, as these are set by each script.
The standard location for steering files is steering-files/src/main/resources/org/hps/steering/ in HPS Java.
This folder is organized into the following sub-directories which contain sets of related steering files.
Directory | Description |
---|---|
analysis | includes analysis template |
broken | broken steering files (which may be removed soon!) |
calibration | not really used currently |
monitoring | steering files designed to run in the monitoring application |
production | production steering including event filtering and Data Quality |
readout | readout simulation to be run on MC data from SLIC |
recon | production reconstruction |
users | user files (organized into sub-directories by user name) |
These steering files can be accessed using their path on disk, or they can be referenced as classpath resources. The exact syntax depends on the command line tool.
For example, a steering file resource might be accessed like this using the job manager.
java -jar ./hps-java/distribution/target/hps-distribution-bin.jar -x /org/hps/steering/recon/EngineeringRun2015FullRecon.lcsim [...]
The same steering file could also be accessed as a file from the local copy of HPS Java.
java -jar ./hps-java/distribution/target/hps-distribution-bin.jar hps-java-trunk/steering-files/src/main/resources/org/hps/steering/recon/EngineeringRun2015FullRecon.lcsim [...]
You can use a file rather than a resource if you running a steering file which is not checked into HPS Java or you are using a modified steering file that has not been packaged into the distribution jar.
For instance, suppose the XML file has this variable definition.
<driver name="MyDriver" type="org.example.MyDriver"> <someNumber>${numVar}</someNumber> </driver>
The var would need to be resolved with a command like this.
java -cp ./distribution/target/hps-distribution-bin.jar org.hps.evio.EvioToLcio -DnumVar=1234 [...]
All variables defined in the XML steering files must be resolved from the command line or an error will occur.
The command line tools may be affected by some Java system properties.
Name | Description | Values |
---|---|---|
java.util.logging.config.file | Java logging config file | described in logging package doc |
java.util.logging.config.class | Java logging config initialization class | described in logging package doc |
hep.aida.IAnalysisFactory | AIDA backend factory class |
|
disableSvtAlignmentConstants | Disables reading of SVT alignment constants from conditions db | true |
org.hps.conditions.connection.file | Properties file with connection settings for conditions database | |
org.hps.conditions.connection.resource | Resource that points to properties file with connection settings for conditions database |
|
These values are set as system properties in Java itself.
java -DdisableSvtAlignmentConstants=true [...]
When set in this way, these values are accessible as Java system properties at runtime.
The JVM accepts a number of command line arguments that alter its behavior.
In particular, when running java you will likely want to increase the default heap space, as the default is too low for running HPS Java's full reconstruction.
java -Xmx2g [...]
That will change the heap space to 2 gigabytes.
Also, you may want to run the JVM in server mode.
java -server [...]
The server JVM has been optimized for performance speed and should run faster than the default client JVM.
HPS Java uses the built-in logging facilities of Java described in the logging package documentation.
Every package in HPS Java has a default level which is set in the following config file.
hps-java/logging/src/main/resources/org/hps/logging/config/logging.properties
This config, or any other custom logging config file, can be activated from the command line by setting the config file property to its path.
cd hps-java; java -Djava.util.logging.config.file=logging/src/main/resources/org/hps/logging/config/logging.properties [...]
You can also activate a Java class which will load this configuration.
java -Djava.util.logging.config.class=org.hps.logging.config.DefaultLoggingConfig [...]
These are the available log levels, in descending order.
Level | Description | Use |
---|---|---|
SEVERE | severe error message usually meaning program should halt | unrecoverable errors that halt the program |
WARNING | warning message indicating a non-fatal error or problem | warning messages |
INFO | informational messages | informational messages that should usually print when the program runs |
CONFIG | configuration messages | printing out config information for a class or tool |
FINE | debug print outs | high level debugging messages that should not typically be active |
FINER | more verbose debug print outs | more verbose debugging messages |
FINEST | most verbose debug messages | the most verbose debugging messages |
ALL | print all error messages | when logger should always print all messages |
OFF | disable all messages | when logger should be completely disabled from printing |
Each logger inherits by default from the global log setting.
This is defined in the config file as follows.
# default global level .level = WARNING
So if a package is not explicitly configured, it will inherit the WARNING log level from the global logger.
In the config file, loggers are defined and configured by package rather than class.
# evio org.hps.evio.level = CONFIG
In the above config, any logger in the org.hps.evio package will have a log level of CONFIG.
A class's logger is typically defined using the following template.
package org.example; import java.util.logging.Logger; class MyClass { static private final Logger LOGGER = Logger.getLogger(MyClass.class.getPackage().getName()); void someMethod() { LOGGER.info("some method was called"); } }
The class uses a package rather than class logger.
The handler and the level should not be assigned in the code, as this will instead be configured in the logging config file.