August 2017 - Allocations-admins - mailman3.cels.anl.gov

New LCRC report submitted for Irridates
by support＠lcrc.anl.gov 10 Aug '17

10 Aug '17

Full project report at https://accounts.lcrc.anl.gov/reporting/project/2017/?project=Irridates

1 0

[LCRC Accounts] Yearly Allocation Request for radix
by accounts＠lcrc.anl.gov 08 Aug '17

08 Aug '17

Hello, A yearly allocation for the LCRC cluster has been requested with the following updated information: Submitter/PI: Pavan Balaji Project Name: radix Division: MCS Project title: Scalable Parallel System Software Associated funding: DoE core, SciDAC, NSF, FASTOS Other Systems: breadboard (unlimited) ALCF Mira/Cetus/Tukey (50,000,000 cpu hours) Science: Our mission is to develop the technologies required to dramatically increase the productivity of scientists developing applications for parallel supercomputers. The focus is fourfold: integration of parallel programming tools, reuse of parallel program components, development of scientific computing toolkits and portable libraries, and exploration of requirements of future parallel computers. Project description: This project aims at optimizing MPI usage in deep learning frameworks. A number of jobs in our previous allocation were killed because of network issues, which we report to LCRC. We are requesting for more core hours to help us complete our experiments. We have already submitted two papers on this work and are working on a third paper. Industry partnership: Project URL: http://www.mcs.anl.gov/group/pmrs/ Current FY Hours Used: undetermined amount New FY Requested allocation: 100000 Q1: 0 Q2: 0 Q3: 0 Q4: 100000 Justification: Storage requirements: No large storage requirements, since the data generated will not be persistent. Thank You, The LCRC Accounts System

1 0

Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
by Roberts, John E. 04 Aug '17

04 Aug '17

This project has been created. Thanks! -John From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of "Aithal, Shashikant M." <aithal(a)cels.anl.gov> Reply-To: LCRC Allocations Admins <allocations-admins(a)lcrc.anl.gov> Date: Thursday, August 3, 2017 at 10:45 AM To: LCRC Allocations Admins <allocations-admins(a)lcrc.anl.gov> Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ If we can give them 5 TB then let us do so. I had very specifically asked them the typical size of a file and how many such files they would produce but the resubmitted proposal did not have any information. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of Roberts, John E. <jeroberts(a)anl.gov> Sent: Thursday, August 3, 2017 10:41 AM To: LCRC Allocations Admins Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ Shashi, The hours sound fine, but this person emailed us and were pretty adamant on needing the 5TB. Do you want to communicate with them more or should we just give the 5? Thanks! -John From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of "Aithal, Shashikant M." <aithal(a)cels.anl.gov> Reply-To: LCRC Allocations Admins <allocations-admins(a)lcrc.anl.gov> Date: Thursday, August 3, 2017 at 7:57 AM To: "allocations-admins(a)lcrc.anl.gov" <allocations-admins(a)lcrc.anl.gov> Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ I recommend granting 100K core-hours and 3T of space. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of accounts(a)lcrc.anl.gov <accounts(a)lcrc.anl.gov> Sent: Wednesday, August 2, 2017 10:53 PM To: allocations-admins(a)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. [https://avatars0.githubusercontent.com/u/22968668?v=4&s=400]<https://github.com/CODARcode/Z-checker> CODARcode/Z-checker<https://github.com/CODARcode/Z-checker> github.com Z-checker - a library to characterize the data and check the compression results of lossy compressors 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

1 0

Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
by Aithal, Shashikant M. 03 Aug '17

03 Aug '17

If we can give them 5 TB then let us do so. I had very specifically asked them the typical size of a file and how many such files they would produce but the resubmitted proposal did not have any information. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of Roberts, John E. <jeroberts(a)anl.gov> Sent: Thursday, August 3, 2017 10:41 AM To: LCRC Allocations Admins Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ Shashi, The hours sound fine, but this person emailed us and were pretty adamant on needing the 5TB. Do you want to communicate with them more or should we just give the 5? Thanks! -John From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of "Aithal, Shashikant M." <aithal(a)cels.anl.gov> Reply-To: LCRC Allocations Admins <allocations-admins(a)lcrc.anl.gov> Date: Thursday, August 3, 2017 at 7:57 AM To: "allocations-admins(a)lcrc.anl.gov" <allocations-admins(a)lcrc.anl.gov> Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ I recommend granting 100K core-hours and 3T of space. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of accounts(a)lcrc.anl.gov <accounts(a)lcrc.anl.gov> Sent: Wednesday, August 2, 2017 10:53 PM To: allocations-admins(a)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. [https://avatars0.githubusercontent.com/u/22968668?v=4&s=400]<https://github.com/CODARcode/Z-checker> CODARcode/Z-checker<https://github.com/CODARcode/Z-checker> github.com Z-checker - a library to characterize the data and check the compression results of lossy compressors 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

1 0

Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
by Roberts, John E. 03 Aug '17

03 Aug '17

Shashi, The hours sound fine, but this person emailed us and were pretty adamant on needing the 5TB. Do you want to communicate with them more or should we just give the 5? Thanks! -John From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of "Aithal, Shashikant M." <aithal(a)cels.anl.gov> Reply-To: LCRC Allocations Admins <allocations-admins(a)lcrc.anl.gov> Date: Thursday, August 3, 2017 at 7:57 AM To: "allocations-admins(a)lcrc.anl.gov" <allocations-admins(a)lcrc.anl.gov> Subject: Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ I recommend granting 100K core-hours and 3T of space. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of accounts(a)lcrc.anl.gov <accounts(a)lcrc.anl.gov> Sent: Wednesday, August 2, 2017 10:53 PM To: allocations-admins(a)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. [https://avatars0.githubusercontent.com/u/22968668?v=4&s=400]<https://github.com/CODARcode/Z-checker> CODARcode/Z-checker<https://github.com/CODARcode/Z-checker> github.com Z-checker - a library to characterize the data and check the compression results of lossy compressors 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

1 0

Re: [allocations-admins] [LCRC Accounts] Project Request: ECP_EZ
by Aithal, Shashikant M. 03 Aug '17

03 Aug '17

I recommend granting 100K core-hours and 3T of space. ________________________________ From: allocations-admins <allocations-admins-bounces(a)lcrc.anl.gov> on behalf of accounts(a)lcrc.anl.gov <accounts(a)lcrc.anl.gov> Sent: Wednesday, August 2, 2017 10:53 PM To: allocations-admins(a)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. [https://avatars0.githubusercontent.com/u/22968668?v=4&s=400]<https://github.com/CODARcode/Z-checker> CODARcode/Z-checker<https://github.com/CODARcode/Z-checker> github.com Z-checker - a library to characterize the data and check the compression results of lossy compressors 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

1 0

[LCRC Accounts] Project Request: ECP_EZ
by accounts＠lcrc.anl.gov 02 Aug '17

02 Aug '17

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

1 0