Broadband User Guide v11.2.2 - Revision history

Fsilva: /* User Support */

2014-07-15T17:08:18Z

User Support

Patrices at 23:12, 13 February 2012

2012-02-13T23:12:17Z

Patrices at 22:08, 7 December 2011

2011-12-07T22:08:10Z

Maechlin: /* Running Acceptance Tests */

2011-11-21T06:08:15Z

Running Acceptance Tests

Maechlin: /* Advanced Users */

2011-11-12T03:00:35Z

Advanced Users

Sandarsh: /* Advanced Users */

2011-10-21T22:00:03Z

Advanced Users

Sandarsh: /* Advanced Users */

2011-10-21T21:57:48Z

Advanced Users

Sandarsh: /* Building the Platform */

2011-10-21T21:52:09Z

Building the Platform

Sandarsh at 21:51, 21 October 2011

2011-10-21T21:51:22Z

Sandarsh: /* Software Dependencies */

2011-10-14T18:35:10Z

Software Dependencies

@@ Line 784: / Line 784: @@
 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: Possible Module Permutations =

← Older revision		Revision as of 23:12, 13 February 2012
Line 1,648:		Line 1,648:

	'''Solution:''' The stochastic nature of the high frequency simulations is considered, and a constant random seed as input for our tests. This is the same constant random seed used to generate the reference results included in the release. This ensures that the time-series generated with unit tests agree with reference results. However, the high frequency codes are more sensitive to changes in compilers and machines due to the algorithm, so small differences that cause the test to fail are generally acceptable. The user is however encouraged to plot the two time-series and visually inspect them to verify they look similar. We are trying to come up with a better comparison for these tests.		'''Solution:''' The stochastic nature of the high frequency simulations is considered, and a constant random seed as input for our tests. This is the same constant random seed used to generate the reference results included in the release. This ensures that the time-series generated with unit tests agree with reference results. However, the high frequency codes are more sensitive to changes in compilers and machines due to the algorithm, so small differences that cause the test to fail are generally acceptable. The user is however encouraged to plot the two time-series and visually inspect them to verify they look similar. We are trying to come up with a better comparison for these tests.
		+
		+	= Appendix C: Technical Notes =
		+
		+	== Running Individual Acceptance Tests ==
		+
		+	The acceptance test script ./tests/AcceptTest.py attempts to run all of the defined tests when executed. However, sometimes it is useful to run an acceptance test in isolation for troubleshooting purposes:
		+
		+	* Identify the test you want to run. Eg: user-URS-UCSB-SDSU-SDSU
		+	* Move to the ./comps directory and execute that test's XML workflow with run_bbp_2G.py. Using the above example:
		+	<pre>
		+	$ ./run_bbp_2G.py -x ../ref_data/accept_inputs/user-URS-UCSB-SDSU-SDSU.xml
		+	</pre>
		+
		+	Since you are running the test outside of AcceptTest.py, you will not see a PASS/FAIL message once the simulation completes. However, you can review the contents of the ./outdata/<SIMID> directory to verify that the correct seismograms and response spectra tables were produced.
		+
		+	== Manaully Setting Random Number Generator Seed Values ==
		+
		+	Several of the platform codebases employ random number generators to produce SRFs and seismograms. These random number generators are generally seeded with an initial value (typically an integer) which are hard-coded in the platform. Advanced users may desire to change these seed values.
		+
		+	Changing the seeds for seismogram synthesis varies depending on which codebase you want to use:
		+
		+	* URS: Edit ./comps/hfsims_cfg.py, Line 43 "self.RAND_NUM"
		+	* UCSB: Edit ./src/ucsb/Syn1DSCEC/syn1D_LAH.f, Line 183 "iseed", and recompile with "make"
		+	* SDSU:
		+	** User event: Edit ./bbp_2g_gf/sdsu/scattering_generic.dat (seed values annotated in file)
		+	** Validation event: Edit ./bbp_2g_gf/sdsu/<event>/scattering.dat

@@ Line 23: / Line 23: @@
 *GNU compilers (gcc, gfortran) v4.5.1
 *GNU Fortran 77 v3.4.6
+*GMT (Generic Mapping Toolkit)
-Optional:
+*ImageMagick
 == Setting Up Your Account ==

@@ Line 291: / Line 291: @@
   $> cd tests
-  $> ./AcceptTests.py
+  $> ./AcceptTests.py &> accept.out &
-Since they take so long to run, you may want to background them instead and redirect their output:
+  $> tail accept.out
- $> ./AcceptTests.py &> accept.out &
+When all the acceptance tests are completed, the AcceptTests.py script will either print "OK" or how many tests failed.
-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_2g/logs/acceptance_tests_logs/<test that failed>.log .  If you can't determine the reason for the failure, contact [[support]].
+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_2g/logs/acceptance_tests_logs/<test that failed>.log .  If you can't determine the reason for the failure, contact [[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 ref_data/accept_inputs/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 know issues and their solutions.

