4 ms·

scientific models and simulations can be and are made very successfully in julia. In particular the diffeq landscape is probably the languages largest comparati

scientific models and simulations can be and are made very successfully in julia. In particular the diffeq landscape is probably the languages largest comparative advantage

spenczar5 3y ago
That’s a broad area. I work in astrodynamic simulations, and don’t know anyone doing much work in Julia. Maybe a couple of grad students playing with it, but that’s it. 99% of the work is Python, Fortran, and C/C++. Are there subdomains that use it a lot? I am not sure what the diffeq landscape is exactly although it sounds related to dynamical simulations?
- affinepplan 3y ago
  I'm sure there are other subdomains that make use of Julia, but in particular I think if your problem involves writing an evolution-like or agent-based-model-like simulation you may find the strengths of Julia particularly compelling
  - edgyquant 3y ago
    “You may find” is not the same thing as “has taken off in” which was the claim
    - pjmlp 3y ago
      https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
- lagrange77 3y ago
  I recently found this: https://github.com/JuliaSpace/ https://github.com/JuliaSpace/ Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
  - spenczar5 3y ago
    Astropy [0] lives at the heart of most work. It has a Python interface, often backed by Fortran and C++ extension modules. If you use Astropy, you're indirectly using libraries like ERFA [6] and cfitsio [7] which are in C/Fortran. I personally end up doing a lot of work that uses the HEALPix sky tesselation, so I use healpy [2] as well. Openorb is perhaps a good example of a pure-Fortran package that I use quite frequently for orbit propagation [3]. In C, there's Rebound [4] (for N-body simulations) and ASSIST [5] (which extends Rebound to use JPL's pre-calculated positions of major perturbers, and expands the force model to account for general relativity). There are many more, these are just ones that come to mind from frequent usage in the last few months. ---- [0] https://www.astropy.org/ https://www.astropy.org/ [1] https://healpix.jpl.nasa.gov/ https://healpix.jpl.nasa.gov/ [2] https://healpy.readthedocs.io/en/latest/ https://healpy.readthedocs.io/en/latest/ [3] https://github.com/oorb/oorb https://github.com/oorb/oorb [4] https://rebound.readthedocs.io/en/latest/ https://rebound.readthedocs.io/en/latest/ [5] https://github.com/matthewholman/assist https://github.com/matthewholman/assist [6] https://github.com/liberfa/erfa https://github.com/liberfa/erfa [7] https://heasarc.gsfc.nasa.gov/fitsio/ https://heasarc.gsfc.nasa.gov/fitsio/
    - lagrange77 3y ago
      Thank you very much for the detailed answer! Will look into those. I recently wrote a little n-body simulator to become familiar with Julia's DifferentialEquations.jl and that motivated me to learn more about astrodynamics.
chestertn 3y ago
One of the things I don't like about the Julia ecosystem is the monolithic libraries that have tons of dependencies. DiffEq is one of those. I think its fine to write a script but if you want to develop something more sophisticated, you want to keep your dependencies lean.
- krull10 3y ago
  You can always (slightly) reduce the DiffEq dependencies by adding OrdinaryDiffEq.jl instead of the meta DifferentialEquations.jl package. But lots of those dependencies arise from supporting modular functionality (changing BLAS, linear solvers, Jacobian calculation methods, in vs. out of place workflows, etc.). That said, the newer extension functionality may let more and more of the dependencies get factored out into optional extensions as time goes on.
  - chestertn 3y ago
    I think it’s also the design philosophy. JuMP and ForwardDiff are great success stories and are packages very light on dependencies. I like those. The DiffEq library seems to pull you towards the SciML ecosystem and that might not be agreeable to everyone. For instance a known Julia project that simulates diff equations seems to have implemented their own solver https://github.com/CliMA/Oceananigans.jl https://github.com/CliMA/Oceananigans.jl
    - ChrisRackauckas 3y ago
      That's a bit different, and an interesting different. Certain types of partial differential equations like the one solved there generally use a form of step splitting (i.e. a finite volume method with a staggard grid). Those don't map cleanly into standard ODE solvers since you generally want to use a different method on one of the equations. It does map into the SplitODEProblem form as a not DynamicalODEProblem, and so there is a way to represent it, but we have not created optimized time stepping methods for that. But I work with those folks so I understand their needs and we'll be kicking off a new project in the MIT Julia Lab in the near future to start developing split step and multi-rate methods specifically for these kinds of PDEs. It's an interesting space because: -(a) there aren't really good benchmarks on the full set of options, so a benchmarking paper would be interesting to the field (which then gives a motivation to the software development) -(b) none of the implementations I have seen used the detailed tricks from standard stiff ODE solvers and so there's some major room for performance improvements -(c) there's some alternative ways to generate the stable steppers that haven't been explored, and we have some ideas for symbolic-numeric methods that extend the ideas of what people have traditionally done by hand here. That should. so we do plan to do things in the future. And having Oceananigans is then great because it serves as a speed-of-light baseline: if you auto-generate an ocean model, do you actually get as fast as a real hand-optimized ocean model? That's the goal, and we'll see if we can get there. We have tons of solvers, but you always need more!

scientific models and simulations can be and are made very successfully in julia. In particular the diffeq landscape is probably the languages largest comparative advantage

spenczar5 3y ago

That’s a broad area. I work in astrodynamic simulations, and don’t know anyone doing much work in Julia. Maybe a couple of grad students playing with it, but that’s it. 99% of the work is Python, Fortran, and C/C++. Are there subdomains that use it a lot? I am not sure what the diffeq landscape is exactly although it sounds related to dynamical simulations?

affinepplan 3y ago
I'm sure there are other subdomains that make use of Julia, but in particular I think if your problem involves writing an evolution-like or agent-based-model-like simulation you may find the strengths of Julia particularly compelling
- edgyquant 3y ago
  “You may find” is not the same thing as “has taken off in” which was the claim
  - pjmlp 3y ago
    https://juliahub.com/case-studies/ https://juliahub.com/case-studies/
lagrange77 3y ago
I recently found this: https://github.com/JuliaSpace/ https://github.com/JuliaSpace/ Out of curiosity, what Python, Fortran, and C/C++ packages do you use / can you recommend?
- spenczar5 3y ago
  Astropy [0] lives at the heart of most work. It has a Python interface, often backed by Fortran and C++ extension modules. If you use Astropy, you're indirectly using libraries like ERFA [6] and cfitsio [7] which are in C/Fortran. I personally end up doing a lot of work that uses the HEALPix sky tesselation, so I use healpy [2] as well. Openorb is perhaps a good example of a pure-Fortran package that I use quite frequently for orbit propagation [3]. In C, there's Rebound [4] (for N-body simulations) and ASSIST [5] (which extends Rebound to use JPL's pre-calculated positions of major perturbers, and expands the force model to account for general relativity). There are many more, these are just ones that come to mind from frequent usage in the last few months. ---- [0] https://www.astropy.org/ https://www.astropy.org/ [1] https://healpix.jpl.nasa.gov/ https://healpix.jpl.nasa.gov/ [2] https://healpy.readthedocs.io/en/latest/ https://healpy.readthedocs.io/en/latest/ [3] https://github.com/oorb/oorb https://github.com/oorb/oorb [4] https://rebound.readthedocs.io/en/latest/ https://rebound.readthedocs.io/en/latest/ [5] https://github.com/matthewholman/assist https://github.com/matthewholman/assist [6] https://github.com/liberfa/erfa https://github.com/liberfa/erfa [7] https://heasarc.gsfc.nasa.gov/fitsio/ https://heasarc.gsfc.nasa.gov/fitsio/
  - lagrange77 3y ago
    Thank you very much for the detailed answer! Will look into those. I recently wrote a little n-body simulator to become familiar with Julia's DifferentialEquations.jl and that motivated me to learn more about astrodynamics.

chestertn 3y ago

One of the things I don't like about the Julia ecosystem is the monolithic libraries that have tons of dependencies. DiffEq is one of those. I think its fine to write a script but if you want to develop something more sophisticated, you want to keep your dependencies lean.

krull10 3y ago
You can always (slightly) reduce the DiffEq dependencies by adding OrdinaryDiffEq.jl instead of the meta DifferentialEquations.jl package. But lots of those dependencies arise from supporting modular functionality (changing BLAS, linear solvers, Jacobian calculation methods, in vs. out of place workflows, etc.). That said, the newer extension functionality may let more and more of the dependencies get factored out into optional extensions as time goes on.
- chestertn 3y ago
  I think it’s also the design philosophy. JuMP and ForwardDiff are great success stories and are packages very light on dependencies. I like those. The DiffEq library seems to pull you towards the SciML ecosystem and that might not be agreeable to everyone. For instance a known Julia project that simulates diff equations seems to have implemented their own solver https://github.com/CliMA/Oceananigans.jl https://github.com/CliMA/Oceananigans.jl
  - ChrisRackauckas 3y ago
    That's a bit different, and an interesting different. Certain types of partial differential equations like the one solved there generally use a form of step splitting (i.e. a finite volume method with a staggard grid). Those don't map cleanly into standard ODE solvers since you generally want to use a different method on one of the equations. It does map into the SplitODEProblem form as a not DynamicalODEProblem, and so there is a way to represent it, but we have not created optimized time stepping methods for that. But I work with those folks so I understand their needs and we'll be kicking off a new project in the MIT Julia Lab in the near future to start developing split step and multi-rate methods specifically for these kinds of PDEs. It's an interesting space because: -(a) there aren't really good benchmarks on the full set of options, so a benchmarking paper would be interesting to the field (which then gives a motivation to the software development) -(b) none of the implementations I have seen used the detailed tricks from standard stiff ODE solvers and so there's some major room for performance improvements -(c) there's some alternative ways to generate the stable steppers that haven't been explored, and we have some ideas for symbolic-numeric methods that extend the ideas of what people have traditionally done by hand here. That should. so we do plan to do things in the future. And having Oceananigans is then great because it serves as a speed-of-light baseline: if you auto-generate an ocean model, do you actually get as fast as a real hand-optimized ocean model? That's the goal, and we'll see if we can get there. We have tons of solvers, but you always need more!