Scilab emphasizes, that the Linux world is rich with Technical / Scientific Computing platforms…

In my previous posting, I listed several (Open-Source) platforms for Computing, available under Linux at no cost, which have emphasis on Technical and Scientific applications. These platforms differ from conventional programming languages, in that conventional languages mainly specialize in allowing applications to be built, that perform a highly specialized function, while technically oriented platforms allow a user to define Math problems to be solved, to do so, and then to define a whole new Math problem to be solved…

My previous posting had also hinted that, when it comes to Computing tools of this kind, I prefer ‘the lean and mean approach’, in which the learning of specialized scripting languages would be kept to a minimum, but where, through his or her own resourcefulness, the User / Scientist knows how to apply Math, to solve their problem…

Yet, solutions do exist which go entirely in a different direction, and I’d say that “Scilab” is one of them. Under Debian Linux, one usually installs it as a collection of packages, from standard repositories, using the package manager.

Scilab is an application – and a workbench – with a rich GUI. It combines many features. But again, If somebody wanted to use it for real problem-solving, what would really count is, to learn its scripting language (which I have not done). Yet, Scilab typically comes with many Demos that tend to work reliably out-of-the-box, so that, even without knowing the scripting language, users can treat themselves to some amount of eye-candy, just by clicking on those….

 

Screenshot_20210709_062947

Screenshot_20210709_063146

Screenshot_20210709_063651

 

As I’ve stated repeatedly, sometimes I cannot gauge whether certain Scientific Computing platforms are really worth their Salt – especially since in this case, they won’t cost much more than a household quantity of salt does. ;-)  But, if the reader finds that he or she needs a powerful GUI, then maybe, Scilab would be the choice for them?

 

Dirk

 

About how I won’t be doing any ‘ASL’ computing soon.

There exists an Open-Source code library named ‘ASL’, which stands for “Advanced Simulation Library“. Its purpose is to allow application-designers who don’t have to be deep experts at writing C++ code, to perform fluid simulations, but with the volume-based simulations running on the GPU of the computer, instead of on the CPU. This can also lead people to say, that ‘ASL’ is hardware-accelerated.

Last night I figured, that ‘ASL’ should run nicely on the Debian / Stretch computer I name ‘Plato’, because that computer has a GeForce GTX460 graphics card, which was considered state-of-the-art in 2011. But unfortunately for me, ‘ASL’ will only run its simulations correctly, if the GPU delivers ‘OpenCL’, version 1.2 or greater. The GeForce 460 graphics card is only capable of OpenCL 1.1, and is therefore no longer state-of-the-art by far.

Last night, I worked until exhausted, trying various solutions, in hopes that maybe the library had not been compiled correctly – I custom-compiled it, after finding out that the simulations were not running correctly. I also looked in to the possibility, that maybe I had just not been executing the sample experiments correctly. But alas, the problem was my ‘weak’ graphics card, that is nevertheless OpenGL 4 -capable.

As an alternative to using ‘ASL’, Linux users can use the Open-Source program-set called ‘Elmer‘. They run on the CPU.

Further, there is an associated GUI-application called ‘ParaView‘, the purpose of which is to take as input, volume-based geometries and arbitrary values – i.e., fluid states – and to render those with some amount of graphics finesse. I.e., ‘ParaView’ can be used to post-process the simulations that were created with ‘ASL’ or with ‘Elmer’, into a presentable visual. The version of ‘ParaView’ that installs from the package-manager under Debian / Stretch, ‘5.1.x’ , works fine. But for a while last night, I did not know whether problems that I was running in to were actually due to ‘ASL’ or to ‘ParaView’ misbehaving. And so what I also did, was to custom-compile ‘ParaView’, to version 5.5.2 . And if one does this, then the next problem one has, is that ParaView v5.5.2 requires VTK v7, while under Debian / Stretch, all we have is VTK v6.3 . And so on my platform, version 5.5.2 of ParaView encounters problems, in addition to ‘ASL’ encountering problems. And so for a while I had difficulty, identifying what the root causes of these bugs were.

Finally, the development branch, custom-compiled version of ‘Elmer’ and package-manager-installed ‘ParaView’ v5.1.x will serve me fine.

Dirk