← Older revision		Revision as of 03:00, 12 November 2011
Line 237:		Line 237:

	This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from SCEC software distribution server. If you are working on SCEC development server, you might be able to create a symbolic link to data folder. Please contact [[#User_Support\|User Support]] to get a location of the data folder on the SCEC development server. If you are not working on SCEC development server, or don't have an SCEC Linux login account, you can get a archive (.tgz) file of the Green's functions from the same download site you obtained this guide.		This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from SCEC software distribution server. If you are working on SCEC development server, you might be able to create a symbolic link to data folder. Please contact [[#User_Support\|User Support]] to get a location of the data folder on the SCEC development server. If you are not working on SCEC development server, or don't have an SCEC Linux login account, you can get a archive (.tgz) file of the Green's functions from the same download site you obtained this guide.
		+
		+	If you know where a read-accessible installation of the green functions data directories you can create a link to that location. This can save disk space in some cases.
		+
		+	ln -s /home/scec-00/scottcal/bband/bbp_2g_gf <path to your gf directory>

	Periodically you should check for updates to the code. To do so, go to your bbp_2g directory and type		Periodically you should check for updates to the code. To do so, go to your bbp_2g directory and type

@@ Line 236: / Line 236: @@
   $> svn checkout https://source.usc.edu/svn/broadband/trunk bbp_2g
-This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from SCEC software distribution server. If you are working on SCEC development server, you might be able to create a symbolic link to data folder. Please contact software support to get a location of the data folder on the SCEC development server.
+This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from SCEC software distribution server. If you are working on SCEC development server, you might be able to create a symbolic link to data folder. Please contact [[#User_Support|User Support]] to get a location of the data folder on the SCEC development server. If you are not working on SCEC development server, or don't have an SCEC Linux login account, you can get a archive (.tgz) file of the Green's functions from the same download site you obtained this guide.
 Periodically you should check for updates to the code. To do so, go to your bbp_2g directory and type

@@ Line 224: / Line 224: @@
 == 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 236: / Line 236: @@
   $> svn checkout https://source.usc.edu/svn/broadband/trunk bbp_2g
-This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from the [on intensity. If you are working on intensity as well, you can just create a symbolic link:
+This will check out the project to your local machine. It contains the source code, tests, and some example files. You also need to obtain a copy of the Broadband Platform data files, containing the Green's tensors. They are too large to be stored in version control. You can obtain a copy from SCEC software distribution server. If you are working on SCEC development server, you might be able to create a symbolic link to data folder. Please contact software support to get a location of the data folder on the SCEC development server.
- $> ln -s /home/scec-00/scottcal/bband/bbp_2g_gf <path to your gf directory>
+If you are not working on SCEC development server, or don't have an SCEC Linux login account, you can get a archive (.tgz) file of the Green's functions from the same download site you obtained this guide.
 Periodically you should check for updates to the code. To do so, go to your bbp_2g directory and type

@@ Line 190: / Line 190: @@
 Once you have checked out the code, you need to build it. By default, every executable is compiled using the compiler recommended by the code developer. However, if you have limited compiler options or are building the codes on an untested system, you may need to specify non-standard alternative compilers, as described below.
-Before you can build the platform, you need to make sure that the Intel compilers are in your path. This is done automatically on intensity.usc.edu, but on other systems you can check by typing:
+Before you can build the platform, you need to make sure that the Intel compilers are in your path. This is done automatically on broadband.usc.edu, but on other systems you can check by typing:
   $>which icc

@@ Line 93: / Line 93: @@
   setenv BBP /home/scec-00/kumar/bbp_2g
 * PYTHONPATH
 After you've obtained a copy of the project, you'll need to make sure the comps directory is on Python's path so Python can find all the project modules. If you're running a Bash shell, add the following line to your .bash_profile with your favorite text editor:
@@ Line 110: / Line 109: @@
 For Bash Shell (in .bash_profile)
-  export PATH=/usr/scec/intel/cce/9.0/bin:/usr/scec/intel/fce/9.0/bin:$PATH
+  export PATH=/usr/usc/intel/composerxe-2011.4.191/bin/intel64:/usr/usc/intel/composerxe-2011.4.191/mpirt/bin/intel64:$PATH
 For C-shell (in .cshrc)
-  setenv PATH /usr/scec/intel/cce/9.0/bin:/usr/scec/intel/fce/9.0/bin:$PATH
+  setenv PATH /usr/usc/intel/composerxe-2011.4.191/bin/intel64:/usr/usc/intel/composerxe-2011.4.191/mpirt/bin/intel64:$PATH
 When running elements of the platform over ssh, be sure to enable ssh forwarding (with the -X or -Y options).
@@ Line 1,483: / Line 1,482: @@
 '''Solution:''' Ensure that the path Intel 64-bit compilers are listed in you PATH variable and being picked up by running 'which icc' and 'which ifort'. If you are trying to build the platform on SCEC development servers like Intensity, verify your path variable has:
 <pre>
-  PATH=...:usr/scec/intel/cc/9.0/bin:/usr/scec/intel/fc/9.0/bin
+  PATH=...:/usr/usc/intel/composerxe-2011.4.191/mpirt/bin/intel64:/usr/usc/intel/composerxe-2011.4.191/bin/intel64
 </pre>