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

## The failings of low-end consumer software, to typeset Math as (HTML) MathML.

One of the features which HTML5 has, and which many Web-browsers support, is the ability to typeset Mathematical formulae, which is known as ‘MathML’. Actually, MathML is an extension of XML, which also happens to be supported when inserted into HTML.

The “WiKiPedia” uses some such solution, partially because they need their formulae to look as sharp as possible at any resolution, but also, because they’d only have so much capacity, to store many, many image-files. In fact, the WiKiPedia uses a number of lossless techniques, to store sharp images as well as formulae. ( :1 )

But from a personal perspective, I’d appreciate a GUI, which allows me to export MathML. It’s fine to learn the syntax and code the HTML by hand, but in my life, the number of syntax-variations I’d need to invest to learn, would be almost as great, as the total number of software-packages I have installed, since each software-package, potentially uses yet-another syntax.

What I find however, is that if our software is open-source, very little of it will actually export to MathML. It would be very nice if we could get our Linux-based LaTeX engines, to export to this format, in a way that specifically preserves Math well. But what I find is, even though I posses a powerful GUI to help me manage various LaTeX renderings, that GUI being named “Kile”, that GUI relies back on a simple command-line tool named ‘latex2html’. Whatever that command-line outputs, that’s what all of Kile will output, if we tell it to render LaTeX specifically to HTML. ‘latex2html’ in turn, depends on ‘netpbm’, which counts as very old, legacy software.

One reason ‘latex2html’ will fail us, is the fact that in general, its intent is to render LaTeX, but not Math in any specific way. And so, just to posses the .TEX Files, will not guarantee a Linux user, that his resulting HTML will be stellar. ‘latex2html’ will generally output PNG Images, and will embed those images in the HTML File, on the premise that aside from the rasterization, PNG Format is lossless. Further, if the LaTeX code was generated by “wxMaxima”, using its ‘pdfLaTeX’ export format, we end up with incorrectly-aligned syntax, just because that dialect of LaTeX has been optimized by wxMaxima, for use in generating .PDF Files next.

(Updated 05/27/2018 : )

## I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )