Workflow Program Requirements - Revision history

Wsavran: /* Characteristics of a Workflow System */

2018-08-14T21:51:21Z

Characteristics of a Workflow System

Maechlin at 19:29, 22 August 2012

2012-08-22T19:29:15Z

Maechlin at 13:44, 31 August 2010

2010-08-31T13:44:28Z

Maechlin at 13:44, 31 August 2010

2010-08-31T13:44:03Z

Maechlin at 13:43, 31 August 2010

2010-08-31T13:43:07Z

Maechlin at 13:38, 31 August 2010

2010-08-31T13:38:55Z

Maechlin at 13:35, 31 August 2010

2010-08-31T13:35:51Z

Maechlin: Created page with 'We recommend the following programming standards for CME scientific software. These standards help make the codes interoperate. #For programs to be hosted as components in workf…'

2010-08-16T17:19:58Z

Created page with 'We recommend the following programming standards for CME scientific software. These standards help make the codes interoperate. #For programs to be hosted as components in workf…'

New page

We recommend the following programming standards for CME scientific software. These standards help make the codes interoperate.

#For programs to be hosted as components in workflows, we ask scientists to prepare their code this way.
#The code should return an exit code when it runs. It should return only two values: Successful return = 0 - Error exit return = 1
#For each code, the number of input and output files must be known and should always be the same whenever the program is run.
#There should be no compiled in references to programs, pathnames, or files names in the code. It is okay to set default values for filenames, however, it should be possible for users of the code to overwrite any default file names if necessary using command line parameters.
#If the code references any other executables, the program should accept a command line parameter to a directory where the executable can be found.
#The code should accept command line parameters to any input files names and not assume that the input file it uses is referred to by a particular name.
#The code should accept command line parameters to any output files so we can assign the name to the output file and output directory.
#If the code requires any environment variables, the program should verify that they are successful read or exit with an error.

For programs to be hosted as components in workflows, we ask scientists to prepare their code this way.

#The code should read variable inputs either on command line or from a configuration file. A code should have its own config file, or its own section in a config file, that contains parameters related only to itself and no other programs.
#If the code passes parameters on the command line, it is better to use attribute name, attribute value pairs (e.g. –o output_file name –i input_file_name) rather than positional values (e.g. first command line parameter is the input file name, second command line parameters is the output filename).
#Programs should input and output seismograms in broadband platform format, which contains 3 components in a single file.
#Programs should work with an arbitrary seismograms of arbitrary length (remove the power of 2 number of samples restriction)
#When SCEC run’s the program, we will probably submit the program to a job scheduler, using a job scheduler scripting language like PBS. Demonstrating that the software can be run using a PBS interfaces makes is much easier for us to use the program in a workflow.

@@ Line 7: / Line 7: @@
 #File and metadata management to track files in system.
 #Support for distributed processing across multiple computing resources.
 == General Program Guidelines for Programs used in a Workflow ==

@@ Line 1: / Line 1: @@
 We recommend the following programming standards for CME scientific software. These standards help make the codes interoperate. For programs to be hosted as components in workflows, we ask scientists to prepare their code this way.
-== General Program Guidelines ==
+== Characteristics of a Workflow System ==
 #The code should return an exit code when it runs. It should return only two values: Successful return = 0 - Error exit return = 1
 #For each code, the number of input and output files must be known and should always be the same whenever the program is run.

@@ Line 21: / Line 21: @@
 == Grid-based Program Guidelines ==
-The Pegasus Programming community has defined a series of guidelines for writing software that will run in a grid environment. Their guidelines are posted on the Pegasus web site:
+The Pegasus Programming community has defined a series of guidelines for writing software that will run in a grid environment. Their guidelines are posted on the Pegasus web site. This link will open a PDF file.
 [http://pegasus.isi.edu/wms/docs/guides/ap1/Developing-Codes-For-Grid-ap1.pdf Pegasus-developed Grid Program Guidelines]

← Older revision		Revision as of 13:44, 31 August 2010
Line 24:		Line 24:

	[http://pegasus.isi.edu/wms/docs/guides/ap1/Developing-Codes-For-Grid-ap1.pdf Pegasus-developed Grid Program Guidelines]		[http://pegasus.isi.edu/wms/docs/guides/ap1/Developing-Codes-For-Grid-ap1.pdf Pegasus-developed Grid Program Guidelines]
		+
		+	This link will open a PDF file.

@@ Line 6: / Line 6: @@
 #The code should accept command line parameters to any input files names and not assume that the input file it uses is referred to by a particular name.
 #The code should accept command line parameters to any output files so we can assign the name to the output file and output directory.
-#If the code requires any environment variables, the program should verify that they are successful read or exit with an error.
+#The code should read variable inputs either on command line or from a configuration file. A code should have its own config file, or its own section in a config file, that contains parameters related only to itself and no other programs.
-For programs to be hosted as components in workflows, we ask scientists to prepare their code this way.
+== Broadband Platform Specific Recommendations ==
 #Programs should input and output seismograms in broadband platform format, which contains 3 components in a single file.
 #Programs should work with an arbitrary seismograms of arbitrary length (remove the power of 2 number of samples restriction)