## I just installed Sage (Math) under Debian / Stretch.

One of the mundane limitations which I’ve faced in past years, when installing Computer Algebra Systems etc., under Linux, that were supposed to be open-source, was that the only game in town – almost – was either ‘Maxima’ or ‘wxMaxima’, the latter of which is a fancy GUI, as well as a document exporter, for the former.

Well one fact which the rest of the computing world has known about for some time, but which I am newly finding for myself, is that software exists called ‘SageMath‘. Under Debian / Stretch, this is ‘straightforward’ to install, just by installing the meta-package from the standard repositories, named ‘sagemath’. If the reader also wants to install this, then I recommend also installing ‘sagemath-doc-en’ as well as ‘sagetex’ and ‘sagetex-doc’. Doing this will literally pull in hundreds of actual packages, so it should only be done on a strong machine, with a fast Internet connection! But once this has been done, the result will be enjoyable:

I have just clicked around a little bit, in the SageMath Notebook viewer, which is browser-based, and which I’m sure only provides a skeletal front-end to the actual software. But there is a feature which I already like: When the user wishes to Print his or her Worksheet, doing so from the browser just opens a secondary browser-window, from which we may ‘Save Page As…’ , and when we do, we discover that the HTML which gets saved, has its own, internal ‘MathJax‘ server. What this seems to suggest at first glance, is that the equations will display typeset correctly, without depending on an external CDN. Yay!

I look forward to getting more use out of this in the near future.

(Update 09/15/2018, 21h30 : )

## I’ve just custom-compiled OpenCV.

One trend in computing is AI, and a subject related to AI, is Computer Image Recognition, which could also be called ‘Computer Vision’. And there exists an Open-Source library for that, called ‘OpenCV‘. While I tend to think of it mainly as a Linux thing, it’s also possible to download and install OpenCV on Windows.

The version of OpenCV which Linux users obtain from the package manager, tends to be an outdated version, which under Debian / Stretch, is version 2.4.9 . I have a Debian / Stretch, Debian 9 computer I name ‘Plato’, and its hardware is decently strong. But one thing I just wanted to do, was to install a more up-to-date version of OpenCV on it, that being version 3.4.2 . The way to do this under Linux, is to custom-compile. And so doing that was an overnight project this morning.

One drawback to using OpenCV remains, that it does not seem to have many working applications out-of-the-box. It offers an API, and one needs to be a very good C++ programmer, to make any use of that API. But interestingly enough, there is a demonstration application these days, called “OpenCV Demonstrator“. If one has the appropriate version of OpenCV installed, one can also custom-compile the Demonstrator.

I made some observations about these two projects the hard way this morning.

## 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

## A First, Complicated Project at Circuit Design with NG-SPICE

One subject which I wrote about in an earlier posting, was that software exists by the name of ‘SPICE’, which stands for “Simulation Program with Integrated Circuit Emphasis”. There are several variants of this software in existence, but the version which I am focusing on for now is the Open-Source ‘NG-SPICE’ system, which needs to be bundled with numerous other packages under Linux, really to be useful. One important package is ‘ngspice-doc’, but there is a whole suite of Linux packages referred to as ‘gEDA’.

Simply having tested a few demo-projects, is not the same thing as actually having designed a circuit, and having witnessed that project ‘work’, at least according to the simulation. Just last night, I did the latter, in order to get a better, working grasp of how to use the software, and also, some idea of the sort of error messages and problems which invariably occur on a first-time basis. What this means is that I actually designed a circuit using the ‘gEDA Schemtic Editor’, which is also known as ‘gschem’, and then ran multiple simulations of the circuit, discovering at first that it had performance issues as I had imagined it, modifying it numerous times, and ending up with a version of the circuit, which I could be satisfied with for now.

The circuit which I was designing, actually involved MOSFETs, because those are the most important components in circuit-design today, and surely enough, I did run into initial problems. One of the tasks which we must complete, when using active components in SPICE, is to define the component, which is as fundamental as the fact that we also don’t just put a resistor, but must also specify what the Value of the resistor is in Ohms. Well with active components, we must do something similar, which also goes under the GUI heading of the Value attribute for the component. Therefore, MOSFETs, be they NMOS or PMOS, also have values, and by default, those values are defined by a Model Card, from which the computer can predict such physical properties about the NMOS or the PMOS transistor, as what its gate-capacitance is, how well it conducts when switched to conductive, conversely when the gate-voltage is zero, etc., etc., etc..

But, because NG-SPICE (v26) is advanced software – though still not the latest version – it may not require that the user defined all these parameters each time he or she considers designing a circuit, because standard component specifications exist.

By default, our MOSFETs have Reference Descriptors that begin with the letter “M”, and not with the letter “Q”, which would stand for a Bipolar Transistor, but which the GUI of ‘gschem’ suggests for the user when he first clicks a MOSFET into his circuit. So we override that, by editing the RefDes into a text-string that has the letter “M” followed without spaces by a number.

What I next proceeded to do, was to put MOSFET-transistors into my circuit, which from the GUI, only had 3 pins. This is a common way in which MOSFETs are often diagrammed, and looked something like this:

Believing that I could just accept what the GUI had constructed, I next tried to simulate the circuit, and received the error, which roughly stated “Unable to find Definition of Model.” This error-message wasted much of my time trying to solve, because I had in fact created a Model Card for the transistors which I was going to use, and at first, I despaired that NG-SPICE might not be as good as paid-for software. But I soon learned that indeed, the following example is a sufficient Model Card for an arbitrary NMOS transistor, with which circuits can be designed:

http://dirkmittler.homeip.net/text/NMOS1.mod.txt

Similarly, we can conjure a default PMOS transistor like so:

http://dirkmittler.homeip.net/text/PMOS1.mod.txt

In actual circuit-design, we’d drop the .TXT Filename-Extension, that makes the above examples readable in a Web-browser. Not only that, but we can also use the ‘gschem’ GUI, to embed such definitions directly into the Netlist, by giving them as a ‘Model’ attribute. So what was causing this error message, in my example? The fact is that MOSFETs are 4-pin components by nature. They have a hypothetical Source, a hypothetical Drain, a Substrate Electrode, and a Gate. It’s the voltage between the Gate and the Substrate Electrode, that finally determines how conductive the MOSFET is to become. By convention, many practical MOSFET-packages tie the Substrate Electrode together with the Source lead, which also happens to make the Source different from the Drain.

By telling NG-SPICE that we’re including a ‘MOSFET_TRANSISTOR‘ in our circuit, we’re telling this program to read 4 Nodes from the Netlist, to parse what the transistor is to be connected to. But, when the GUI only provides 3 arguments, an error ensues, that garbles the attempt of NG-SPICE to parse the Netlist. That’s all. Curiously, the reverse error does not happen. If I conjure a 4-lead MOSFET-symbol from the GUI, but specify a 3-lead MOSFET (more on that below), then I obtain a well-managed error message, that tells me what the problem is.

(Updated 06/14/2018 … )

Actually, the symbols above are also different in another way. In theory, one stands for an enhancement-mode, and the other, for a depletion-mode transistor. But, because under Linux, ‘this software is divided into two departments’, effectively, this does not matter.

The GUI allows schematics to be drawn in such a way, that Netlists result, while the actual NG-SPICE software emulates what these Netlists define. It’s in the emulation of the Netlists, that the decision is also made, as to whether a component is an enhancement-mode or a depletion-mode, or a subcircuit component… ( :1 )

(Updated 06/16/2018 : )