-
-
Save tkphd/29e7c07825e818ad62de337d395cf5df to your computer and use it in GitHub Desktop.
--- | |
metadata: | |
# Describe the runtime environment | |
summary: MPI parallel workstation benchmark with MMSP, periodic domain | |
author: Trevor Keller | |
email: trevor.keller@nist.gov | |
date: Wed, 04 Jan 2017 19:30:31 -0500 | |
hardware: | |
# Required hardware details | |
architecture: x86_64 | |
cores: 6 | |
# Optional hardware details | |
details: | |
- name: clock | |
value: 3600.078 | |
units: MHz | |
software: | |
name: Mesoscale Microstructure Simulation Project (MMSP) | |
url: https://github.com/mesoscale/mmsp | |
version: 4 | |
repo: | |
url: https://github.com/mesoscale/mmsp/tree/develop | |
version: 8f29eb47146b9fbbdcd17b08d12e06fceb3ed728 | |
branch: develop | |
implementation: | |
end_condition: time limit | |
repo: | |
url: https://github.com/mesoscale/MMSP-spinodal-decomposition-benchmark/tree/master/periodic/ | |
version: 1de1abe6dc9a7d7251ec44e6ee18db907f84543e | |
branch: master | |
details: | |
- name: mesh | |
value: uniform rectilinear | |
- name: numerical_method | |
value: explicit finite difference | |
- name: compiler | |
value: GNU mpic++ | |
- name: parallel_model | |
value: MPI | |
benchmark: | |
# Specify the problem | |
model: spinodal decomposition | |
boundary_condition: periodic | |
id: 1a | |
domain: | |
- name: geometry | |
value: square | |
- name: origin | |
value: [0, 0] | |
- name: size | |
value: [200, 200] | |
- name: resolution | |
value: [1, 1] | |
data: | |
# Gather simulation output | |
- name: timestep | |
value: 0.00195312 | |
- name: free energy | |
# JSON list of {time, energy} pairs | |
value: [{"x":0, "y":319.094}, {"x":1.95312, "y":318.909}] | |
- name: run time | |
value: 65.48 | |
unit: seconds | |
- name: memory usage | |
value: 27280 | |
unit: KB |
This is making more sense.
code
should besoftware
for the framework, andrepo
should becode
for the implementation.- The benchmarks are called by name on the Web site, you have to dig a bit to find a number and letter. It would make sense to Hackathon participants, but not everyone will be among those. Is a
number+letter
sufficient identification, or should we ask for both an ID and a name for redundancy in the parsing stage? name: size
andname: spacing
are written by the code at runtime, hencedata
in my opinion. We know what we want the code to do, but it's good to make sure the code understood and reports the right settings.solver
probably does belong inmeta_data
, buttimestep
is computed at runtime, could change, and isdata
.architecture
should bex86_64
,ARM
,PowerPC
, etc., not necessarily the make and model of the CPU.
Thanks, very nice, I think the specification of the benchmark is very good.
I think that
- name: origin
value: [0, 0]
- name: size
value: [200, 200]
should go in the benchmark specification and I also don't think we need origin
. It stuff that's know beforehand. Agreed on timestep
, max timestep', 'min timestep
etc should definitely be in data.
I put the origin
and size
in a list of domain details, which should be considered optional. If a pedant wants to include it, there's no harm, right? Same for a lot of the other details, such as clock speed, compiler, numerical method... Only important to someone who's curious enough about particulars to open one of these files.
I'm trying to use the vega data format for free energies. It passes the YAML lint test, but I'm still not 100% sure this is proper syntax. I have a sneaking suspicion that the entire data section belongs in a JSON block, but we can iterate on that.
The pieces are now in a different order since I have the governor script writing metadata, initialization code writing the benchmark, and the timestepper writing the data section. I believe this is irrelevant to the YAML parser, and it makes automatic generation of meta.yml easy (on GNU/Linux systems).
A few things:
name
andemail
will go in themetadata
segmentname: domain
data item is redundant as we know which example this isdata
segment is for data generated by the simulation -- things needed to specify the problem go in thebenchmark
section, while things required to specify the code and run time environment go in themeta_data
section.solver
goes in the metadata segment as it's knows at the start even better in thecode
segment` as it is unique to MMSPtimestep
if it's know beforehand