Technical Papers FAQs

FAQ Table of Contents

1. New at SC12 Tech Papers
2. State of Practice (SOP)
3. Rebuttals to reviews (based on the SIGGRAPH rebuttal process)
4. Plagiarism (including self-plagiarism)
5. Conflict of Interest Guidelines

1. New at SC12 Tech Papers

Question: What is new at SC12 for technical papers?
Answer: Three major elements have been introduced to highlight the topical areas of contributions, to streamline the review process and to enhance the quality of accepted submissions.

  • We have reorganized topical areas from SC11 and introduced new ones for broad, yet focused coverage of high performance computing. Authors may submit high-quality, original research contributions along the following topical areas: 1. Algorithms; 2. Applications; 3. Architectures and Networks; 4. Clouds and Grids; 5. Performance, Energy, and Dependability; 6. Programming Systems; 7. Storage, Visualization, and Analytics; 8. System Software; 9. State of Practice.
  • The "State of Practice," originally introduced as a separate event in the SC 11 Technical Program, has now been integrated into technical papers as the ninth topical area. Authors may submit high-quality contributions with new and generalizable insights that can advance the practice of high performance computing, including facilities, services and systems. See Section 2 below for more information.
  • We have introduced a rebuttal process to enhance the rigor of peer-review to determine acceptance of submissions. Authors may address factual errors in the reviews and answer specific questions posed by reviewers during the review rebuttal period. See Section 3 below for more information.

Q. What are the main review criteria for acceptance?
A. We will focus on originality, technical soundness, presentation quality, timeliness, impact, and relevance to SC. These criteria will be applied uniformly across the nine topical areas to drive the acceptance of contributions that measurably improve upon the state of the art along dimensions that are relevant for SC. Consequently, for the State of Practice, they will be tailored to value the new and generalizable insights as gained from the practice of high performance computing (see Section 2 below for further information).

Q. Is it mandatory for authors to select the primary area of their contribution?
A. Yes. Authors must indicate the primary area of contribution from the nine topical areas above. We understand that contributions may straddle more than one area and in such cases, we encourage authors to indicate a secondary area of contribution.

Q: What do you expect the acceptance rate to be?
A. With our focus on quality and the observed trend towards substantial increases in submissions from year to year, we expect a 20 percent acceptance rate for SC12.

Q: Will there be best paper awards?
A. Yes. Awards will be given for Best Paper and Best Student Paper. Extended versions of papers selected as finalists for the Best Paper and Best Student Paper Awards may be published in the journal Scientific Programming.

2. State of Practice (SOP)

Q: Will my SOP paper count as a regular SC paper so that I can claim the same impact factor, etc.?
A: Yes, that is the whole point of making the SOP a part of the Technical Papers program. A SOP paper is just as good as any other paper in the Technical Papers program, and the entire Technical Papers Committee collectively endorses its academic quality.

Q: Who will review the SOP papers?
A: As with any other tech paper, they will be reviewed by a set of tech papers committee members who are experts in the field and will comprise the "SOP area". In fact, SOP is one of the 9 areas for tech papers we have this year.

Q: It is not clear to me whether my paper should be submitted to the SOP area, or another area. How do I decide?
A: We realize there is a fine line here depending on the paper topic. For example, if it is a new compiler algorithm it would likely land in one of the software areas; but, a performance evaluation of new supercomputer might be a SOP paper, or may belong in another area such as architecture or performance. We do have the authors specify the primary and secondary submission areas, and for papers self-categorized to be in SOP, the relevant area chairs will take a careful look at it to recommend which area it would be appropriate to be in, but ultimately we plan on making it your decision to classify it as a SOP paper.

Q: I am concerned that if the standards for SOP are the same as for the regular papers, the SOP papers will be rejected for not being sufficiently academically rigorous. How will you handle this?
A: Although SOP papers will be reviewed under the same rigorous academic peer review process as the papers in other areas, e.g., careful reviews and face-to-face discussions by anonymous reviewers, the acceptance criteria will be tailored to value the new and generalizable insights as gained from: experiences of a particular instance in HPC machines/operations/applications/benchmarks, overall analysis of the status quo of a particular metric of the entire field; historical reviews of the progress of the field, etc.

Such types of papers are actually common in other academic disciplines, including branches of computer science. For example, software engineering highly values the "experience papers" of particular frameworks and methodologies; human-computer interaction embodies numerous works on analysis of human behavior given a particular interface; Social science is all about collecting data on social phenomenon and providing meaningful insights based on their statistical analysis.

Q: At the same time, if you apply less rigor to the SOP papers won't the prestige of the entire conference suffer?
A: We do plan to apply rigor in a sense that, although we will not necessarily require the particular technology that would be the subject matter of the paper to be novel, we do require that the insights gained to be novel and useful. That is to say, papers with contents of the nature "this is how we do things here" without new, generalizable insights provided to the peers will likely have low chance of acceptance.

Q: Will the SOP papers be part of the optional rebuttal process?
A: Yes, it will be part of the rebuttal process, just as any other technical paper.

Q: I know that a paper might be switched to a different area other than the requested primary area for review. But what if I submit a SOP paper and it gets switched to a non-SOP area, or vice versa? Aren’t the “standard” papers and SOP papers being reviewed under somewhat different criteria, and that might work to my disadvantage?
A: In general, the area chairs will work to collectively to determine if a paper whose primary or secondary area is designated as SOP would actually be suitable to be evaluated as such. If we determine that a submission whose primary area is SOP is more suitable for the secondary area or vice versa, we will ask the principal author to confirm if such a switch would be OK or not. The author has every right to approve or refuse the switch and we will abide by the author's decision.

