I started a new blog on my experiences with Julia programming. Have a look: https://ufechner7.github.io/
46 Likes
New post: Why am I using Julia?
And thank you for all the likes I got so far!
9 Likes
Hey! Consider cross posting these to https://forem.julialang.org so that I can more easily share them across the ecosystem! You can set the canonical link so that the SEO goes to your original blog post.
3 Likes
New post: Working with Julia projects | Julia programming notes
Please check if I explained the effect of compat bounds correctly. Is this wording correct:
The first two numbers of the version string v1.31.7 are 1 and 31?
3 Likes
What is a canonical link? And how can I set it?
And what is an SEO?
Does Forem support interactive Julia blocks similar to NextJournal? Example
Search-engine optimization, if you want our blog to get noticed. I don’t know how, but your blog is worthy of attention.
At least the one blog I read:
My preferred solver for stiff differential algebraic equations is the Radau5DAE solver, which is available in Fortran and Python, but not yet wrapped or re-written in Julia.
It’s unclear to me if Python is just a wrapper, or is adding to the Fortran code, so that it wouldn’t be enough to just wrap the Fortran code directly (make JLL). Might be easiest would be to use PythonCall.jl, manually, or even a wrapper based on it (it could always be changed later to exclude Python runtime?).
You link indirectly to (and its C-interface):
RADAU5 implicit Runge-Kutta method of order 5 (Radau IIA) for problems of the form My’=f(x,y) with possibly singular matrix M; with dense output (collocation solution). Concerning the linear algebra routines the user has the choice to link the program either with DC_DECSOL and DECSOL or with DC_LAPACK and LAPACK and LAPACKC
Hints for the choice:
a) the LAPACK routines use BLAS
b) the compiler has to accept COMPLEX16 for the LAPACK routines; the DECSOL routines only use REAL8 declarations
That’s ComplexF64 (i.e. of doubles) in Julia lingo, would it help to translate to Julia, make faster (2-4x?), to make generic, supporting ComplexF32 (and even ComplexF16), or would it just be a mistake to lower precision (or not need speedup)?
@chrisrackauckas I see all the Fortran code is FORTRAN77. There was a Fortran-to-Julia for that version, if I recall, made by some Julia people (partly implemented in Perl), could look it up, or was trying, but actually found not one but two more, in case you want to do that (fork the code…, needed in SciMl?):
We have RadauIIA5, but no RadauIIA5DAE for fully implicit DAE definitions. We need to add that one. It’s on the radar.
1 Like
There are two versions available, a Fortran version with a Python wrapper and a pure Python version. They should be functionally identical. The problem that requires effort is to integrate it with the DifferentialEquations.jl interface…
Or to translate it to pure Julia… I would like to have a pure Julia version because I would like to use it with StaticArrays in a non-allocating fashion…
It shouldn’t be to hard to transpile the Fortran code (just try!), but since there’s a pure Python version, you could also try transpiling that with GitHub - JuliaCN/Py2Jl.jl: Python to Julia transpiler. I don’t know if it or those from Fortran are mature, at least there was an interesting JuliCon 2022 talk on it (for fastest resulting code, you can help it along, I doubt that’s needed for Fortran, since it should have all the type info, so the opposite problem: I guess you then get non-generic code out, but easy to fix that).
New blog post: Installing Julia 1.8 and VSCode | Julia programming notes