Broadband User Guide v13.9.0 - Revision history

Fsilva: /* Running Acceptance Tests */

2014-03-27T21:41:58Z

Running Acceptance Tests

Fsilva: /* SDSU Method: BBToolbox exits with code 174 */

2013-10-25T16:29:16Z

SDSU Method: BBToolbox exits with code 174

Fsilva: /* Appendix A: Troubleshooting */

2013-10-25T16:27:03Z

Appendix A: Troubleshooting

Fsilva: /* test_gof */

2013-09-26T15:31:07Z

test_gof

Fsilva: /* test_gof */

2013-09-26T15:30:00Z

test_gof

Fsilva: /* Unit/Acceptance Test Failures and Errors */

2013-09-26T15:29:37Z

Unit/Acceptance Test Failures and Errors

Fsilva at 17:14, 12 September 2013

2013-09-12T17:14:32Z

Fsilva: /* Sample User-defined Southern California simulation with source description */

2013-09-12T17:09:06Z

Sample User-defined Southern California simulation with source description

Fsilva: /* Available Options */

2013-09-12T17:08:38Z

Available Options

Fsilva: /* Platform Modes */

2013-09-12T17:08:07Z

Platform Modes

@@ Line 249: / Line 249: @@
 Make sure the unit tests pass before moving on to the acceptance tests. To run the acceptance tests, users should:
-$ cd /home/sarah/bbp/13.9.0/tests
+ $ cd /home/sarah/bbp/13.9.0/tests
-$ ./AcceptTests.py
+ $ ./AcceptTests.py
 There will be one test for each method in the platform, for both the validation mode (historical events) and the scenario modes (hypotethical earthquakes). These tests will take somewhere between 2 and 3 hours to run, depending on how fast the computer is.

@@ Line 812: / Line 812: @@
   BBtoolbox.exe      0000000000403629  Unknown               Unknown  Unknown
