Summary:

The author has built source code and a Graphical User Interface for calculating TOA incoming solar radiation based on orbital parameters. Other packages have been developed previously to do this, but the author’s aim is for a more flexible (output more customized) and usable (for research and/or teaching) package. These calculations are useful for setting insolation boundary conditions in models, understanding the relative influences of individual orbital parameters on insolation, etc. A few major comments (below) relate to points of clarification in the description of DINSOL, comparison to other insolation calculators, and the code validation.

1. Flexibility: It would be helpful to provide more information comparing DINSOL with PALINSOL. I read the PALINSOL documentation and the biggest gains in flexibility in DINSOL seem to be in providing calculations for a 365-day calendar, as opposed to just a 360-day calendar, and at several time scales shorter than daily mean (e.g., 6 hour, 3 hour, 1 hour, 30 minutes or 15 minutes). Both programs allow adjustments to solar constant as well as access to various solutions for orbital parameters (Berger78, Berger90, Laskar04). One way in which PALINSOL seems to be more flexible is with specification of latitude. Any latitude value may be used, whereas in DINSOL, the user specifies the number of latitude bands and latitudes are assumed to be equally-spaced. Since some climate models use spectral grids (e.g., T42, T31) that are not equally-spaced, PALINSOL is more flexible in this regard. Also, PALINSOL could calculate insolation at the specific latitude of a paleoclimate proxy, another potential use case. At any rate, it would be helpful to the reader to provide a more detailed comparison such as this, so that they may choose the most appropriate tool for their application.
2. Usability: the code is well-documented and it was easy to run on a Unix system.  a) I was not able to test the GUI due to the number of dependencies it requires (fortran, python version 2.7, R, GrADS, as well as several additional libraries). The GUI looks like a useful tool for visualizing output, particularly in a classroom setting, and a future version that is easier to get running with fewer dependencies might be used more widely.   b) The two output formats are text and binary. Given the ubiquity of netcdf in climate modeling, adding this as an output option would be useful.   c) Another advantage of implementations such as PALINSOL is their modularity. For example, it is easy to write a loop in R using PALINSOL functions to calculate a transient time series of insolation, say through many thousands of years, for several specific latitudes, etc. Maybe the author could comment on how similar tasks would be completed with DINSOL. I imagine shell scripting would be part of the solution, but it doesn’t seem as straightforward.
3. Description of DINSOL as a model: Strictly speaking, I think it is more accurate to refer to DINSOL as a “program” or “calculator” rather than a “model,” and that DINSOL “computes” or “calculates” insolation rather than it “simulates” insolation. While there are some uncertainties in exact values of orbital parameters through time (and thus the Berger and Laskar solutions), once orbital parameter is specified, the equations translating orbital parameters to insolation are established and this becomes a computation or calculation rather than a simulation (where things have to be assumed and the answer is not exact). See for examples lines 225-227, but also many other places throughout the manuscript.
4. Points of clarification related to DINSOL uses:   a) Title: “…tool to be coupled with climate models…” The word “coupled” within the context of modeling suggests a two-way flow of information. DINSOL would provide information to simplified climate models, but models would not give information back to DINSOL. I recommend changing this wording to something like: “tool for specifying solar radiation boundary conditions and for classroom use.”   b) Line 60: “versatile tool ideal for paleoclimate simulations, such as those prepared on the PMIP” PMIP models already have code (internally) that calculate insolation from specified orbital parameters or from specified year, for the model time step and spatial grid, so DINSOL is not needed in that context.    c) The author mentions in several places that the ability to specify hypothetical orbital parameters is ideal for exoplanets. It is important to note, however, that DINSOL allows specification of only a 360-day or 365-day year, which are Earth specific.
5. Code validation:   a) There isn’t a validation for orbital parameters calculated from the Be90 and Lask methods (Table 4) since GISS uses only Be78. It seems that a validation could be done against PALINSOL.   b) I’m not sure that the statistical tests in Tables 4 and 6 are a useful way to compare DINSOL with other calculators. The orbital parameter and insolation calculations should be exactly the same across calculators (as Table 4 shows) within rounding error. A U-test for whether the calculated medians are the same is not useful because it is not testing replication. I found RMSE to be most useful, and recommend the U-test results be deleted.  c) Astronomical dates Table 5, section 3.2. For clarification, these were not “modeled” by PMIP – they were calculated based on Berger78. Perhaps use something like the following for the Table 5 caption: “This table contains the dates … calculated by DINSOL and by PMIPII, both using the method of Be78, for ...” And, then the first sentence of section 3.2: “Table 5 contains the dates … aphelion calculated by DINSOL and by PMIPII, both using the method of Be78.” And the third sentence of section 3.2: “by PMIPII” rather than “using PMIPII” since the PMIP team used Be78.  d) Monthly insolation Figure 11, section 3.3: The LGM differences shown in panel (i) have a pattern at high latitudes during spring and fall seasons. The colors are not randomly distributed as you would expect if the two calculations are different only within rounding error. Without a scale bar, I can’t tell how large the differences are, but it is curious why this systematic bias exists.

Minor comments:

1. “PMIPII” is referenced many times in the abstract and throughout the paper (e.g., lines 125, 129, 150, etc.) It is unclear why “PMIPII” is referenced rather than “PMIP” more generally. PMIP3 and PMIP4 have also used specified orbital parameters. The focus on PMIPII seems out of date. One exception is the validation section (section 3), in which calculations performed specifically by the PMIPII team were compared to DINSOL output.
2. Line 42: “From Messori et al. (2019), most climate model simulations showed the intensification and geographical expansion of the monsoonal precipitation during the mid-Holocene…” My understanding is that this paper presents results from one model only and that there are still large model-data discrepancies for mid Holocene monsoonal precipitation. This sentence is also quite specific in the context of this paragraph. To make a more general point about the importance of PMIP model-data comparisons and about recent advances in this area, I recommend one sentence summarizing and referencing the recent paper by Brierly et al. https://doi.org/10.5194/cp-16-1847-2020
3. Line 55: “none was developed to prepare ISR data flexibly” and “prepare custom solar radiation data.” I would argue that PALINSOL is flexible and customizable to some degree, and this statement is too strong.
4. Line 76: “modern day” rather than “current days”
5. Line 129: “typical climate models use a 360-day calendar” is not true, most of the PMIP climate models use a 365-day calendar. Perhaps it is typical for intermediate-complexity climate models to use a 360-day calendar and this could be clarified to make a distinction between different sorts of models.
6. Line 257 and elsewhere: When referring to the PALINSOL software package, provide a citation and/or URL?
7. Regarding the discussion on colormaps for Figure 11 and for the GUI: I agree with the previous reviewer that a divergent colormap is preferable for difference maps (e.g., “Comparison to Current”). Keeping the original yellow-blue colormap is preferable for the Daily Insolation and the Day Length plots since these are not differences.
8. Scale bar for Figure 11 plots g-i is missing.