the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Daily INSOLation (DINSOL-v1.0) model: An intuitive tool to be coupled with climate models and used in classrooms
- Laboratory of Meteorology, Federal University of Vale do São Francisco (UNIVASF), 48902-300, Juazeiro-BA, Brazil
- Laboratory of Meteorology, Federal University of Vale do São Francisco (UNIVASF), 48902-300, Juazeiro-BA, Brazil
Abstract. Climate modelling requires spending an extensive amount of time programming, which means reading, learning, testing, and evaluating source code. Fortunately, many climate models have been developed within the past decades, making it easier for climate studies to be conducted on a global scale. However, some climate models have millions of code lines, making the introduction of new parameterizations a laborious task that demands teamwork. While it is true that the high complexity models perform realistic climate simulations, some researchers perform their studies using simplified climate models in the preliminary test phases. This realisation motivated the development of the Daily INSOLation (DINSOL) model, a robust computer program to support the simplified climate models, performing solar radiation calculations while considering Milankovitch cycles and offering various simulation options for its users. DINSOL was intended to function as a model which supplies data (e.g., daily insolation, instantaneous solar radiation, orbital parameters of the Earth, and the calendar dates), such as the PMIPII. While preparing the boundary conditions of solar radiation for climate models, it was realised that the DINSOL model could also be a helpful tool for use in classrooms. Thus, it was decided that an intuitive graphical user interface would be required to cater to this educational purpose. The model was written in the Fortran 90 language, while its graphical user interface would be built using PyGTK, a Python application programming interface (API) based on GIMP ToolKit (GTK). Furthermore, the R language would also be used to generate a panel containing contour fields and sketches of the orbital parameters to support the graphical execution. The model evaluation made use of data from PMIPII and other models, and the data analysis was performed through statistical methods. Once all tests were concluded, an insignificant difference between the DINSOL-obtained results and the results obtained from other models validated the viability of DINSOL as a tool.
Emerson Damasceno Oliveira
Status: open (extended)
-
CC1: 'Comment on gmd-2022-201', Kevin Schwarzwald, 22 Nov 2022
reply
General Comments
The author introduces a new modeling package to create values for incoming top of atmosphere solar radiation based on variable orbital parameters and insolation constants. The purpose of the package is to easily create useable inputs for earth system modeling and educational purposes.
The paper details the construction of the model and compares output to existing PMIPII simulations. It seems like the fundamental calculations done by the model are thoroughly detailed, and the model seems to compare well to the state-of-the-art simulations in PMIP. I think the paper could however benefit from some clarifications and figures could be made more readable (both detailed below). In particular, DINSOL’s advantages over other TOA shortwave calculators could be made clearer.
I was able to easily download and run the model on a Linux server. I was unable to test the GUI, however – I run MacOS (which the paper clarifies is not supported by the software), and the Linux server I have access to runs CentOS, which has known issues with installing required dependencies such as PyGTK.
Since the paper emphasizes the educational component of the model, moving forward (beyond the publication in this journal), it may be helpful to bundle the code with a sample lesson plan to detail how it can be used in the classroom.
Specific Comments
L55: This paragraph would benefit from a clearer description of what benefits DINSOL has over existing programs. Though a sentence is given for this point, I was still a bit confused as to these differences – is it usability? Speed? Flexibility?
L129: Most GCMs use 365-day years these days – though this might not be the case for other types of models, perhaps a clarification could help
L335 – 354: Please clarify what exactly is meant by ‘sample’ – samples of eccentricity, etc.? or Q?
L355: Please clarify which time intervals
L400: why were the differences between DINSOL and PMIPII only with the 360-day calendar?
Appendix B: - this is useful performance information, thanks for including it. Could you also include an example for a more ‘typical’ GCM-level output (say, 1 degree x 1 degree, while keeping the 30-minute timestep)
Typos / Other fixes
A few places, including L80, L158, L233, could you please use $\times$ instead of $x$ for the multiplication sign? The latter makes it look at first glance as if a variable is being referred to.
L92: please clarify true anomaly of what (solar longitude I assume?)
L96: Typo: find instead of finding
L100: Recommend placing the sentence starting with “However” after eq 3 for clarity.
L114: Typo: should be “Kepler”
L125: Please specify what the ‘beginning’ of the year is defined as – a particular value of λ?
L131: perhaps ‘supports’ instead of ‘uses’
L159: maybe clarify that S_0 can be manually set in the model as well
L241: clarify that it’s +/- 1 Myr “of the present”
L322: “Even under hypothetical cases…” perhaps
Figures
Figure 7 – please label axes on figure as well
Figure 10 – I recommend putting all of the lines for each subplot onto the same axis and differentiating them perhaps by color. Right now, it’s very difficult to see that the Be90 and Lask curves have a different eccentricity amplitude, due to the different y-axes used.
Figure 11 – please use a divergent colormap (red to blue, for example) for difference maps (g, h, i) – they are currently unreadable with the monotonic colormap (from the screenshots of the GUI, it seems like the same colormap is used for difference maps in the program as well – it would definitely be preferable to use a divergent colormap whenever differences are shown). Also it would be great if the broad categories of subplots were labeled on the side – i.e., 365-day for a-f and 360-day for g-l (this can easily be done in a post-processing program – paint, powerpoint, etc.)
-
AC1: 'Reply on CC1', Emerson Damasceno de Oliveira, 25 Nov 2022
reply
Dear Kevin Schwarzwald,
I'm very thankful for your feedback. Your comments and suggestions were essential to help me to improve the manuscript's quality. Thank you for your contributions!
The answers and improved Figures are in the attached file. Please look at it and analyze if my modifications have been conforming to the expectations.
Best regards,
Emerson D. Oliveira
-
AC1: 'Reply on CC1', Emerson Damasceno de Oliveira, 25 Nov 2022
reply
-
RC1: 'Comment on gmd-2022-201', Anonymous Referee #1, 28 Nov 2022
reply
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.
- 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.
- 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.
- 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.
- 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.
- 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:
- “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.
- 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
- 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.
- Line 76: “modern day” rather than “current days”
- 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.
- Line 257 and elsewhere: When referring to the PALINSOL software package, provide a citation and/or URL?
- 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.
- Scale bar for Figure 11 plots g-i is missing.
-
AC2: 'Comment on gmd-2022-201', Emerson Damasceno de Oliveira, 03 Dec 2022
reply
Dear Kevin Schwarzwald, referee#1, and more community members,
Conform was related in the previous comments; the Linux distributions presented issues installing the libraries needed to run the DINSOL in GUI mode. Then, in order to get around this issue, I compiled the GUI.py file into an executable file, "GUI.exe". In general, my experience running the "GUI.exe" on Windows systems was successful in all these operating systems: Windows XP, Windows 7, Windows 10, and Windows 11.
Moreover, I decided to adopt the "Wine Is Not an Emulator" (WINE) because Linux users can run many Windows applications on different options of Linux distributions. Therefore, I prepared a new DINSOL version that can run using wine, which solved the libraries' issues and expanded the distro's compatibilities. Please note that the new program file contains a shell script configuring the DINSOL program in Debian distros, even though it can be easily adapted to run on others environments, such as Arch Linux.
Besides enhancing the compatibility, I also modified the color palette as was suggested in the previous comments.
Well, I'm really thankful for all the feedback and glad to share this new version following the suggestions.
Download link: https://zenodo.org/record/7394326#.Y4uFiHbMK3A
For now, I'm working on the manuscript, but as soon as I conclude the manuscript corrections, a new DINSOL version for Windows will also be posted following the recommended suggestions.
Best Regards,
Emerson D. Oliveira
Emerson Damasceno Oliveira
Data sets
Supplementary files/DINSOL-v1.0 Emerson Damasceno de Oliveira https://doi.org/10.5281/zenodo.6885502
Model code and software
Daily INSOLation (DINSOL-v1.0) model Emerson Damasceno de Oliveira https://doi.org/10.5281/zenodo.6884499
Emerson Damasceno Oliveira
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 322 | 74 | 17 | 413 | 6 | 7 |
- HTML: 322
- PDF: 74
- XML: 17
- Total: 413
- BibTeX: 6
- EndNote: 7
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1