CFP and Submissions

HPCMASPA 2020 welcomes submissions of original work not previously published nor under review by another conference or journal. All categories of papers will be peer-reviewed and published in proceedings arranged for by IEEE Cluster.


EXTENDED DEADLINES!

Categories: (All dates AOE)

1. Technical Papers: (8 pages+ 2 additional reference only pages)

Addressing completed research, best practice whitepapers, and other in-depth research and experience, etc.

  • Submissions Open: Jun 5

  • Abstracts: Jun 19 WAIVED

  • Papers: Jun 26 Jul 6

  • Notification: Jul 17 Jul 20

  • Camera Ready: Aug 14

2. Short and Work in Progress Papers: (4 pages + 1 additional reference only page) At least one session will be dedicated to Short/WIP papers encouraging interactive audience discussion.

  • Submissions Open: Jul 18 Jul 20

  • Papers: Jul 24 Jul 27

  • Notification: Jul 31 Aug 3

  • Camera Ready: Aug 14

Submissions:

  • Web-based submissions through EasyChair.

  • PDFs only.

  • Submissions must be compliant with the format used by IEEE Cluster. LaTex and Word templates can be found here.

  • NO additional pages can be purchased for this workshop.

  • Submissions must be in English.

  • Submission implies the willingness of at least one of the authors to register and present the work associated with submission in accordance with the policies of IEEE Cluster (virtual/remote participation policies will be posted soon).

  • Submissions will be evaluated on their technical soundness, significance, presentation, originality of work, and relevance and interest to the workshop scope.

  • No additional pages can be purchased.




Topics:

Including, but not limited to:

Data collection, transport, and storage

  • Monitoring methodologies and results for all HPC system components and support infrastructure (e.g., compute, network, storage, power, facilities)

  • Design of systems and frameworks for HPC monitoring which address HPC requirements such as:

    • Extreme scalability

    • Run time data collection and transport

    • Analysis on actionable timescales

    • Feedback on actionable timescales

    • Minimal application impact

  • Extraction and evaluation of resource utilization and state information from current and next generation components

Analysis of large-scale data and system information

  • Extraction of meaningful information from raw data, such as system and resource health, contention, or bottlenecks

  • Methodologies and applications of analysis algorithms on large scale HPC system data

  • Visualization techniques for large scale data (addressing size, timescales, presentation within a meaningful context)

  • Evaluation of correlative relationships between system state and application performance via use of monitored system data

Response to and utilization of analysis results and insights

  • Mechanisms for feedback and response to applications and system software (e.g., informing schedulers, down-clocking CPUs)

  • HPC application design and implementation that take advantage of monitored system data (e.g., dynamic task placement or rank-to-core mapping)

  • System-level and Job-level feedback and responses to monitored system data

  • Job scheduling and allocation based on monitored system information (e.g. contention for storage or network resources)

  • Integration of system and facilities data for system and site operational decisions

  • Use of monitored system data for evaluation of future systems specifications and requirements

  • Use of monitored system data for validation of systems' simulations

Experience reports and System operations

  • Design and implementation of monitoring tools as part of HPC operations

  • Experiences with monitoring and analysis methodologies and tools in HPC applications

    • Note this is not meant to include application performance analysis tools such as open|speedshop or craypat

  • Experiences with monitoring and analysis tools for HPC systems specification/selection

  • Sub-optimal approaches taken because there currently isn’t another way (include associated gap analysis)

  • How not to do it, with explanations, benchmarks, or analysis of code to save the rest of us from trying it again