Options

The fruit fly of climate models

Isaac Held has posted a blog article on what he calls "the fruit fly of climate models", i.e. a simple reference model to help understand conceptual behavior. It's a "a dry atmosphere, an ideal gas on a spherical rotating planet forced only by radiative fluxes — modeled as a simple relaxation of temperature to a “radiative equilibrium” that is a function of latitude and pressure — and a frictional force that relaxes the flow near the surface to zero (in the reference frame rotating with the surface)." This might be an interesting model to attempt if people become more ambitious to write fluid dynamics codes for Azimuth. I haven't read Held and Suarez so I don't know exactly how ambitious it really is. (Simpler models would be things like beta-plane approximations.)

Comments

  • 1.

    Thanks! I've added this information to Climate model. As we get more ambitious, we'll always be looking around for the next step up. So, I hope everyone here uses the wiki to store information we uncover in our conversations. Otherwise it can be hard to find.

    What's a 'beta-plane approximation'?

    Comment Source:Thanks! I've added this information to [[Climate model]]. As we get more ambitious, we'll always be looking around for the next step up. So, I hope everyone here _uses the wiki_ to store information we uncover in our conversations. Otherwise it can be hard to find. What's a 'beta-plane approximation'?
  • 2.

    A beta-plane approximation is a solution of the Navier-Stokes equations on a tangent plane that takes into account changes of the coriolis force with position in a linear approximation.

    I wrote about it here: Atmospheric and oceanic fluid dynamics (or rather started to write about it)

    Comment Source:A beta-plane approximation is a solution of the Navier-Stokes equations on a tangent plane that takes into account changes of the coriolis force with position in a linear approximation. I wrote about it here: [[Atmospheric and oceanic fluid dynamics]] (or rather started to write about it)
  • 3.

    I've had a quick scan of Held and Suarez. My blue-sky idea would be to try applying the hydrodynamic pde solver framework, Paraiso, described in this paper. It would be much fun to try anyway.

    Comment Source:I've had a quick scan of Held and Suarez. My blue-sky idea would be to try applying the hydrodynamic pde solver framework, Paraiso, described in this [paper](http://arxiv.org/pdf/1204.4779v2.pdf). It would be much fun to try anyway.
  • 4.

    I think the most important point in Held & Suarez is the idea that one needs to cut GCMs into software modules that can be tested and compared independently from the rest of the model, with unified interfaces, so that they are interchangeable.

    This idea is, of course, at least 50 years old, in computer science (see "information hiding", "encapsulation", "unit testing" etc.). But the fact that climate modellers are rediscovering these ideas all by themselves means that the chances to "bridge the communication gap" are improving.

    The second important point is of course that software needs to be published for results to be reproducable.

    Comment Source:I think the most important point in Held & Suarez is the idea that one needs to cut GCMs into software modules that can be tested and compared independently from the rest of the model, with unified interfaces, so that they are interchangeable. This idea is, of course, at least 50 years old, in computer science (see "information hiding", "encapsulation", "unit testing" etc.). But the fact that climate modellers are rediscovering these ideas all by themselves means that the chances to "bridge the communication gap" are improving. The second important point is of course that software needs to be published for results to be reproducable.
  • 5.

    Tim, My paper with Max Suarez was written about 20 years ago, and there was nothing new about the idea of "encapsulation" within the climate science community then -- so perhaps we are not that far behind the times. Many GCMs are quite modular in this restricted computer science sense. But this is not the emphasis of my recent blog post, which focuses on the scientific value of a hierarchy of idealized (but non-trivial) climate models. This has nothing to do with modularity per se -- although there is nothing wrong with constructing different models in this hierarchy from the same modular elements (which, of course, is exactly what we do.)

    The problem here is not with the limit of the simplest diffusive or box models, but with focusing the community's attention on some idealizations that still retain aspects of the core complexity of more comprehensive models -- in the case of the dry idealized GCM we hope to capture the essence of the "macroturbulence" of the midlatitude troposphere.

    Comment Source:Tim, My paper with Max Suarez was written about 20 years ago, and there was nothing new about the idea of "encapsulation" within the climate science community then -- so perhaps we are not that far behind the times. Many GCMs are quite modular in this restricted computer science sense. But this is not the emphasis of my recent blog post, which focuses on the scientific value of a hierarchy of idealized (but non-trivial) climate models. This has nothing to do with modularity per se -- although there is nothing wrong with constructing different models in this hierarchy from the same modular elements (which, of course, is exactly what we do.) The problem here is not with the limit of the simplest diffusive or box models, but with focusing the community's attention on some idealizations that still retain aspects of the core complexity of more comprehensive models -- in the case of the dry idealized GCM we hope to capture the essence of the "macroturbulence" of the midlatitude troposphere.
  • 6.
    edited May 2012

    Okay, I would say that such a hierachy is necessary for educational purposes, as well. I'll most certainly not try to understand any full-blown GCM right away :-)

    Since you write on your blog post

    Many of my colleagues are probably tired of hearing me talk about the importance for climate theory of studying a hierarchy of climate models...

    Are they so tired of it that they started to create those models or are they simply tired of it? :-)

    Of course we could try to write some simple models here on Azimuth ourselves, but since this is quite an effort, I think it could only work as an open source project. Such a project needs a core of several lead developers who keep things going, who are very interested in having the software completed, and last but not least know very well what they are doing.

    I'm not sure that Azimuth can form such a core...

    Comment Source:Okay, I would say that such a hierachy is necessary for educational purposes, as well. I'll most certainly not try to understand any full-blown GCM right away :-) Since you write on your blog post <blockquote> <p> Many of my colleagues are probably tired of hearing me talk about the importance for climate theory of studying a hierarchy of climate models... </p> </blockquote> Are they so tired of it that they started to create those models or are they simply tired of it? :-) Of course we could try to write some simple models here on Azimuth ourselves, but since this is quite an effort, I think it could only work as an open source project. Such a project needs a core of several lead developers who keep things going, who are very interested in having the software completed, and last but not least know very well what they are doing. I'm not sure that Azimuth can form such a core...
  • 7.

    Tim van Beek wrote:

    I'm not sure that Azimuth can form such a core...

    But perhaps a satellite? Doesn't your previous post on modularity and Isaac's interdisciplinary theory and observation approach using simple informative models suggest that competent coders with little more domain knowledge and maths than I can code informative, interactive equational models?

    The Azimuth code project is open-source so I missed that point.

    I have tried to find the source code for the CM models but it doesn't seem to be publicly available :(.

    Even though I loathe reading Fortran, even with named subroutines, it provides a condensed version of a specification and I reckon needs to be publicly checked against alternative implementations.

    Comment Source:Tim van Beek wrote: > I'm not sure that Azimuth can form such a core... But perhaps a satellite? Doesn't your previous post on modularity and Isaac's interdisciplinary theory and observation approach using simple informative models suggest that competent coders with little more domain knowledge and maths than I can code informative, interactive equational models? The Azimuth code project is open-source so I missed that point. I have tried to find the source code for the CM models but it doesn't seem to be publicly available :(. Even though I loathe reading Fortran, even with named subroutines, it provides a condensed version of a specification and I reckon needs to be publicly checked against alternative implementations.
  • 8.
    edited May 2012

    But perhaps a satellite?

    Orbiting whom?

    To be a little more constructive: Is there a chance that we can agree on a software platform for which we could try to implement a simple model like Isaac's fruit fly? I have come to the conclusion that managed languages like C# and Java are not cut out to perform numerical calculations and don't have any useful libraries for that task. I don't like scripting languages like Python for larger projects. I don't feel inclined to learn FORTRAN. That leaves C++.

    Comment Source:<blockquote> <p> But perhaps a satellite? </p> </blockquote> Orbiting whom? To be a little more constructive: Is there a chance that we can agree on a software platform for which we could try to implement a simple model like Isaac's fruit fly? I have come to the conclusion that managed languages like C# and Java are not cut out to perform numerical calculations and don't have any useful libraries for that task. I don't like scripting languages like Python for larger projects. I don't feel inclined to learn FORTRAN. That leaves C++.
  • 9.

    [Here] is something more recent. There are a lot of young climate dynamicists who are interested in this sort of thing, but i think they would need to see some forward movement rather than just discussion of coding styles to get involved here. Public (Fortran) codes exist for many idealized models of interest. If you demonstrate that you can do something that is more transparent and useful to a broader group then I think people could get interested. Watching the process could be informative in itself. But I don't see much progress since I checked in last.

    Comment Source:[[Here]](http://kiwi.atmos.colostate.edu/pubs/HeldandRandall.11.pdf) is something more recent. There are a lot of young climate dynamicists who are interested in this sort of thing, but i think they would need to see some forward movement rather than just discussion of coding styles to get involved here. Public (Fortran) codes exist for many idealized models of interest. If you demonstrate that you can do something that is more transparent and useful to a broader group then I think people could get interested. Watching the process could be informative in itself. But I don't see much progress since I checked in last.
  • 10.
    edited May 2012

    I don't know when Isaac Held checked in last, but the big progress over the last 6 months is that we now have a group of people starting to write programs. That's a big change.

    I'm having some trouble figuring out where I fit into this - what I should do. Ideally I should be learning and explaining climate models, to lure the programmers into writing them up. When I go back to Riverside this fall I'll start rounding up a crew of grad students, and ideally I'd get them to work on climate models, or mathematical aspects of hydrodynamics. But I seem to be much better at network theory than these other subjects. It just seems easier for me to come up with worthwhile ideas in that realm. It's possible my main role should be the humble one of editing, publishing and publicizing blog posts that feature the models that are being created here.

    So, it would be great if someone who knows climate models would join this project and lead that aspect of the effort. But it would need to be someone willing to put time into it. Ideally, some smart energetic expert who likes the idea of online collaborations with people who are good at programming but who are just learning some climate physics. This is a pretty non-mainstream approach, at present.

    What do the rest of you folks think?

    Comment Source:I don't know when Isaac Held checked in last, but the big progress over the last 6 months is that we now have a group of people starting to write programs. That's a big change. I'm having some trouble figuring out where I fit into this - what I should do. Ideally I should be learning and explaining climate models, to lure the programmers into writing them up. When I go back to Riverside this fall I'll start rounding up a crew of grad students, and ideally I'd get _them_ to work on climate models, or mathematical aspects of hydrodynamics. But I seem to be much better at [network theory](http://math.ucr.edu/home/baez/networks/) than these other subjects. It just seems easier for me to come up with worthwhile ideas in that realm. It's possible my main role should be the humble one of editing, publishing and publicizing blog posts that feature the models that are being created here. So, it would be great if someone who knows climate models would join this project and lead that aspect of the effort. But it would need to be someone willing to put time into it. Ideally, some smart energetic expert who likes the idea of online collaborations with people who are good at programming but who are just learning some climate physics. This is a pretty non-mainstream approach, at present. What do the rest of you folks think?
  • 11.

    Isaac wrote:

    [Here] is something more recent.

    Ah, alright. I'm not sure I understand the difference of "physical modularity" versus "software modularity" as in "models should be modular as a software, but cannot be modular as a model because the climate is not modular". Maybe I can try to compare climate models (CM) with the construction of an operating system (OS):

    1) everybody working on an OS should have a holistic understanding of OS, check (holds for CM and the climate, too). (And also of computer hardware, programming languages and paradigms, software engineering practices, build and configuration management etc. etc...).

    2) No one can hope to understand every part of an OS, check (holds for CM and the climate, too).

    3) While some parts of an OS mirror the physical structure of a computer (one device driver per device, for example), some definitely don't (scheduling, processes and threads, for example). One could say that some OS modularity was created because it is the only way you can handle the complexity, not because it was suggested by the hardware structure. Check? (holds for CM, too, maybe).

    4) Interfaces are always a pain, the interoperation of modules created by different teams is always one of the most difficult part of the software construction process. Check (holds for CM, too).

    5) You need a central hard core of very competent people who control the overall construction process and are responsible for the end product (check, holds for CM, too).

    I don't see how 4) and 5) are counterpoints to an open source project (see Linux). Here is my most important counterpoint: Successful open source projects are about a solution to a problem that coders have. People engage in it because it is the simplest and most effective way to get a solution to a problem they face in their everyday job/life.

    I don't know of any successful open source project where coders had to obtain a considerable amount of domain specific knowledge.

    Comment Source:Isaac wrote: <blockquote> <p> [Here] is something more recent. </p> </blockquote> Ah, alright. I'm not sure I understand the difference of "physical modularity" versus "software modularity" as in "models should be modular as a software, but cannot be modular as a model because the climate is not modular". Maybe I can try to compare climate models (CM) with the construction of an operating system (OS): 1) everybody working on an OS should have a holistic understanding of OS, check (holds for CM and the climate, too). (And also of computer hardware, programming languages and paradigms, software engineering practices, build and configuration management etc. etc...). 2) No one can hope to understand every part of an OS, check (holds for CM and the climate, too). 3) While some parts of an OS mirror the physical structure of a computer (one device driver per device, for example), some definitely don't (scheduling, processes and threads, for example). One could say that some OS modularity was created because it is the only way you can handle the complexity, not because it was suggested by the hardware structure. Check? (holds for CM, too, maybe). 4) Interfaces are always a pain, the interoperation of modules created by different teams is always one of the most difficult part of the software construction process. Check (holds for CM, too). 5) You need a central hard core of very competent people who control the overall construction process and are responsible for the end product (check, holds for CM, too). I don't see how 4) and 5) are counterpoints to an open source project (see Linux). Here is my most important counterpoint: Successful open source projects are about a solution to a problem that coders have. People engage in it because it is the simplest and most effective way to get a solution to a problem they face in their everyday job/life. I don't know of any successful open source project where coders had to obtain a considerable amount of domain specific knowledge.
  • 12.
    edited May 2012

    John wrote:

    I don't know when Isaac Held checked in last, but the big progress over the last 6 months is that we now have a group of people starting to write programs. That's a big change.

    Ugh, yes, but Isaac's point is of course that a project needs to have some results to be interesting. An open source project needs an interesting code base that already does something useful to get other coders interested in contributing to it. Experience shows that you cannot get people to work on the idea for an open source project. In that sense he is absolutley right: There hasn't been any progress here.

    My idea of how to start was and is to write a solution for the 1D Burgers equation, comparing the solution in closed form to the Spectral methods for PDEs ansatz. This includes a lot of choices with regard to the software infrastructure. The next step would be a simulation of turbulence of the Navier-Stokes equations in 3D with periodic boundary conditions.

    I guess that the latter part would be complex enough to get people interested, if the software turns out to be well structured, documented, easy to use and adapt, fast, reliable and if it produces maybe some new interesting results or at least reproduces some recently obtained interesting results.

    Only the next step would be Isaac's fruit fly, because it involves a more complex geometry (a rotating sphere with boundary conditions). That seems to be too hard to tackle it right on, if you start from scratch.

    Comment Source:John wrote: <blockquote> <p> I don't know when Isaac Held checked in last, but the big progress over the last 6 months is that we now have a group of people starting to write programs. That's a big change. </p> </blockquote> Ugh, yes, but Isaac's point is of course that a project needs to have some results to be interesting. An open source project needs an interesting code base that already does something useful to get other coders interested in contributing to it. Experience shows that you cannot get people to work on the idea for an open source project. In that sense he is absolutley right: There hasn't been any progress here. My idea of how to start was and is to write a solution for the 1D [[Burgers equation]], comparing the solution in closed form to the [[Spectral methods for PDEs]] ansatz. This includes a lot of choices with regard to the software infrastructure. The next step would be a simulation of turbulence of the Navier-Stokes equations in 3D with periodic boundary conditions. I guess that the latter part would be complex enough to get people interested, if the software turns out to be well structured, documented, easy to use and adapt, fast, reliable and if it produces maybe some new interesting results or at least reproduces some recently obtained interesting results. Only the next step would be Isaac's fruit fly, because it involves a more complex geometry (a rotating sphere with boundary conditions). That seems to be too hard to tackle it right on, if you start from scratch.
  • 13.

    The next step would be a simulation of turbulence of the Navier-Stokes equations in 3D with periodic boundary conditions.

    I guess that the latter part would be complex enough to get people interested

    Only the next step would be Isaac's fruit fly, because it involves a more complex geometry (a rotating sphere with boundary conditions). That seems to be too hard to tackle it right on, if you start from scratch.

    @Tim: there do exist open source projects in C++ that allow modelling turbulence, for example OpenFOAM, in case you would want to skip the second step (if OpenFOAM satisfies your requirements, of course)

    Comment Source:> The next step would be a simulation of turbulence of the Navier-Stokes equations in 3D with periodic boundary conditions. > I guess that the latter part would be complex enough to get people interested > Only the next step would be Isaac's fruit fly, because it involves a more complex geometry (a rotating sphere with boundary conditions). That seems to be too hard to tackle it right on, if you start from scratch. @Tim: there do exist open source projects in C++ that allow modelling turbulence, for example [OpenFOAM](http://www.openfoam.com/), in case you would want to skip the second step (if OpenFOAM satisfies your requirements, of course)
  • 14.
    edited May 2012

    Yes, we have that reference already on Computational fluid dynamics.

    I'm undecided yet if it would be better to try to understand openFoam or to try to implement something from scratch. I'd need to take a closer look at the code. Even if it satisfies my requirements, it may be useful to at least try to implement something from scratch for educational purposes.

    This is similar to math: Sometimes it is better to try to solve a problem for two weeks by yourself and fail, and then read about the solution, than to read the solution right away. Often one cannot understand a paper if one has no clear idea of all the problems that the authors tried to solve and which ones they solved successfully.

    But thanks for the reminder, I think I will take a closer look at the code during the next weeks.

    Comment Source:Yes, we have that reference already on [[Computational fluid dynamics]]. I'm undecided yet if it would be better to try to understand openFoam or to try to implement something from scratch. I'd need to take a closer look at the code. Even if it satisfies my requirements, it may be useful to at least try to implement something from scratch for educational purposes. This is similar to math: Sometimes it is better to try to solve a problem for two weeks by yourself and fail, and then read about the solution, than to read the solution right away. Often one cannot understand a paper if one has no clear idea of all the problems that the authors tried to solve and which ones they solved successfully. But thanks for the reminder, I think I will take a closer look at the code during the next weeks.
  • 15.
    edited June 2012

    Tim wrote:

    I don't know of any successful open source project where coders had to obtain a considerable amount of domain specific knowledge.

    Try the glorious glasgow haskell compiler's million lines of haskell (cf perhaps 20m lines to do the similar things in C++) in the domains of category theory, type theory and engineering.

    If you're a software architect, software company or freelance programmer you nearly always start from almost total domain ignorance. I've had to speed read and swallow standard texts on fibre optic physics, structural engineering and reinsurance among many others. This might be called textbook to code. Ignorance should be no inhibitor provided you read fanatically. Now 7 volumes of the XLib reference manual - I call that a brain ache.

    Comment Source:Tim wrote: > I don't know of any successful open source project where coders had to obtain a considerable amount of domain specific knowledge. Try the glorious glasgow haskell compiler's million lines of haskell (cf perhaps 20m lines to do the similar things in C++) in the domains of category theory, type theory and engineering. If you're a software architect, software company or freelance programmer you nearly always start from almost total domain ignorance. I've had to speed read and swallow standard texts on fibre optic physics, structural engineering and reinsurance among many others. This might be called textbook to code. Ignorance should be no inhibitor provided you read fanatically. Now 7 volumes of the XLib reference manual - I call that a brain ache.
  • 16.
    Tim: The fruit fly is a lot simpler than 3d turbulence -- if you assume that the flow is hydrostatic, ignoring vertical accelerations (which is a good approximation until your horizontal resolution gets down to less than 10km or so), you can think of it as a bunch of 2D layers stacked on top of each other -- ie, you use the fact that you are modeling pancake like flows with small aspect ratio.

    John: I'll mention this to a few people who might conceivably be interested. Maybe some will drop by and provide unsolicited advice.
    Comment Source:Tim: The fruit fly is a lot simpler than 3d turbulence -- if you assume that the flow is hydrostatic, ignoring vertical accelerations (which is a good approximation until your horizontal resolution gets down to less than 10km or so), you can think of it as a bunch of 2D layers stacked on top of each other -- ie, you use the fact that you are modeling pancake like flows with small aspect ratio. John: I'll mention this to a few people who might conceivably be interested. Maybe some will drop by and provide unsolicited advice.
  • 17.

    Thanks, Isaac! I hereby solicit unsolicited advice.

    Since the conversation is drifting toward issues of the strategy the Azimuth Project should take, I'll talk more about that in the 'Strategy' section.

    Comment Source:Thanks, Isaac! I hereby solicit unsolicited advice. Since the conversation is drifting toward issues of the strategy the Azimuth Project should take, I'll talk more about that in the 'Strategy' section.
  • 18.
    Hi,

    I'm a post-doc working with Isaac Held. This is my first post, and I have not read the complete archives, so apologies if I write something that has already been discussed.

    I read the blog post from a month or so ago about multiple equilibria in 0-d EBMs with albedo feedback (This week's finds 319). I like the interactive applet - perhaps that is a useful direction.

    Here is a web-based radiative convective equilibrium calculation from Rodrigo Caballero:
    http://people.su.se/~rcaba/cgi/toa_balance.html

    Ray Pierrehumbert has put together a lot of Python scripts to do radiation-based calculations of this sort (I believe the actual radiative transfer code is from NCAR and is written in Fortran) for his Principles of Planetary Climate book, which I recommend. They are available here: http://geosci.uchicago.edu/~rtp1/PrinciplesPlanetaryClimate/Courseware/coursewarePortal.html

    Last, on the topic of unsolicited advice: this thread was hidden until I registered and logged in. I suppose it may be intentional to not have a public discussion, but some of the others who Isaac advertised the forum to may not have had the fortitude to go through the registration without knowing what is being discussed here.
    Comment Source:Hi, I'm a post-doc working with Isaac Held. This is my first post, and I have not read the complete archives, so apologies if I write something that has already been discussed. I read the blog post from a month or so ago about multiple equilibria in 0-d EBMs with albedo feedback (This week's finds 319). I like the interactive applet - perhaps that is a useful direction. Here is a web-based radiative convective equilibrium calculation from Rodrigo Caballero: http://people.su.se/~rcaba/cgi/toa_balance.html Ray Pierrehumbert has put together a lot of Python scripts to do radiation-based calculations of this sort (I believe the actual radiative transfer code is from NCAR and is written in Fortran) for his Principles of Planetary Climate book, which I recommend. They are available here: http://geosci.uchicago.edu/~rtp1/PrinciplesPlanetaryClimate/Courseware/coursewarePortal.html Last, on the topic of unsolicited advice: this thread was hidden until I registered and logged in. I suppose it may be intentional to not have a public discussion, but some of the others who Isaac advertised the forum to may not have had the fortitude to go through the registration without knowing what is being discussed here.
  • 19.

    Hi Tim, welcome :-)

    I have read Pierrehumbert' book. Some time ago, I started some Wiki pages to collect this kind of material. I just added his book and the link to the source code here: Climate physics.

    Progress seems to have slowed down on the Wiki. The reason why I don't write more is because I have to learn the stuff I write about first :-) But the idea of the Wiki is nevertheless to have references and explanations for climate and climate models starting with basic stuff and ending with links to current research. Also, I would like to have material for computer models on the Wiki, to help coders and scientists to get started. That's why we have little pages about Python, Java etc.

    Here is a web-based radiative convective equilibrium calculation from Rodrigo Caballero: http://people.su.se/~rcaba/cgi/toa_balance.html

    I'll look for a good place on the Wiki for this. As a long term goal, I plan to understand radiative transfer, blog about it and explain code that is used in climate models for both line-by-line resolutions and approximations. This may take a year or more :-) So I'll really need to put these references on the Wiki to be able to look it up later.

    Comment Source:Hi Tim, welcome :-) I have read Pierrehumbert' book. Some time ago, I started some Wiki pages to collect this kind of material. I just added his book and the link to the source code here: [[Climate physics]]. Progress seems to have slowed down on the Wiki. The reason why I don't write more is because I have to learn the stuff I write about first :-) But the idea of the Wiki is nevertheless to have references and explanations for climate and climate models starting with basic stuff and ending with links to current research. Also, I would like to have material for computer models on the Wiki, to help coders and scientists to get started. That's why we have little pages about [[Python]], [[Java]] etc. <blockquote> <p> Here is a web-based radiative convective equilibrium calculation from Rodrigo Caballero: http://people.su.se/~rcaba/cgi/toa_balance.html </p> </blockquote> I'll look for a good place on the Wiki for this. As a long term goal, I plan to understand radiative transfer, blog about it and explain code that is used in climate models for both line-by-line resolutions and approximations. This may take a year or more :-) So I'll really need to put these references on the Wiki to be able to look it up later.
  • 20.

    Jim wrote:

    If you're a software architect, software company or freelance programmer you nearly always start from almost total domain ignorance. I've had to speed read and swallow standard texts on fibre optic physics, structural engineering and reinsurance among many others. This might be called textbook to code. Ignorance should be no inhibitor provided you read fanatically.

    BTW, Jim, you quoted me, not Isaac :-)

    That is encouriging. Yes, I know what you talk about from my own experience. I've been working for a software company for more than a decade know that develops custom software for very specialized needs. Right now I am project lead in a small project that takes care of the installation process of software for embedded microcontrollers in cars. So I have to learn quite a bit about car electronics.

    So, we can try to prove that instead of getting climate scientists up and running as coders (which is also important and currently happening), we can also do it the other way around and get interested and motivated coders up and running in understanding climate models :-)

    Comment Source:Jim wrote: <blockquote> <p> If you're a software architect, software company or freelance programmer you nearly always start from almost total domain ignorance. I've had to speed read and swallow standard texts on fibre optic physics, structural engineering and reinsurance among many others. This might be called textbook to code. Ignorance should be no inhibitor provided you read fanatically. </p> </blockquote> BTW, Jim, you quoted me, not Isaac :-) That is encouriging. Yes, I know what you talk about from my own experience. I've been working for a software company for more than a decade know that develops custom software for very specialized needs. Right now I am project lead in a small project that takes care of the installation process of software for embedded microcontrollers in cars. So I have to learn quite a bit about car electronics. So, we can try to prove that instead of getting climate scientists up and running as coders (which is also important and currently happening), we can also do it the other way around and get interested and motivated coders up and running in understanding climate models :-)
  • 21.
    I've been involved in another effort to publicly distribute idealized climate models: http://www.gps.caltech.edu/~tapio/gcms/index.html

    Some of these are similar to the dry 'fruit fly' that Isaac has described. Others include a representation of the hydrological cycle. All use the same spectral representation of the fluid dynamics that is implemented in Fortran from the GFDL FMS code (http://data1.gfdl.noaa.gov/~arl/pubrel/m/atm_dycores/doc/).
    Comment Source:I've been involved in another effort to publicly distribute idealized climate models: http://www.gps.caltech.edu/~tapio/gcms/index.html Some of these are similar to the dry 'fruit fly' that Isaac has described. Others include a representation of the hydrological cycle. All use the same spectral representation of the fluid dynamics that is implemented in Fortran from the GFDL FMS code (http://data1.gfdl.noaa.gov/~arl/pubrel/m/atm_dycores/doc/).
  • 22.

    Tim Merlis wrote:

    I've been involved in another effort to publicly distribute idealized climate models: http://www.gps.caltech.edu/~tapio/gcms/index.html

    I've added the reference to our GCM page on the Wiki. I have a somewhat naive, uninformed question: Isaac writes about the need of a hierachy of models, created and updates as open source projects. On the other hand we have collected some links to existing projects, you have mentioned one yourself. What is the status of these projects? What is lacking and why does Isaac see a need to start new projects?

    Comment Source:Tim Merlis wrote: <blockquote> <p> I've been involved in another effort to publicly distribute idealized climate models: http://www.gps.caltech.edu/~tapio/gcms/index.html </p> </blockquote> I've added the reference to our [[GCM]] page on the Wiki. I have a somewhat naive, uninformed question: Isaac writes about the need of a hierachy of models, created and updates as open source projects. On the other hand we have collected some links to existing projects, you have mentioned one yourself. What is the status of these projects? What is lacking and why does Isaac see a need to start new projects?
  • 23.
    edited June 2012

    Tim wrote:

    So, we can try to prove that instead of getting climate scientists up and running as coders (which is also important and currently happening), we can also do it the other way around and get interested and motivated coders up and running in understanding climate models :-)

    Brilliant. I was a little worried my post might get shot down for my usual over-optimism (usually crushed in real-world contexts, happily).

    If and when I or anybody else gets any simple validated, verified, literate climate model code working in Haskell, and we have a UCR or other server (Amazon EC?), I will nudge John Baez to ask Dan Piponi (whom he knows) if he will post a request for programmers to the Haskell community to join the Azimuth Code Project. If Dan asks, I'm sure others will respond.

    BTW, Jim, you quoted me, not Isaac :-)

    Corrected above. (I'm glad it was you not Isaac - that's much less depressing :) )

    Comment Source:Tim wrote: > So, we can try to prove that instead of getting climate scientists up and running as coders (which is also important and currently happening), we can also do it the other way around and get interested and motivated coders up and running in understanding climate models :-) Brilliant. I was a little worried my post might get shot down for my usual over-optimism (usually crushed in real-world contexts, happily). If and when I or anybody else gets *any* simple validated, verified, literate climate model code working in Haskell, and we have a UCR or other server (Amazon EC?), I will nudge John Baez to ask Dan Piponi (whom he knows) if he will post a request for programmers to the Haskell community to join the Azimuth Code Project. If Dan asks, I'm sure others will respond. > BTW, Jim, you quoted me, not Isaac :-) Corrected above. (I'm glad it was you not Isaac - that's much less depressing :) )
  • 24.
    RE Tim van Beek: One argument is that there is value in having climate models (throughout the hierarchy) that are more user-friendly or accessible. Is it too high of a bar that someone who wants to perform an integration of a Held-Suarez GCM has to be expert enough to compile a Fortran code with the appropriate libraries?

    This is what motivated me to promote the web-based RCE calculation.

    One more link to a project from the climate community that may be of interest: EdGCM is an education version of the comprehensive GISS climate model (http://edgcm.columbia.edu/). I think it has a GUI interface and presumably the executable is already built or the build occurs without user intervention.
    Comment Source:RE Tim van Beek: One argument is that there is value in having climate models (throughout the hierarchy) that are more user-friendly or accessible. Is it too high of a bar that someone who wants to perform an integration of a Held-Suarez GCM has to be expert enough to compile a Fortran code with the appropriate libraries? This is what motivated me to promote the web-based RCE calculation. One more link to a project from the climate community that may be of interest: EdGCM is an education version of the comprehensive GISS climate model (http://edgcm.columbia.edu/). I think it has a GUI interface and presumably the executable is already built or the build occurs without user intervention.
  • 25.

    One argument is that there is value in having climate models (throughout the hierarchy) that are more user-friendly or accessible.

    We'll need to make an analysis of the target group first: "user-friendly" and "accessible" depend on whom you are talking about. There are several possibilities that come to my mind:

    1) a general audience won't be able to do much with any climate model,

    2) the readers of the Azimuth blog are supposedly fluent in math and some physics, so they can understand simple models if we explain them on the blog, and will probably play around with simple online gadgets,

    3) other climate scientists may be grateful for a simpler installation process, a GUI, a better documentation of the source code etc.

    4) developers will need good explanations of the math and the physics behind the code, and 3) partially applies also to them. Plus they will be attracted to models that use modern software engineering principles, starting with the programming language.

    Talking about myself: Learning Fortran is a pure waste of time on a professional level. Learning C++ could become useful for my career, it is certainly valuable to know about it anyway. The main difference of 3) and 4) is that developers won't care much about GUIs, because they dive into the code anyway, while climate scientists won't care much about "bad code quality". Talking about myself again: Reading some of the published code is like grinding sand with my teeth, it's just no fun.

    I'm mostly thinking about 4.

    Comment Source:<blockquote> <p> One argument is that there is value in having climate models (throughout the hierarchy) that are more user-friendly or accessible. </p> </blockquote> We'll need to make an analysis of the target group first: "user-friendly" and "accessible" depend on whom you are talking about. There are several possibilities that come to my mind: 1) a general audience won't be able to do much with any climate model, 2) the readers of the Azimuth blog are supposedly fluent in math and some physics, so they can understand simple models if we explain them on the blog, and will probably play around with simple online gadgets, 3) other climate scientists may be grateful for a simpler installation process, a GUI, a better documentation of the source code etc. 4) developers will need good explanations of the math and the physics behind the code, and 3) partially applies also to them. Plus they will be attracted to models that use modern software engineering principles, starting with the programming language. Talking about myself: Learning Fortran is a pure waste of time on a professional level. Learning C++ could become useful for my career, it is certainly valuable to know about it anyway. The main difference of 3) and 4) is that developers won't care much about GUIs, because they dive into the code anyway, while climate scientists won't care much about "bad code quality". Talking about myself again: Reading some of the published code is like grinding sand with my teeth, it's just no fun. I'm mostly thinking about 4.
  • 26.

    One more link to a project from the climate community that may be of interest: EdGCM is an education version of the comprehensive GISS climate model (http://edgcm.columbia.edu/).

    Thanks, I just checked and it is alreay on our page GCM.

    Comment Source:<blockquote> <p> One more link to a project from the climate community that may be of interest: EdGCM is an education version of the comprehensive GISS climate model (http://edgcm.columbia.edu/). </p> </blockquote> Thanks, I just checked and it is alreay on our page [[GCM]].
Sign In or Register to comment.