Sinusoidal Domain

[ian-bertolacci]

• under subdirectory
• Readme
  • Includes
    • How to run (On ocelote)
    • What specific software to download/run
      • Including ocelote module
      • Also exactly the parflow version, build configuration (versions/brands of mpi, compiler, hypre)
• scripts
  • parameterized TCL script
  • bash script

Done when: Michelle can go onto Ocelote and run this without snags.

[ian-bertolacci]

@mstrout
To test this, you will need to log into ocelote, make a test directory somewhere, and clone the repository.

The instructions in are in test_domains/sinusoidal/

[mstrout]

I logged into ocelote, but then ran into the following snag:

[mstrout@login2 Hydroframe]$ git clone https://github.com/CompOpt4Apps/IanHydroframeWork.git
Initialized empty Git repository in /home/u2/mstrout/Hydroframe/IanHydroframeWork/.git/
error: The requested URL returned error: 403 Forbidden while accessing https://github.com/CompOpt4Apps/IanHydroframeWork.git/info/refs

fatal: HTTP request failed

I was able to clone your repository just fine on my Mac. What is causing the issue?

[ian-bertolacci]

This is probably a permissions problem.
I have my ssh keys setup on ocelote so I can clone my private repositories using the ssh url: git clone git@github.com:CompOpt4Apps/IanHydroframeWork.git

When I clone with the https url, as you are doing (git clone https://github.com/CompOpt4Apps/IanHydroframeWork.git) I have to type in my username and password.

Is it possible you typed in a password wrong or our github credentials stored on Ocelote are wrong?

Alternatively, you can download the source locally in a zip file (on the repo page click "Clone or Download" then "Download zip") and SCP the file to ocelote (documentation on using SCP for UAHPC)

[mstrout]

Waiting to hear back from HPC consult about git clone on ocelote.

[ian-bertolacci]

@mstrout Please review test_domains/sinusoidal/Readme.md and test_domains/sinusoidal/Ocelote_Readme.md

[mstrout]

The README is currently too long and contains commentary that isn't necessary. Please move most of the material out of the README into another file, potentially one called "User Manual". The key points that need to be expressed within preferably the first screen of the README are as follows:

• The first two sentences saying where you got the test case are good. They used this test case with various parameters in some papers right? Please put in citations to those papers. [Kollet et al. 20XX](link to bottom of document with bibtex).
• The example of running the tcl script and an indication that you are assuming the user is doing this in bash.
• The setting of the parameters for the tcl script that mostly fill an ocelote node and the /bin/time results that indicate that is the case.
• Then have more details about the parameters to the tcl script.

I appreciate that you like the runner script. However, the reason why others don't is it adds one more level of thing they have to understand to run a simulation. This isn't a push button application. We have to understand all of the parameters and how they are being passed. Thus having a script is only useful when we have an established set of benchmarks that we want to run to performance benchmark. So please keep the runscript and documentation on it because we will probably use some aspects of it to set up the performance regression tests that Cathie wants, but it is overkill for single runs of the sinusoidal benchmark.

Also, put the PBS information in the Ocelote readme. I did not read the Ocelote README yet, but use a similar principle for the next draft of that. The principle is to provide your reader with the punchline as effectively and succinctly as possible. We are lucky if readers open the README file at all. No one likes to read documentation. If they can see what to do in under 30 seconds they will be really happy. If they have to read a book, they won't do it.

More detailed feedback:

• Put a one phrase blurb of where to find the various readme's in your top README.md.
• Put the memory in GB as well as KB when it is that many KBs.
• Put the execution time in hours as well as seconds when it is that many seconds.

[ian-bertolacci]

Ok, I will move a lot of this into a user-manual readme, and have a shorter main readme.

On a side note, I do not understand the perspective of wanting to run the tcl script directly?
From my perspective, running the simulation tcl script directly for benchmarking/testing purposes happens in < 1% of my runs, especially with this domain.
I'm not sure who these 'others' who disagree with using a runner script, but I us students who are running these on a daily/hourly basis do already use/make runner scripts to manage the execution and output of the benchmarks.

Maybe we should move this management into the tcl script itself?

When you say that this is not a push button application, do you mean that this is not meant to be a push-button application? or that, in its current form, it is not structured/behaving like a push-button application?
For the former, I would disagree. I've personally run this particular test domain almost a hundred thousand times, 20-100 times a day. I cannot conceive of a scenario where I would want (or could even allow) this to not be a push-button process.
Even with single runs of the domain, the output needs to be managed so that the output does not clutter the workspace or overwrite important data from previous runs.
For the latter, I would like to know more about how a user would need to know about how the parameters are being passed through.
If it helps, the parameters are passed to the tcl script in the same form and order they are passed to the run script.
This test case is particularly unique in that it takes in configuration arguments at all.
Most tcl scripts take in no arguments, or at most take in process topology configuration.
This being a synthetic, highly parameterizable domain, all of the scripts must take in quite a few arguments in order to be generally useful without being a pain to adapt to new configurations.