6

I am currently in the process of addressing the feedback received from a reviewer regarding a manuscript I've submitted. The primary concern raised is that there are "Too many simulation results presented in the manuscript. Almost five full pages of the manuscript are dedicated to sim-results, which is too much."

Have you encountered similar situations or have experience dealing with such feedback? The manuscript in question is a simulation-based work, totaling 17 pages. Given the nature of the research, a significant portion is dedicated to presenting simulation results.

I am unsure about the best approach to respond to the reviewer's comment. Should I consider condensing the results section, or is there a way to better justify the extensive presentation of simulation results in a simulation-focused manuscript?

5
  • 1
    Is it common in your field/target journal to have such long papers? Feb 25 at 19:31
  • 2
    Can you propose moving it to a supplemental data section? Feb 26 at 0:23
  • 9
    This is impossible to answer without seeing the paper. If I were reviewing a "simulation-based work" I would fully expect many pages of simulation results (it goes without saying). The question I have is how are these results presented (is it coherent or disjointed) and are they all germane to the article? I see no way of recommended you condense the results section without seeing the paper. In short, you are asking for specific advice without providing the requisite details. You are better off having a colleague read the paper and get actionable (and informed) feedback.
    – tnknepp
    Feb 26 at 14:11
  • 1
    Did the editor say they agree with the reviewer? Did the editor mention this issue at all? In principle you can disagree with a reviewer and not make a change they ask for, giving hopefully good reasons. It's the editor who decides in the end so it is important what they think. I have in such situations sometimes defended how I did things and written in the response that for the moment I think it's good as it is, but I would be willing to change this if the editor asks me to do so. Feb 26 at 15:43
  • Perhaps the overall length is the primary problem for the reviewer, not the amount of simulation results in isolation. Reading a 17 page paper is quite a hassle in a way ~10 page paper isn't. IMO effort goes roughly quadratically with number of pages. Also, does the paper introduce a new method or present results using existing one? These two papers need to be written differently. ((note that your own method you presented in another paper is existing one)) Feb 27 at 8:35

4 Answers 4

24

Think of the reviewer as a reader who will more carefully read your article than the average reader. (Notice that I haven't said that the reviewer reads your article carefully, but only that they are more careful than the average reader, which is a pretty low bar.) So, if a reviewer does not understand something about your paper, then you can be pretty sure any future reader will not get it either. So the reviewer is not necessarily right, but all her/his/their comments are valuable feedback on how a serious reader would perceive your article.

So you claim that this is a simulation-focused article, but apparently the reviewer did not understand your article that way. That could be the problem. In that case, the solution is to keep the results part unchanged, but to improve the introduction, or the structure of the article to make the nature of the article clearer.

Alternatively, the reviewer could have understood the nature of your article, but thought that many of the results are superfluous and could maybe be relegated to an appendix.

So in short, you need to figure out what the problem is, and then solve it. This can be complicated, because the problem may not be what the reviewer says.

0
12

My first impression is that the reviewer thinks you've presented a lot of results, but not all of them are interesting. So either explain why it's important to run the simulation for all the different input parameters you used, or remove the results that are uninteresting.

0
10

Of course, I do not know the concrete paper you talk about, and might be completely off.

But there is a phenomenon that I sometimes call an "experimental desert" (or, in your case, a "simulation desert"). Endless experiments with variations of this or that without the reader getting a clear idea or direction where things are going.

You may, as author, want to retain the results as archivary information somewhere, and the supplementary material is a good place to act as the archive of your results.

The main paper, however, should give a compelling argument what you set out to study and what you found out. If a sequence of experiments and their results are mentioned, make a stringent case for how the question from one study follows from the previous or adds to it substantially.

I see another possible interpretation of this reviewer comment, however. Namely, that you are in a field where they may expect more real-world experiments or else theoretical computations, rather than simulations which are neither one nor the other.

Which of these might be plausible depends on your field.

TL;DR: I see two possible cases: Either you string together too many results with no compelling line of argument. Or else, the reviewer expects real-world experiments or else analytical approaches as opposed to simulations. You need to reflect which of these it might be.

2
  • 5
    Regarding the part about a sequence of experiments and justifying the steps, it can also be a trap to present the work as a historical account of how it was done, rather than the best way to understand it in retrospect. Avoid a listing an exhaustive series of sequential actions with all the twists and turns along the way. It's often better to present the work as a whole keeping the conclusion in mind, rather than comprehensively describing everything you did - it is possible to say too much and distract from the important bits. Feb 26 at 19:58
  • 1
    @NuclearHoagie I agree. I did not mean to indicate actual history, but logical stringency of argument. Feb 26 at 21:55
4

You do not say say anything about the nature of your "results". My guess is that the problem is neither that there are too many experiments (simulations), nor that the results somewhat duplicate one another". Rather, I would guess that there is too little abstraction and that you have presented too much raw data that might better belong in either an appendix or, more likely, in a collection of supplementary material.

With that hypothesis (guess!) in mind, consider whether the results of the simulations can be abstracted in some way or presented in a way that makes the important issues clearer to the reader. Can you present any of the results in the form of graphics that highlight similarities and differences between the results of the simulations? Are there any descriptive statistics that are relevant to the results and which would summarize the results without overwhelming the reader?

Not the answer you're looking for? Browse other questions tagged .
https://academia.stackexchange.com/questions/207991/reviewers-concerns-about-excessive-simulation-results
academia.stackexchange.com
CC-MAIN-2024-18
182848
application/http; msgtype=response
sha1:7MGHNH545SFDOS4FQFMBATO2QC4HQGJO
<urn:uuid:050eea90-ed7d-4bc6-bb82-3181fcf40959>
2024-04-22T22:47:03Z
172.64.144.30
text/html
sha1:FFGPC67IRRQUNUAV72D36RRNPSMITEEX
<urn:uuid:fa396780-595b-494c-850c-59838fde1523>
https://academia.stackexchange.com/questions/207991/reviewers-concerns-about-excessive-simulation-results
response
<urn:uuid:ffe13c7c-bc77-49a0-b460-e9e36e6bf732>
isPartOf: CC-MAIN-2024-18
publisher: Common Crawl
description: Wide crawl of the web for April 2024
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-116
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.5-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/