Current Functionality:

TestRefMacro — Returns the reference image of the specified test.

Example:

[[TestRef(TestName)]]

TestSimMacro — Returns the simulation image of the specified test.

Example:

[[TestSim(TestName)]]

TestLogMacro — Returns the run log of the specified test.

Example:

[[TestLog(TestName)]]

TestsMacro — Returns a table of reference and simulation images of all tests.

Example:

[[Tests]]

Test images may be manipulated using all standard arguments. For example:

[[Tests(120px)

Will rescale the width of all pictures to 120 pixels.

See example here: u/noyesma

The plugin reads available directories from the /data/tests directory on clover. If are are no corresponding images for a test in the SVN repository, the image entries will just appear as a question mark in the table. Hence, as new tests are added they will be automatically displayed in the Tests table.

I also added functionality to buildproblem to check the bear2fix.data.img on clover to determine the frame number that should be uploaded for each test. That should fix the issue with FieldLoopRestart. In addition, the astrobear log file is now added to the test log uploaded to the SVN repository.

Finally, I updated the buildproblem -d parameter to check out the latest copy of astrobear. For example:

buildproblem -d ~/astrobear/ -t -np 2

Will check out a fresh copy of the code to ~/astrobear/, and run all tests with 2 processors. If ~/astrobear/ already exists it will not check out the latest copy, presuming you want to run with the older version already present.

The OrbitingParticles test and testing compilation with various flags are still under development. The RadiativeInstability tests need to be optimized to only produce the chombo that will be used for the test, not for an entire run.

The infrastructure for testing is in place, with the exception of wiki integration.

Concerns for the meeting will be:

1. Should the directory structure used in the tests repository be modified to be easier to read?
2. Should the "history" of tests be reflected in various SVN revisions or by date directories (as they are now)?
3. Final functionality required for wiki integration.
4. Bear2fix updates.

Now that build problem and go.s are fairly robust, the following remains for wiki integration. Let me know if you believe there is a more efficient or effective way of organization.

I created a new SVN repository at /data/repositories/tests on clover. This repo is currently integrated under the Browse Source tab.

This repository will store files of interest from /data/tests on clover.

The files will be organized as follows:

testname/logs/[date]/(testlog, rel_errors.data, abs_errors.data)

testname/images/[date]/sim.png

testname/images/ref.png

after go.s runs, the entire /data/tests directory will be checked into the repository. All files in this directory will be ignored except for those mentioned above.

A wiki plugin will be created which iterates through the repository and embeds the images in a wiki page. For example:

[[Tests]]

would output the references and simulation runs for all tests for all dates, as well as a success or failure flag.

[[TestList]]

would output a list of all tests currently on file in the repository.

Since only one reference is listed in the subversion repository for each test, any changes to this reference should the original be determined inaccurate would automatically update on pages using this plugin. One concern is if Trac will allow me to modify the "success" flag to invalidate all test results preceding the date of the reference change.

The results could also be culled. For example:

[[Tests(FieldLoopAdvection, 11-11-2010, 11-11-2011)]]

would output the references and simulation runs for the FieldLoopAdvection test over the course of a year. This will allow for more complicated WikiFormatting structures, such as comparisons between test runs of different dates in tables.

Specific data can also be represented:

[[TestResults(FieldLoopAdvection, 11-11-2011)]]

would only output "success" or "failure" for the FieldLoopAdvection test run on 11-11-2011.

[[TestSim(FieldLoopAdvection, 11-11-2011)]]

would only output the the simulation picture for the FieldLoopAdvection test run on 11-11-2011.

[[TestReference(FieldLoopAdvection)]]

would only output the reference picture for the FieldLoopAdvection test.

Please let me know what features/data culling abilities/syntax you would like to see if it is not adequately represented in the format above.

I have created two tickets in regards to executing bear2fix scripts.

Please see the tickets #159 and #160 for more details.

UPDATE: Issues have been resolved. Bear2fix integration should now be usable.

I have updated the build problem script to the point where it is suitable for general use. To begin using on a regular basis, add the following to ~/.bashrc:

export PATH=/home/noyesma/bin:$PATH

The script now automatically dumps all chombo files to /data/tests/[MODULE]/out on clover.

This requires setting up passwordless SSH for your account. The procedure for this is a follows:

1. SSH into grass or alfalfa

ssh [username]@grass.pas.rochester.edu

2. Create a secure key

ssh-keygen -t dsa

DO NOT change the default name of id_dsa

When it prompts for a passphrase, just press press enter. This will make the key passphrase-less.

3. Change the private key permissions to be readable only by you.

chmod 600 .ssh/id_dsa

4. Install the public key on your remote computer (For clover, the home directory is the same as grass so you don't need to SCP it).

scp .ssh/id_dsa.pub [username]@clover.pas.rochester.edu
ssh [username]@clover.pas.rochester.edu
cat id_dsa.pub >> .ssh/authorized_keys
rm id_dsa.pub

I created a problem submission script based in part on the old buildtests.s script. I have debugged it enough to the point where it seems usable, please let me know if there are any issues with it.

The script is called buildproblem and is located at /home/noyesma/buildproblem on grass.

Pre-Conditions

1. The astrobear code has been checked out to some location
2. The module directory exists and contains properly formatted *.data files.
3. A Makefile.inc.[hostname] file exists in the root code directory with [hostname] being the name of the machine being compiled for

Features

1. Compiles AstroBEAR based on the machine being run on
2. Populates TABLES and out directories
3. Copies and runs astrobear to the run directory (currently the run directory is the module directory)
4. Outputs run log to a (date).log file

Usage

buildproblem [-d code_dir] [-m module] [-np processors] [-t]

buildproblem -d /grassdata/noyesma/astrobear -m RTInstability -np 2

cd /grassdata/noyesma/astrobear
buildproblem -t -np 8

Tips and Tricks

1) Running

buildproblem [arguments] &> /dev/null &

will compile and run astrobear in the background and pipe all non-error output to null.