Reviewer's report: Dear editor, authors, I have read and partly validated the data for the paper “Shared data for IMRT optimization research: the CORT dataset” by David Craft et. al.

The background for this work is to provide the radiotherapy community an open dataset to facilitate comparisons of optimisation algorithms. So far, no relevant sets were available to the public (due to many reasons), and interinstitutional comparisons between different optimisation algorithms were hard to make.

For non-radiotherapy institutions it is a threshold to obtain real data in order to test their ideas. By providing this dataset, the authors facilitate the development of high-quality algorithms, and hopefully also the quality of future publications on the subject. I only have a few comments on the paper, and some suggestions for improvement and extension. I have partially checked the provided data for the 4 patients, and successfully ran the series of code snippets from the paper for the liver case. No inconsistensies were found.

Major Compulsory Revisions:

none

Minor Essential Revisions:

1. Is it the idea to extend the dataset (by submission of others), and aim for a large open-access database with many cases? Or give the “advice” of including one or more patients from this dataset in future publications on optimisation? Or both? I can understand if this was strategically left out, but a pointer could make the paper stronger.

2. A bit further down on page 3, it is mentioned that geometric beamlet information is not necessary for the basic types of IMRT optimisation. I argue against that: fluence map optimisation is only reasonable when some smoothing is included in the optimisation. To construct constraints/objectives for smoothing, the geometrical information of the beamlets is required. See for example the images in http://dx.doi.org/10.1088/0031-9155/51/14/019 .

3. Page 5, section Prostate: add spaces between “1cm x 1cm”. Similar on page6, right above the figure.

4. Page 9, section Fluence map optimization. Here it is stated that there is “no work that proves that non-convex objective functions are needed to produce high quality treatment plans”. This is a firm statement, and true, when speaking purely about objective (cost) functions used as objective. In the current text, it is not clear whether the authors mean the cost functions in general, or cost functions used as objectives. More elaborate: for constraints, non-convex objective (cost) functions do ease the generation of high-quality treatment plans. A hard constraint commonly used in liver SBRT is that at least 700 cc of the liver should receive a dose less than 15 Gy. As this is a constraint, and often a limiting one, an EUD or other function is not an efficient substitute.

5. Page 13: there is an extra space between “section” and the “.”

6. Appendix A: the beamlet grid orientation can be explained more clear. Instead of mentioning “superior-inferior”, (also) mention “negative z direction in patient coordinates”, to ease understanding for users outside the medical field.

7. In CTVOXEL_INFO.txt, also include the beamlet resolution, or include it in the BEAMINFO files.

8. It is not clear to me if the central beamlet coordinate (0,0) position passes through a beamlet, or in between. That is, if the grid has odd or even rows/columns. From the data it seems to be an even grid, but it is better to have it explicitly documented.

9. Also on the beamlets: I cannot find documented how the beamlets are indexed. The _BEAMINFO files contain the x- and y-coordinates of each beamlet, but it does not contain a description of which beamlet corresponds to which column of D. An indexed BEV representation is convenient to have (at least for smoothing). I did this using the following code: % Converting beamlet information into a matrix % Resolution of the beamlets in cm bres_x = 1; bres_y = 1; % General MLC field, 40 x 40 cm MLC = zeros(40/bres_x, 40/bres_y); centre_x = size(MLC, 1)/2bres_x; centre_y = size(MLC, 2)/2bres_y; % Dumb, but fool-proof loop for j=1:length(x) MLC((x(j)+bres_x/2)/bres_x+centre_x, (y(j)+bres_y/2)/bres_y+centre_y) = j;end In this case, the beamlets are indexed according to their appearance in x and y. Feel free to include this snippet in your paper, or supply the matrices with the data.

10. Also provide the code-snippets as data to increase the probability that people will work with this dataset. People are lazy. Well, I am...

Discretionary Revisions

1. On page 3, section Beamlet information: I suggest to also include the collimator angle by default. Despite that the collimator rotation fell out of grace with the introduction of IMRT fluence map optimisation, it does not harm to have a field included in the data. Not only if someone wants to explore the advantages of MLC rotation, but it is essential for some treatment devices. Also for VMAT it is beneficial to have a slight rotation to avoid tongue-and-groove effects.

2. Outside the scope of this paper, but I was wondering if you think it is useful to include or describe the patient transformation matrix, i.e. how to project each patient voxel onto the collimator. Despite the simple geometrical exercise, it is a cumbersome, error-prone task, especially when all 3 angles are taken into account (gantry, couch and collimator). If you agree, let me know if I can help.

Level of interest:

An article of importance in its field

Quality of written English:

Acceptable

Statistical review:

No, the manuscript does not need to be seen by a statistician.

Declaration of competing interests:

I declare that I have no competing interests