There are several open source “black box” air quality models (SMOKE, CMAQ, CAMx) which are written primarily in FORTRAN. The size and difficulty of these models is a HUGE barrier for environmental folks interested in air quality. I was wondering to what extent Julia could make this easier? It might be worth the time to create Julia bindings for these libraries, or even to consider porting some of the code to Julia? Anyway, I was thinking it might be a nice summer of code project.
It’s a good idea for sure. I’d also be interested in some aspects for this, but more for small-scale modelling, say neighbourhood-level rather than a full continent. Are you just suggesting this as an idea, or do you want to work on it?
Dunno, do you think it would be useful? I would consider working on it though I don’t have too much experience with fortran
Could you post some more details? What equations do these solve? What techniques are normally used?
I assume it’s some big PDE. I’d like to know what kind these are to know how to build in that direction.
Hydrologic models might be interesting to take a look at as well. One is SWAT
Thanks for sharing. I see that these are reaction-diffusion-advection equations. That is one big direction I am going towards with the PDEs library. Of course, we are a long ways off from those huge models and refined methods, but we should have a toolbox to start building the core simulation engine by the end of summer.
When we get there we should discuss how to properly build this to separate the computational engine from the overall model, to keep building out new methods separately.
I’m confused by the “we” here. You’re referring to the PDE team?
We the community 
. I’m not sure who that encompasses. I know I’ll be continuing to work on things DifferentialEquations.jl-related. I know that there will be some proposals for PDE-related GSoC projects, so they might be in the “we”. And the “we” includes anyone else who is interested.
2 Likes
Ok, well theoretically both CMAQ and CAMx should have the infrastructure for handling these kind of differential equations. One project could be to track down where in each model this is actually done, find the commonalities, port the code into Julia, and make it more extensible so that it could be used in broader applications.
Their infrastructure and designs are not necessarily good for Julia. And not necessarily good for re-usability either.
To be more clear: they were built to be an internal engine for a special-purpose software. Instead, I think we should build a general-purpose solver which has the abstractions and flexibility that it can be used as the core in a package for this special purpose. Essentially: core diffeq solvers + DSL, instead of a mixed design. This has many advantages for program structure, and it means that over time people working on different domains can improve each others algorithms even if they are working on something different. This design leads to more sustainable software: splitting out the different chunks to have their own separate tests, and with multiple use cases even rare bugs are more likely to be found. A multiple dispatch design using Julia effectively can make this essentially a zero-cost abstraction.
But, it would have to be built from scratch. A wrapper is a fine short-term solution though.
1 Like