I have found that promising library, which seems not yet published online (tell me if you find a link somewhere):
Hello everybody. I am the author of the library demonstrated in that video. The video was intended for a fellow developer of a similar C library to interchange ideas privately, but since I didn’t want to attach it in a mail, I uploaded it to Youtube and sent him a link. I didn’t expect anyone else to notice… and I was wrong. vmagnin actually did found the video, although I never posted any link to it anywhere.
@vmagnin I keep being impressed.
Anyway, this project started a few years ago, and passed several stages. I started it after trying many Multimedia libraries that are available out there. All of them have their pros and cons, but none of them was exactly what I wanted. Even worse, all of them are written in C or C++. I don’t like C and I really dislike C++ because it was meant to be an improved C and did everything wrong in my opinion. So I started my own Multimedia library instead, written 100% in the best programming language ever made, Fortran.
I am using the library on a regular basis myself, but there are some changes I consider imperative for a public release. The library uses custom home-made Fortran 2008 bindings, namely bindings for OpenGL, GLEW (graphics rendering), FreeGLUT (window contexts and text rendering), SOIL (image rendering), and OpenAL, Alut, Alure (sound support). OpenMP is used for parallelization (basically spawning threads, for example sound fade-out is done that way).
This is the underlying structure, and the programmer has full access to it, but it’s normally not necessary. The library provides “higher level” Fortran types to use instead (“classes” in… that other language terminology). For example, one could just use the OpenGL and SOIL bindings included in the library to implement a Fortran program that does animation, but the library provides a “Animated_Sprite” class to use instead, which makes things way easier.
Although the bundle I tried to describe above works well, I am not completely happy with some of the underlying libraries, mainly because they are not flexible enough to support future features I am planning to add in the library. Thus I decided to replace FreeGLUT with the GLFW and FTGL frameworks, and completely remove GLEW as a dependency. I am working on those changes but at a slow pace because the library works as it is for me and because none else was really interested, at least so far.
I also wasn’t aware of this community, which seems a great place to interchange ideas, get/give help, learn new things I was not aware of (such as fpm), or just hangout with fellow Fortraners.
Welcome to the Fortran Discourse!
Pleased to meet you @Pap on the Discourse!
@Pap , welcome to the Discourse and Mega Kudos on your brilliant effort with FML. It’s highly impressive what you have achieved with Fortran 2003 and 2008, there are certain challenges and compiler limitations (long wait times for standard features to appear and longer wait with bug fixes) that have made it rather difficult to conveniently pursue certain Fortran library design options, especially with multimedia and graphics. This has deterred in our experience some powers-that-be from funding such pursuits post 2000.
Fortran 2018 has addressed some of the language inconveniences and challenges with enhanced interoperability with C and a few other goodies; Fortran 202X will offer a few more, and hopefully Fortran 202Y will be path breaking when it comes to authoring libraries in Fortran with facilities for Generics and so forth. And compilers keep getting better. Then there is the tremendous effort by @certik et al. who have created a good modern Community for Fortran with improving ecosystem for Fortran library development. Through all this though, FML will stand out with what it achieved when!
I was waiting for years to finally see submodules supported by compilers without issues, and that’s just a small example for a feature that simplifies things and makes the code easier to read/maintain.
The problem is compilers - at least the compilers “common mortals” have access to. They were and will always be behind what the Fortran committees decide for the next standard. However i am not complaining, this is to be expected. Also, it is not always a bad thing: it forces the programmer to get the most from what he/she has, and that can lead to some useful techniques people wouldn’t otherwise bother to put the time and effort needed to develop.
What I am trying to say is having all the convenience at your hands often makes you lazy, while being somewhat limited makes you creative. I am pretty sure people behind big Fortran projects (much bigger than my humble one) learned a lot of new things just because the compilers they had to deal with were limited. As an example, consider LSODAR: it is the best ODE solver I’ve ever seen, it is used by many others such as Scilab, R, and the Matlab equivalent is suspiciously similar (my educated guess is they just copied LSODAR). And yet the original was written in Fortran 77… I am pretty sure their developers learned a lot of useful techniques, just because they had to.
Made my day.
Cool! Is there performance difference between LSODA and LSODAR? I know LSODAR added root finding stuff. But just curious is there some performance advantage of LSODAR over LSODA? Thanks!
No, there is no performance difference worth mentioning. The “bottleneck” of the solver is the integration, especially around the point(s) the algorithm needs to switch between non-stiff and stiff methods. Root finding is the easy part, and it is not mandatory either: if you don’t need root finding, you can switch it off completely. You don’t have to provide constraint functions; if you omit them, the root finding functionality is just not used.
LSODAR is just an improved version of LSODA with optional extra functionality. So personally, I see no reason to use LSODA.