-This message reflects an issue in the raytracer code used by BBToolbox that will cause the code to fail with certain geometries. The SDSU team is currently working on a fix to this issue and we expect a future version of the Platform to include the fix. Meanwhile, the user can try to change the problem geometry in order to avoid the error. This can be done by overriding the geometry that is calculated based on the stations and rupture (using a larger x/y/z grid will not affect the simulation results but can sometimes solve this raytracer issue). To specify a different geometry to be used by BBToolbox's raytracer, users can include the following keys in the SRC file:
+This message reflects an issue in the raytracer code used by BBToolbox that will cause the code to fail with certain geometries. The SDSU team is currently working on a fix to this issue and we expect a future version of the Platform to include the fix. Meanwhile, the user can try to change the problem geometry in order to avoid the error. This can be done by overriding the geometry that is calculated based on the stations and rupture (using a larger x/y/z grid will not affect the simulation results but can sometimes solve this raytracer issue). To see what is the current problem geometry, users can look for the following line in the .bbpar file (located in the $BBP_DATA_DIR/indata/<simulation_id> directory:
   GRID_X = xxx

← Older revision		Revision as of 16:27, 25 October 2013
Line 768:		Line 768:

	These messages do not indicate a failure of the unit test. At the end of this test you will still see the "ok" status, indicating that the test was successful.		These messages do not indicate a failure of the unit test. At the end of this test you will still see the "ok" status, indicating that the test was successful.
		+
		+	=== Runtime Warnings and Errors ===
		+
		+	Below is a list of known issues in the current Broadband 13.9.0 release that can sometimes cause a simulation to fail.
		+
		+	==== SDSU Method: BBToolbox exits with code 174 ====
		+
		+	The current version of SDSU's BBToolbox code can sometimes fail with an exit code of 174. This will cause the Broadband simulation to stop immediately and a message similar to the one below will be recorded in the bbtoolbox log file (which is located in the simulation's log directory at $BBP_DATA_DIR/logs/<simulation_id>:
		+
		+	* Welcome to the Broad-Band Toolbox (v1.5) *
		+
		+	Initialising the code, please type input filename ...
		+	rl= 131
		+	rl= 131
		+	Starting slug3d: by J. Vidale, 1988, UCSC
		+	Starting punch: by J. Hole, 1993, UBC-Stanford
		+	-- travel-times written to :time3d_P.out
		+	-- selected velocity file :vel3d_P.bin
		+	WARNING: Computing only to max radius = 1001
		+	Completed radius = 10
		+	Completed radius = 20
		+	Completed radius = 30
		+	Completed radius = 40
		+	Completed radius = 50
		+	Completed radius = 60
		+	Completed radius = 70
		+	Completed radius = 80
		+	Completed radius = 90
		+	Completed radius = 100
		+	Completed radius = 110
		+	wavefront done
		+	Starting slug3d: by J. Vidale, 1988, UCSC
		+	Starting punch: by J. Hole, 1993, UBC-Stanford
		+	-- travel-times written to :time3d_S.out
		+	-- selected velocity file :vel3d_S.bin
		+	WARNING: Computing only to max radius = 1001
		+	forrtl: severe (174): SIGSEGV, segmentation fault occurred
		+	Image PC Routine Line Source
		+	BBtoolbox.exe 000000000043A28B Unknown Unknown Unknown
		+	BBtoolbox.exe 0000000000403A8B Unknown Unknown Unknown
		+	BBtoolbox.exe 000000000040372C Unknown Unknown Unknown
		+	libc.so.6 000000337641ECDD Unknown Unknown Unknown
		+	BBtoolbox.exe 0000000000403629 Unknown Unknown Unknown
		+
		+	This message reflects an issue in the raytracer code used by BBToolbox that will cause the code to fail with certain geometries. The SDSU team is currently working on a fix to this issue and we expect a future version of the Platform to include the fix. Meanwhile, the user can try to change the problem geometry in order to avoid the error. This can be done by overriding the geometry that is calculated based on the stations and rupture (using a larger x/y/z grid will not affect the simulation results but can sometimes solve this raytracer issue). To specify a different geometry to be used by BBToolbox's raytracer, users can include the following keys in the SRC file:
		+
		+	GRID_X = xxx
		+	GRID_Y = yyy
		+	GRID_Z = zzz
		+
		+	Where xxx, yyy, and zzz are the new dimensions for the raytracer to use (specified in km).

	== Related Entries ==		== Related Entries ==

← Older revision		Revision as of 15:31, 26 September 2013
Line 763:		Line 763:

	/usr/lib64/python2.7/site-packages/matplotlib/font_manager.py:1242: UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found.		/usr/lib64/python2.7/site-packages/matplotlib/font_manager.py:1242: UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found.
		+	Falling back to Bitstream Vera Sans
		+	/usr/lib64/python2.7/site-packages/matplotlib/font_manager.py:1242: UserWarning: findfont: Font family ['STIXSizeFourSym'] not found.
	Falling back to Bitstream Vera Sans		Falling back to Bitstream Vera Sans

@@ Line 758: / Line 758: @@
 Unit and Acceptance tests are provided to verify the Broadband platform and it's supporting modules built by the user are functioning as designed. Under certain circumstances, some of these test might fail or print a warning message. While some of these failures might indicate serious problems that will have to be addressed before the platform can used, it is acceptable to ignore some of the warnings. This section lists some issues and their solutions.
-===== test_gof =====
+==== test_gof ====
 In certain environments, the test_gof unit test will display a series of warning messages regarding the availability of certain fonts used in the plots. The user would see a number of messages like:
-  /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py:1242: UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found. Falling back to Bitstream Vera Sans
+  /usr/lib64/python2.7/site-packages/matplotlib/font_manager.py:1242: UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found.
 These messages do not indicate a failure of the unit test. At the end of this test you will still see the "ok" status, indicating that the test was successful.

@@ Line 754: / Line 754: @@
 The instruction for installing Broadband Platform are listed in Section 1: "Installing the Second-Generation Broadband Platform" of the User guide. If after following all steps listed in this section of the user guide the build fails, check if the failure is listed in this section and try the solution to fix the issue you are facing.
-=== Unit/Acceptance Test Failures and Errors ===
+=== Unit/Acceptance Test Warnings and Errors ===
-Unit and Acceptance tests are provided to verify the Broadband platform and it's supporting modules built by the user are functioning as designed. Under certain circumstances, some of these test might fail or print a warning message. While some of these failure might indicate serious problems that will have to be addressed before the platform can used, it is acceptable to ignore some of the failures. This section lists some failures and their solutions.
+Unit and Acceptance tests are provided to verify the Broadband platform and it's supporting modules built by the user are functioning as designed. Under certain circumstances, some of these test might fail or print a warning message. While some of these failures might indicate serious problems that will have to be addressed before the platform can used, it is acceptable to ignore some of the warnings. This section lists some issues and their solutions.
 == Related Entries ==

@@ Line 199: / Line 199: @@
 == Advanced Users ==
-Alternatively, if you would like access to the latest version of the platform, to get frequent but less thoroughly tested improvements, you can check out the platform from SCEC's Subversion version control repository on intensity.usc.edu. Only advanced users should follow this approach. If you are unsure, you should download the code as outlined in [[#Downloading the Platform|Downloading the Platform]] and skip this section.
+Alternatively, if you would like access to the latest version of the platform, to get frequent but less thoroughly tested improvements, you can check out the platform from SCEC's Subversion version control repository on source.usc.edu. Only advanced users should follow this approach. If you are unsure, you should download the code as outlined in [[#Downloading the Platform|Downloading the Platform]] and skip this section.
 You may need to request access from the SCEC system administrator, John Yu ([mailto:johnyu@usc.edu johnyu@usc.edu]). Make sure you have subversion in your path before beginning.
@@ Line 241: / Line 241: @@
 The tests should begin and will take approximately 30 minutes to run. At the end of each test, a "ok" should be printed if the test was
-successful. At the end, the program will print the number of tests that passed and the number of tests that failed. If a test has failed, first check that you have built the executables.You can rerun just the specific test that failed (test_<module>.py). If the test is still failing, also verify that you have the ref_data directory, since it contains the input and reference files. If you're looking for more information about the failure, you can consult the Unit Tests log file in $BBP_DATA_DIR/logs/unit_test.log .  If you can't determine the reason for the failure, contact [mailto:software@intensity.usc.edu support].
+successful. At the end, the program will print the number of tests that passed and the number of tests that failed. If a test has failed, first check that you have built the executables.You can rerun just the specific test that failed (test_<module>.py). If the test is still failing, also verify that you have the ref_data directory, since it contains the input and reference files. If you're looking for more information about the failure, you can consult the Unit Tests log file in $BBP_DATA_DIR/logs/unit_test.log .  If you can't determine the reason for the failure, contact [mailto:software@scec.org support].
 Once the unit tests all pass, proceed to the acceptance tests. If there are any failure or errors while running the unit tests, consult the Troubleshooting section at the end of this user guide for know issues and their solutions.
@@ Line 254: / Line 254: @@
 There will be one test for each method in the platform, for both the validation mode (historical events) and the scenario modes (hypotethical earthquakes). These tests will take somewhere between 2 and 3 hours to run, depending on how fast the computer is.
-When they're complete, the console will either print "OK" or how many tests failed. Acceptance test failures indicate that the modules are not integrated correctly. Like with the unit tests, verify that you have the ref_data directory.  If a certain acceptance test fails, you can get more information by consulting the acceptance test logs in $BBP_DATA_DIR/logs/acceptance_tests_logs/<test that failed>.log .  If you can't determine the reason for the failure, contact [mailto:software@intensity.usc.edu support].
+When they're complete, the console will either print "OK" or how many tests failed. Acceptance test failures indicate that the modules are not integrated correctly. Like with the unit tests, verify that you have the ref_data directory.  If a certain acceptance test fails, you can get more information by consulting the acceptance test logs in $BBP_DATA_DIR/logs/acceptance_tests_logs/<test that failed>.log .  If you can't determine the reason for the failure, contact [mailto:software@scec.org support].
 Since the acceptance tests can take a long time to run, you may wish to resume where you left off. This feature is supported automatically. If you do not wish to resume, delete the resume file in $BBP_DATA_DIR/logs/resume.txt. If there are any failure or errors while running the acceptance tests, consult the Troubleshooting section at the end of this user guide for known issues and their solutions.
@@ Line 745: / Line 745: @@
 If you run into bugs with the platform, you can open a trouble ticket at the [http://northridge.usc.edu/trac/broadband Broadband Trac site].
-Check to see if there has already been a ticket opened for the bug. If you are unable to get the platform to run, you can get direct user support by emailing [mailto:software@intensity.usc.edu software@intensity.usc.edu].
+Check to see if there has already been a ticket opened for the bug. If you are unable to get the platform to run, you can get direct user support by emailing [mailto:software@scec.org software@scec.org].
 = Appendix A: Troubleshooting =

@@ Line 549: / Line 549: @@
 == Sample User-defined Southern California simulation with source description ==
-Next let's try running a user-defined event. Copy the files $BBP_DIR/examples/user_rup_gen/nr_one_stat.stl and $BBP_DIR/examples/user_rup_gen/user_eq.src to the start directory. user_eq.src is a simple source description. Its format is outlined in [[#Simple source description|section 5.1]].
+Next let's try running a user-defined event. Copy the files $BBP_DIR/examples/user_rup_gen/nr_one_stat.stl and $BBP_DIR/examples/user_rup_gen/user_eq.src to the start directory. user_eq.src is a simple source description. Its format is outlined in [[#Simple source description|section 6.1]].
   $ ./run_bbp.py

@@ Line 399: / Line 399: @@
 == Available Options ==
-To get a list of the current available options, run run_bbp_2G.py with the -h flag.
+To get a list of the current available options, run run_bbp.py with the -h flag.
   $ ./run_bbp.py --help

@@ Line 396: / Line 396: @@
 An option file provides responses to all the questions that the platform poses. The format is described in [[#Option File|section 6.7]], but it's basically a text file, 1 entry per line, with support for comments. It can be fed to the platform using the -o option.
-The platform will also accept XML files containing a full description of a run. The schema for these files is given in [[#XML workflow description schema|section 5.7]]. These files are also produced by the platform after every simulation, and placed in xml/<simulation ID>.xml. So if you want to rerun a simulation, you can point the platform to the XML file from that simulation using the -x option. Note that a new simulation ID will be assigned to the run, so there is no risk of overwriting previous simulation results.
+The platform will also accept XML files containing a full description of a run. The schema for these files is given in [[#XML workflow description schema|section 6.8]]. These files are also produced by the platform after every simulation, and placed in xml/<simulation ID>.xml. So if you want to rerun a simulation, you can point the platform to the XML file from that simulation using the -x option. Note that a new simulation ID will be assigned to the run, so there is no risk of overwriting previous simulation results.
 == Available Options ==