I recommend granting 100K core-hours and 3T of space.
From: allocations-admins <allocations-admins-bounces@lcrc.anl.gov> on behalf of accounts@lcrc.anl.gov <accounts@lcrc.anl.gov>
Sent: Wednesday, August 2, 2017 10:53 PM
To: allocations-admins@lcrc.anl.gov
Subject: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
Sent: Wednesday, August 2, 2017 10:53 PM
To: allocations-admins@lcrc.anl.gov
Subject: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
Hello,
A new project on the LCRC cluster has been requested. Please forward
the information on to the LCRC Allocation sub-committee.
Applicant's name: Sheng Di
Applicant's institution: ANL
Applicant's division: MCS
Project Name: ECP_EZ
Project title: High Performance Lossy Compressor for Scientific Data
Associated funding: DOE
Other Systems: MIRA, Titan, and NERSC
Science: Develop a robust and effective production level lossy compressor for scientific data responding to ECP user needs.
computational methods: SZ compressor (prediction model + quantization + lossless compression)
Project description: Project description:
computational methods: SZ compressor (prediction model + quantization + lossless compression).
programming model: currently, it's serial program, and it can run in parallel with MPI program now. In the future, we'll support multi-thread version or so.
scalability issues: Good scalability because there are no or very limited communication cost across MPI ranks (also confirmed by our experiments).
experiments planned: Perform compression tests using a small number of nodes (such as 16 or less) in most of the time, and also need to submit the jobs each with 1024 cores some times.
software requirements: SZ compressor, ZFP compressor, Z-checker (https://github.com/CODARcode/Z-checker), MPICH.
technical details: We developed SZ compressor (prediction model + quantization + lossless compression), which is an error bounded lossy compressor. OUr EZ project is based on SZ compression model, and we need to optimize the compression quality for different ECP applications, including ECPSKY(HACC, NYX), EXAALT, EXAFEL, GAMESS. We also try to tailor the most efficient/effective compressors for APS researchers who are dealing with an extremely large volume of tomographical data every day.
The key features of SZ are listed below.
1. Compression: Input: a data set (or a floating-point array with any dimensions); Output: the compressed byte stream
Decompression: input: the compressed byte stream; Output: the original data set with the compression error of each data point being within a pre-specified error bound ∆.
2. SZ supports C, Fortran, and Java. It has been tested on Linux and Mac, with different architectures (x86, x64, ppc, etc.).
3. SZ supports two types of error bounds. The users can set either absolute error bound or value-range based relative error bound, or a combination of the two bounds （with operator AND or OR).
The absolute error bound (denoted δ) is a constant, such as 1E-6. That is, the decompressed data Di′ must be in the range [Di − δ,Di + δ], where Di′ is referred as the decompressed value and Di is the original data value.
As for the relative error bound, it is a linear function of the global data value range size, i.e., ∆=λr, where λ(∈(0,1)) and r refer to error bound ratio and range size respectively. For example, given a set of data, the range size r is equal to max (Di )− min (Di ), and the error bound can be written as λ( max (Di )− min (Di )). The relative error bound allows making sure that the compression error for any data point must be no greater than λ×100 percentage of the global data value range size.
4. SZ supports three compression modes (similar to Gzip): SZ_BEST_SPEED, SZ_DEFAULT_COMPRESSION, and SZ_BEST_COMPRESSION. SZ_BEST_SPEED results in the fastest compression. The best compression factor will be reached when using SZ_BEST_COMPRESSION and Gzip_BEST_COMPRESSION meanwhile. SZ_DEFAULT_COMPRESSION is a tradeoff between the SZ_BEST_SPEED and SZ_BEST_COMPRESSION.
Performance achieved: Compression rate is about 100+MB/s on one core, and the compression ratio is from 4:1 to 100+:1, depending on the data set.
expected number of project members: 4-10.
Industry partnership:
Project URL: http://www.mcs.anl.gov/~shdi/download/sz-download.html
Requested allocation: 392000
Q1: 0
Q2: 0
Q3: 0
Q4: 392000
Justification: 392,000 =
16 cores/node * (128+64+32+16+8+4+2+1 nodes) *
1 hour * 8 runs * 4 applications * 4 compressors
+ 320 hours development.
Please kindly note that in our experiment, we need to read the data from the parallel file system and also write the compressed data back to the PFS. So, I/O cost often leads our job take a long time. Moreover, enough core-hours is also important to our research.
We need to perform the compression-based experiments for multiple applications, each of which may take a long time to read, compress/decompress, and write data. Suppose I run 8 experiments for each application, then there will be 40 runs for 4~5 applications in total. Note that we need to run different scales to observe the scalability and efficiency of the compressions (with 16 cores through 2048 cores), and also need to compare 3~5 different compressors/solutions in our experiments.
I reduced a bit the request as above, and I believe this should be enough through Sep 30.
Storage requirements: expected space: 5TB
Our project (ECP-EZ) aims to develop various compressors for different HPC applications. Some typical applications include HACC, EXAALT, EXAFEL, APS, CESM climate simulation, GAMESS, etc. In fact, each of the above application's data size may easily exceed 1TB. For example, the sample data generated by CESM-ATM has 40+ snapshots, and each snapshot has 100+ variables and many of them are 3D single-precision floating-point arrays (26*2800*3600), such that the total data size is 1.6TB. Another example is HACC application. Each snapshot has 64 sub-files each being of about 700MB. There are 100 snapshots in total. For now, we can use 20 snapshots for our current research, then the total size already reaches 768GB. We still need more space to store the compression results (such as compressed data files by different compressors). Since HACC data are very hard to get high compression ratios, the total storage size may easily exceed 2 TB.
The requester has used undetermined amount hours of their initial startup project.
In addition to approving an initial amount, please specify a Category
and Subcategory for this project. For a list of the current selection
of approved categories, please see:
https://wiki.lcrc.anl.gov/wiki/Processes/Categories
Once the Allocation committee has approved the project, please go to
the Project Management page to create it:
https://accounts.lcrc.anl.gov/projects.php
Thank You,
The LCRC Accounts System
A new project on the LCRC cluster has been requested. Please forward
the information on to the LCRC Allocation sub-committee.
Applicant's name: Sheng Di
Applicant's institution: ANL
Applicant's division: MCS
Project Name: ECP_EZ
Project title: High Performance Lossy Compressor for Scientific Data
Associated funding: DOE
Other Systems: MIRA, Titan, and NERSC
Science: Develop a robust and effective production level lossy compressor for scientific data responding to ECP user needs.
computational methods: SZ compressor (prediction model + quantization + lossless compression)
Project description: Project description:
computational methods: SZ compressor (prediction model + quantization + lossless compression).
programming model: currently, it's serial program, and it can run in parallel with MPI program now. In the future, we'll support multi-thread version or so.
scalability issues: Good scalability because there are no or very limited communication cost across MPI ranks (also confirmed by our experiments).
experiments planned: Perform compression tests using a small number of nodes (such as 16 or less) in most of the time, and also need to submit the jobs each with 1024 cores some times.
software requirements: SZ compressor, ZFP compressor, Z-checker (https://github.com/CODARcode/Z-checker), MPICH.
 |
github.com
|
|
technical details: We developed SZ compressor (prediction model + quantization + lossless compression), which is an error bounded lossy compressor. OUr EZ project is based on SZ compression model, and we need to optimize the compression quality for different ECP applications, including ECPSKY(HACC, NYX), EXAALT, EXAFEL, GAMESS. We also try to tailor the most efficient/effective compressors for APS researchers who are dealing with an extremely large volume of tomographical data every day.
The key features of SZ are listed below.
1. Compression: Input: a data set (or a floating-point array with any dimensions); Output: the compressed byte stream
Decompression: input: the compressed byte stream; Output: the original data set with the compression error of each data point being within a pre-specified error bound ∆.
2. SZ supports C, Fortran, and Java. It has been tested on Linux and Mac, with different architectures (x86, x64, ppc, etc.).
3. SZ supports two types of error bounds. The users can set either absolute error bound or value-range based relative error bound, or a combination of the two bounds （with operator AND or OR).
The absolute error bound (denoted δ) is a constant, such as 1E-6. That is, the decompressed data Di′ must be in the range [Di − δ,Di + δ], where Di′ is referred as the decompressed value and Di is the original data value.
As for the relative error bound, it is a linear function of the global data value range size, i.e., ∆=λr, where λ(∈(0,1)) and r refer to error bound ratio and range size respectively. For example, given a set of data, the range size r is equal to max (Di )− min (Di ), and the error bound can be written as λ( max (Di )− min (Di )). The relative error bound allows making sure that the compression error for any data point must be no greater than λ×100 percentage of the global data value range size.
4. SZ supports three compression modes (similar to Gzip): SZ_BEST_SPEED, SZ_DEFAULT_COMPRESSION, and SZ_BEST_COMPRESSION. SZ_BEST_SPEED results in the fastest compression. The best compression factor will be reached when using SZ_BEST_COMPRESSION and Gzip_BEST_COMPRESSION meanwhile. SZ_DEFAULT_COMPRESSION is a tradeoff between the SZ_BEST_SPEED and SZ_BEST_COMPRESSION.
Performance achieved: Compression rate is about 100+MB/s on one core, and the compression ratio is from 4:1 to 100+:1, depending on the data set.
expected number of project members: 4-10.
Industry partnership:
Project URL: http://www.mcs.anl.gov/~shdi/download/sz-download.html
Requested allocation: 392000
Q1: 0
Q2: 0
Q3: 0
Q4: 392000
Justification: 392,000 =
16 cores/node * (128+64+32+16+8+4+2+1 nodes) *
1 hour * 8 runs * 4 applications * 4 compressors
+ 320 hours development.
Please kindly note that in our experiment, we need to read the data from the parallel file system and also write the compressed data back to the PFS. So, I/O cost often leads our job take a long time. Moreover, enough core-hours is also important to our research.
We need to perform the compression-based experiments for multiple applications, each of which may take a long time to read, compress/decompress, and write data. Suppose I run 8 experiments for each application, then there will be 40 runs for 4~5 applications in total. Note that we need to run different scales to observe the scalability and efficiency of the compressions (with 16 cores through 2048 cores), and also need to compare 3~5 different compressors/solutions in our experiments.
I reduced a bit the request as above, and I believe this should be enough through Sep 30.
Storage requirements: expected space: 5TB
Our project (ECP-EZ) aims to develop various compressors for different HPC applications. Some typical applications include HACC, EXAALT, EXAFEL, APS, CESM climate simulation, GAMESS, etc. In fact, each of the above application's data size may easily exceed 1TB. For example, the sample data generated by CESM-ATM has 40+ snapshots, and each snapshot has 100+ variables and many of them are 3D single-precision floating-point arrays (26*2800*3600), such that the total data size is 1.6TB. Another example is HACC application. Each snapshot has 64 sub-files each being of about 700MB. There are 100 snapshots in total. For now, we can use 20 snapshots for our current research, then the total size already reaches 768GB. We still need more space to store the compression results (such as compressed data files by different compressors). Since HACC data are very hard to get high compression ratios, the total storage size may easily exceed 2 TB.
The requester has used undetermined amount hours of their initial startup project.
In addition to approving an initial amount, please specify a Category
and Subcategory for this project. For a list of the current selection
of approved categories, please see:
https://wiki.lcrc.anl.gov/wiki/Processes/Categories
Once the Allocation committee has approved the project, please go to
the Project Management page to create it:
https://accounts.lcrc.anl.gov/projects.php
Thank You,
The LCRC Accounts System