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

 

Update to ‘polkit’ and ‘libpolkit’ today.

Modern Linux computers, that have a considerable GUI, also have a feature called ‘polkit’. The purpose of this feature is not hard to understand. There exist certain operations which require ‘root’ privileges on a Linux computer, but actual users run Graphical User Interfaces, in ‘user mode’, i.e, without elevated privileges. Usually, Linux users want to be able to do such things as to install and update packages, which requires ‘root’ privileges, but want to be able to do so using the GUI. And so the way the feature ‘polkit’ is organized, there exists a daemon running as user ‘root’, which can among other things update packages, and there exists another daemon running as the specific user, which makes requests to the ‘root’ polkit daemon, to update packages. The root daemon carries out the requested action.

This arrangement may seem to make more sense for Ubuntu, where there is no such thing in a pronounced way, as ‘root’, as there is under Debian. But even some Debian setups have partial Ubuntu installs running, and many Debian users also like the ease, of being able to install a package, just by clicking on it, and then, by convincing the ‘root’ polkit daemon, that the user in question is privileged enough to do so.

Well today, my two Debian / Jessie systems, which I name ‘Phoenix’ and ‘Klystron’, have received routine updates to the polkit packages themselves. But the rather unbalanced, immediate result of this is, that on both these computers, the user-space daemon is still running the old binary, from before the update, while a new ‘root’ daemon has been launched, as part of the update. The two versions of ‘polkit’ running on both these computers, may or may not continue to be compatible with each other.

If they should turn out to be incompatible, then in the very near future I’ll need to reboot both computers as well, which could therefore also lead to brief downtime for this blog.

I’m keeping my fingers crossed, that the new service may be running in a way that remained compatible, with the old client.

Dirk

 

I’ve just tweaked my kernel memory a little.

According to This previous posting of mine, I had set aside 270MiB of RAM, just in case the kernel needed it, on the computer I name ‘Phoenix’, to keep track of user-space programs, watching files and directories. I had also taken A Quick Glance at the way 64-bit kernel, virtual memory is organized under Linux, differently from how 32-bit virtual addresses were. Given the additional fact, that I only want to set aside 128MiB of user-space RAM, To cache my blog’s Web-pages, I decided that the earlier amount of kernel-memory was too large.

And so now I’ve reduced the amount, for ‘INotify’, to a mere 135MiB.

This computer has 4GiB total RAM.

Elaboration:

On 32-bit systems, the entire address space only had 4GB, but under no circumstances was the kernel expected to take up more than 1 GB. The computer ‘Phoenix’ is a 64-bit system, but one which only has 4GB of physical RAM. Therefore, even though it’s a 64-bit system, its kernel should still not take up more than 1GB. Yet, if I preallocate 270MB, just to perform one task, I’m pushing this system’s kernel closer to using up 1GB for real. So just for this one task, I’ve reduced this one commitment to 135MB.

Dirk

 

A Problem which can befall Dropbox under Linux (Unable to Access -Folder).

This is a problem which has happened to some of the Dropbox customers, who have the client installed under Linux:

The Dropbox Icon changes to a grayed-out icon, with a red cross, and when we click or right-click on the icon, it says it’s unable to access (its) Dropbox folder. It even asks us for our Linux Password (apparently Windows-gurus don’t understand Linux), in a bid to correct the permissions of the folder in question. Don’t enter any password. At the same time, if we have a very complex desktop-management system running, we may find that the Desktop and its management-software become laggy to almost non-functional, especially with ‘Baloo’ running etc..

In my case this was due to the combination of two factors:

  1. I had added many, systematically-named files to my Dropbox folder from another synced computer, due to backing up newly-installed software.
  2. Dropbox uses a feature called ‘INotify’, so that a program gets notified as soon as the contents of a file are changed, which that program has placed a watch on. In this case, Dropbox has a watch on thousands of files.

In my case, the following helped. On a Debian-based system, in a terminal-window, type:

 


dirk@Phoenix:~$ su
Password: 
root@Phoenix:/home/dirk# cd /etc
root@Phoenix:/etc# edit text/*:sysctl.conf

 

Then, edit the file in question, to contain the following two lines:

 


fs.inotify.max_user_watches = 262144
fs.inotify.max_user_instances = 256

 

Then, to make the changes take effect, type:

 


root@Phoenix:/etc# sysctl -p

 

What this does is set the kernel limits ‘very high’, as to how many INotify-watches it will support. For the moment, the Dropbox client on this machine is stable again.

(Updated 07/03/2018, 8h35 … )

(As of 07/02/2018, 11h25 : )

Actually, according to my own recent experience, after applying the above fix, if the limit already did run out, a reboot is nevertheless required.

And because of the needed reboot, my server was also down for about 10 minutes this morning…

Continue reading A Problem which can befall Dropbox under Linux (Unable to Access -Folder).