3. Rebuttals to reviews (based on the SIGGRAPH rebuttal process)

Q: What is a rebuttal?
A: The rebuttal is for addressing factual errors in the reviews and for answering specific questions posed by reviewers. There will be an opportunity to upload a rebuttal to address factual errors and specific questions in the reviews via the online submission system during a rebuttal period. Then, authors may upload up to 750 words of text in the system before the rebuttal deadline. The rebuttals will be read by the referees and factored into the discussion leading up to the acceptance decisions made at the Technical Papers Committee meeting.

Q: Should I write a rebuttal?
A: Any author may upload a rebuttal. The choice of whether to submit one and how much time to spend on it is up to each author. As a general guideline, submitting a rebuttal is a good idea if the paper seems to have a chance of being accepted, and if the reviews contain errors that can be corrected or specific questions than can be answered with short textual descriptions.

Q: What should be included in the rebuttal?
A; The rebuttal is for addressing factual errors in the reviews and for answering specific questions posed by reviewers. The rebuttal can also help clarify the merits and novelty of the paper with respect to prior work, if it is felt that the reviewers misunderstood the paper’s contributions and scope. It is very limited in length, and must be self-contained. It cannot, for instance, contain URLs to external pages.

Q: Now that I've read the reviews of my paper, I see much better how to organize it so it will be clear to the reader. Can I do this reorganization and upload the new version during the rebuttal period?
A: No. The rebuttal period is only for addressing factual errors in the reviews, not for getting revised text into the review process. The committee members will have only a short time in which to read and act on your rebuttal, and it must be short and to the point. Hence, it will be limited to 750 words of text.

Q: Between paper submission and the rebuttal period, we've gotten some really cool new results for our paper. Can I upload those results during the rebuttal period? I'm sure that they will make the reviewers realize the importance of our approach.
A: No. The rebuttal period is for addressing factual errors in the reviews, not for getting new results into the review process.

Q: Reviewer #4 clearly didn't read my paper carefully enough. Either that or this reviewer doesn't know anything about the field! How should I respond during the rebuttal period?
A: We've all received reviews that made us angry, particularly on first reading. The rebuttal period is short and doesn't allow for the cooling-off period that authors have before they write a response to a journal review. As a result, authors need to be particularly careful to address only factual errors or reviewer questions in the rebuttals rather than letting their emotions show through.

Please don't say: "If reviewer #4 had just taken the time to read my paper carefully, he would have realized that our algorithm was rotation invariant." Instead say: "Unfortunately, Section #4 must not have been as clear as we had hoped because Reviewer #4 didn't understand that our algorithm was rotation invariant and he was therefore skeptical about the general applicability of our approach. Here is a revised version of the second paragraph in Section 4, which should clear up this confusion."

Remember that your rebuttal gets sent to all the reviewers; you don't want to offend or alienate them. In particular, you want the reviewers to come out of the rebuttal process sufficiently enthused about your paper to champion it at the committee meeting, and if the paper is accepted and needs revision, then you want them to feel sufficiently comfortable with you as an author that they are willing to "shepherd" the paper through the revision process.

Q: I uploaded a rebuttal, but got no feedback. How can I be sure the reviewers received and actually read my rebuttal?
A: If you can view your rebuttal comments in the online review system, so can your reviewers. Rest assured that rebuttal information is considered and can be very helpful in the selection process.

4. Plagiarism (including self-plagiarism)

Q: What is plagiarism?
A: Please see the IEEE website for more information on identifying plagiarism.
Identifying plagiarism:

Plagiarism FAQ:

5. Conflict of Interest Guidelines

Q: What are the SC12 guidelines for Conflicts of Interest (COI)?
A: A potential conflict of interest occurs when a person is involved in making a decision that 1) could result in that person, a close associate of that person, or that person’s company or institution receiving significant financial gain, such as a contract or grant, or 2) could result in that person, or a close associate of that person, receiving significant professional recognition, such as an award or the selection of a paper, work, exhibit, or other type of submitted presentation.

Authors and Technical Papers Committee members will be given the opportunity to list the potential conflicts during the submission and review process. Technical Papers Committee chairs and area chairs will make every effort to avoid assignments that have a potential COI.

For SC12, we define a conflict of interest as:

  1. Your Ph.D. advisors, post-doctoral advisors, Ph.D. students, and post-doctoral advisees forever.
  2. Family relations by blood or marriage, or equivalent (e.g., a partner), forever.
  3. People with whom you collaborated in the past five years. Collaborators include
    1. co-authors on an accepted/rejected/pending research paper,
    2. co-PIs on an accepted/rejected/pending grant,
    3. those who fund your research,
    4. researchers whom you fund, or
    5. researchers who you are actively collaborating with on a project.
  4. People who were employed by, or a student at, your primary institution(s) in the past five years, or people who are active candidates for employment at your primary institution(s).
  5. Close personal friends or others with whom you believe a conflict of interest exists.

Note that “service” collaborations, such as writing a DOE, NSF, or DARPA report, or serving on a program committee, are not a conflict-of-interest per se.

Other possible conflicts can exist, and you should contact the Technical Papers chairs for questions or clarification on any of these issues.