Ginger Gengar's Git Server

About

Sat, 24 Sep 2022 00:00:00 +0000

Greetings,

I am Ginger Gengar, and I am not going to reveal my true name, but I am the author of these projects and this site.

I have a few hobbies like playing board games, and watching some movies. I am also into Scuba Diving, snorkelling, swimming and generally water sports. I also enjoy fishing, and a bit of cooking I guess, though I am not going to advertise myself as a great cook. I also like taking pictures to a certain extent just to remember my good memories.

So I guess I will tell you a story how I managed to develop all of these projects. I always wanted to become an engineer because I wanted to build all sorts of useful and cool new things.

I originally became extremely invested in classical physics because I needed to model the real world theoretically. When I realized that many of the modelling that occurs in classical physics was mathematically based, I became invested in both classical physics and mathematics heavily.

At this point I was already “controlling” a large chunk of information and I just realized that there will be some kind of limitation to how many things I can remember at a GIVEN time. Although I was kind of discouraged, I decided to settle for the next best thing.

If the amount of knowledge I can control at a given time is limited, at least the knowledge I can quickly access and relearn should not be limited as such. This is the original reasoning as the start of the Knowledge Archives Project. I also learnt LaTeX to support this project.

In university, I realized very quickly that there will be limitations to analytical hand-written solutions, and numerical methods were needed to get the real answers. This forced me to transition and invest into programming.

I started with C and then learnt C++ and Python. It was very hard at first and I spent alot of sleepless nights fixing compilation errors and terminating infinite loops. Eventually I got familiar and it became much much easier. Originally I used Visual Studio for all of my programming work. Thinking back at it, I still laugh at how I used to be.

At this point I felt that I still haven’t got enough practise with C++ so I wrote the Neural Network Backpropagation Algorithm. I thought it was quick, just taking me 2 days. I was very wrong, it ended up taking 2 weeks. Many errors were produced and I learned valuable lesson on the importance of planning before implementing an algorithm.

Several important things happened when I tried writing the Neural Network backpropagtion algorithm. I tried installing a linear algebra library named eigen, and was absolutely frustrated with the non-existence of a good package manager in a Windows System. So I migrated to Ubuntu to code better and also to use the package manager to install eigen. I also migrated the Knowledge Archives project and realized I could compile LaTeX really easily on a linux machine.

The migration to Linux turned out to be a much larger thing than I originally realized. I quickly learned how to use text editors and how to use command line programs and so on. Once I got that done, I started using LaTeX for all of my major projects and assignments.

After that was completed, I really loved the entire digitization of my work and wanted to have a machine whose User Interface I’ve customized to my own needs. I envisioned a machine that could get my work done much more effectively and something that allows me to be much more productive, so I decided to migrate from Ubuntu to Arch Linux.

That was very difficult. Trying to to set-up the way down in the hardware level was challenging, but I persisted and now I have an Arch Linux set based on my own preferences. From this new computing environment, I combined alot of theoretical aerodynamic and fluid mechanics with programming and gave rise to the Steger-Warming Projects, the compression ramp project and more.

Changing to Arch Linux exposed me to the full force of the open-sourced world. Firstly I used Neovim as a text editor, and then combined it with UltiSnips to allow me to write extremely fast LaTeX representations. I was very heavily inspired by Gilles Castille and I am very thankful I stumbled upon his blog post. I still believe my hand-writing is faster than my LaTeX writing, but my LaTeX capabilities rose greatly with the integration of UltiSnips. Also I use VimTex to jump between the different sections and toggle some of the equations as needed.

At this point, I have only made system changes. I got exposed to Sympy and realized that I could cross-check alot of my assignments using Sympy. So I integrated Sympy along with Bash scripts to automate the verification of my engineering work.

I guess this is just a story of how my academic performance came to be.

Showcase

Sat, 24 Sep 2022 00:00:00 +0000

I guess these are just some nice pretty pictures or animations you can look at from the projecs that can be found within this page.

Automated 2D Airfoil Testing Algorithm

Sun, 18 Sep 2022 00:00:00 +0000

This is a bunch of bash scripts and Python scripts that is used to automate the testing of a bunch of airfoils by running XFoil.

XFoil is a program written by Professor Mark Drela of MIT. It is a low-order model that can be used to make effective predictions of airfoils at low Reynold’s Numbers.

This project can be used to select airfoils for preliminary aircraft design. Python with its extensive libraries like Numpy and Matplotlib is then used for some data visualization capabilities and data analysis of “choosing” which airfoil we would like.

Documentation would be written for this as well.

Aircraft Sizing Algorithn

Sat, 27 Aug 2022 00:00:00 +0000

This is an algorithm that sizes an aircraft

Arch Linux Tutorial

Tue, 12 Jul 2022 00:00:00 +0000

This is not supposed to be a documentation on how to use Arch Linux in general. This is just the documentation on how to use MY SPECIFIC Configuration of Arch Linux. This is just to help those who are new to the Linux ecosystem and would like to learn as fast as possible how to turn their work-station into an effective productivity engine.

1D Steger-Warming Inviscid Flow Solver

Sat, 26 Mar 2022 00:00:00 +0000

This is an implementation of flux vector splitting using the Steger-Warming Method in C++. It is currently set to solve the Riemann Shock Tube Problem.

The Riemann Shock Tube Problem is an inviscid 1-D problem wherein a tube with a membrane separating high pressure gas and low pressure gas has that membrane suddenly punctured. The result is a seris of expansion waves running through the high pressure section making the high pressure section move and decreasing pressure and temperature. Shocks will run throughout the low pressure section making the gas there move and increasing its pressure in a discrete jump.

Currently, this simulation can predict shocks and expansion waves forming correctly within the Riemann Shock Tube Problem. Associated documentation for the theory behind it is also included although it is lacking.

Certainly this project can use more work particularly in proving the theories and where they come from. Perhaps an integration with the Knowledge Archives Project is appropriate. This code is also serial, which is kind of limited. To be honest, this is unlikely to be of real practical use, it is probably just useful as an educational tool of how flux vector splitting techniques can be implemented.

LaTeX Tutorial

Tue, 08 Mar 2022 00:00:00 +0000

This is not supposed to be a comprehensive Documentation on how to do LaTeX, for that we have CTAN. This is just meant as a short introduction of how I used LaTeX for my work. It emphasises on communication of technical mathematical ideas. It also introduces a bit of general house-keeping like sectioning and structuring of the document and so on. Basic things like package inclusion is also included.

Compressible Flow Library

Sat, 19 Feb 2022 00:00:00 +0000

This is a library for compressible flows that is written in C. A Makefile has also been included to compile the different parts of the code into object code. Linking it with Main is the user’s responsibility. Here is a list of things which this library could compute:

Isentropic flow relations
Normal shock relations
Oblique shock relations
Prandtl-Meyer expansion
Area relations for isentropic flow
Template for a Bisection Solver
Template for a Newton Method Solver
Some Ideal Gas Conversions
A little bit of Unit Conversion capability

2D Compression Ramp

Tue, 15 Feb 2022 00:00:00 +0000

This project attempts to compute the “optimal” ramp for a 2-D supersonic jet inlet. The “optimal” ramp here is defined as a ramp that allows the incoming airflow to experience as little loss of stagnation pressure. The constraint is that the shock waves that is used to slow the airfoil must all be contained within the engine inlet so it does not cause massive wave drag to other components, this calls for a series of gradual oblique shock waves impinging on a single point at the engine inlet. More details will be provided in the documentation.

This proejct has the bulk of its computation performed in C++, but post-processing of producing the various plots is handled using Python and the matplotlib library.

The code documentation is poor and very lacking.

Knowledge Archives

Mon, 17 Jan 2022 00:00:00 +0000

Rationale:

Document Philosophy:
Part of the original intention of the Archives Series Project began in an effort to preserve some of the most general and powerful mathematical techniques I learned. The Project began as a way of archiving oneself's skills at the peak of performance in case it would ever be needed again one day. Along the way, I was posed with a few important question "Why is this Archive Necessary?", "Couldn't we just refer back to the original textbooks and sources of the Archives?" "What sets such an Archive different than the multitudes of other textbooks that exist out there?"

In my humble opinion I believe that writing and giving names to mathematical objects is a pre-requisite to mathematics. It is impossible to do mathematics without definition of terms, and the notation of the terms are closely related to the definition of terms. Since the intimate relationship between notation and definition is so important, uniting various sources with differing notations under a unified consistent notation style ensures that the information discussed in this document is easily readable provided one learns the notation convention defined along the discussion. This guarantees an ease of information absorption and allows the powerful general mathematical theorem in this document to reach its maximum ease of use without compromising generality.

This calls for the implementation of a series of supposed rules that govern the document. Although not all parts of the documents currently adhere to said rules, this should be a kind of standard that should be achieved in due time for this document to fully implement the principles stated above:

1.) Theorems presented in the document must contain Proofs

2.) Each difference in line or after an = sign, there should be a maximum of 2 similar mathematical operations algebraic operations performed.

3.) Observations should be explained and the types of variables as mathematical objects must be defined within the scope of the theory (Is x a vector? Matrix? Tensor? Real? Complex?) (Is \times a cross product or an algebraic multiplication?)

4.) The inputs and outputs of the functions produced as a consequence of the mathematical theorems must be clearly defined as said mathematical objects.

5.) The Document must not include any examples to make it concise and helpful. Examples may be defined in a seperate document. But not this one, because it has to be concise.

6.) The proof of theorems found in this document should be replaced if a more elegant proof appears.

Objectives:

Resolve knowledge dependency issues

A particular topic should have its pre-requisite topics made clear. For example, the knowledge of derivatives and integrals is a pre-requisite to differential equations.

As much as possible, dependency "loops" have to be avoided. This is particularly deadly and here's how it works: Topic A depends on a learner understanding topic B, but topic B depends on the learner understanding topic A. In essence, one has to understand either one of the topics to even be able to understand both and this defeats the purpose of the project. The way such a thing can be avoided is to first ask learner to use suspension of disbelief, or just declare something as a definition, and then the resulting theorem should justify said definition or explain why the suspension of disbelief was initially correct.

A particular document should always be able to trace its path back to "first principles", which are either nested in physical observation like Newton's 2nd law or some definition agreed upon definition, for example definition of integers.

Segmentize knowledge into small parts

Document should be split into small modular pieces. This helps with recyclability. 

In general documents should be attempted to be kept as small as possible. However, if a group of particular topics are really interrelated, they should be included in the same file. For example, it wouldn't make sense to have integral and differential continuity fluid mechanics split in different documents. Continuity integral form is built on top of differential continuity form, and in many instances, continuity integral refers to many variables of differential continuity. So there is some tradeoff in which knowledge should be grouped together and which could be split. If two topics are not too interrelated, they can be split.

Doing this also has advantages particularly when collaborating. Files allow the writing of the archives to be more distributed, and makes it easier to do merges.

Generalization and Abstraction

Generalizations allow equations to become more 'powerful' in that they are able to describe a wider variety of cases.

However, the more generalizations and abstractions are implemented on a particular topic, the harder it is to write, and the harder it is to understand for the inexperienced learner.

Enact Variable Naming Standardization

Variables should be named. If a variable was never or defined, it shouldn't be used. Always assume the worst case that learner does not recognize any form of variable naming conventions. Additionally, variable naming conventions are very loose. x can represent so many different things across many different fields and sometimes even within the same field.

Variables should be named consistently. suppose 'v' signified velocity, then as much as possible, 'v' should not represent some other quantity, for example volume. 

However, this is very difficult as the range and lists of the topic grows, so does the number of variables that need to be described within the archives project. For this reason, scopes must be declared. A particular variable should be defined in a particular scope, say within these group of documents, 'v' should represent velocity, but other than these document, 'v' could represent something else.

To Do:

There are a couple of issues with the reformatting of the project. Particularly in producing a "dependency tree". Here is the vision: A graphical interface exists that shows the dependencies of the topics. Based on the dependencies of the topics, then end user can simply choose a particular topic and a custom-made document can be arranged from the dependency tree to go as far back as first principles as first principles allows. 

This would mean that each topic under a different circumstance could be shelved under section, subsection, subsubsection, chapter, or even part, which means if we want to make the document structure custom, then the document structure must be dynamically allocated, not static. Therefore, sections, subsubsections, and other similar constructs must be stripped completely from the archive individual content files. 

So now, how does document generation work? A secondary method, (probably some computer programming language) must have a rather complex data structure that can represent a "tree". Most probably a bunch of objects with pointers to each other. Each node of the tree represents a "content" file in the archive directoy which contains LaTex code about theoretical content. Meaning that each node must have: Name of the topic, and address of the content file. Pointers can then be used to represent what THAT particular topic is a dependency tree to. So if A points to B then A must be the dependent theory to B. So a particular object can point to multiple other objects and the same that multiple other objects can point to a single object. 

So probably using a programming language write a program which can generate "include" files, which are essentially import statements everywhere and sections and subsection statements, to write the "custom" document.

The environments must also be discussed. It made sense at some point that each of the archives say math archives and physics archives or fluid archives would have their own separate environment declarations, however this might be an issue. Perhaps it's best to use a tiered inheritance system, wherein say all the archives like math archives and fluid archives share some common environment such as amsmath, but then inside the individual archives, additional environments pertaining to that particular archive may be declared. 

The way environments are included should be similar to how content is included.

More experiments needed to be performed on standalone and import and usepackage. This is a major source of headache. For some reason standalone does not allow for begin{center} end{center} environments and I dont know why.

Of course, more content need to be added, especially structures is very very lacking. Math archives need to be revamped for the PDEs, this is so embarassing.

Folders

The Utility folder contains certain scripts that can clear the build files from the latex compiler.

Airfoil Conformal Mapping

Thu, 04 Nov 2021 00:00:00 +0000

Conformal mapping is an exact method, unlike thin airfoil theory. It relies on invscid flow assumptions though, which is bad because it cannot predict drag, stall or separation, but it can be used in conjunction with Boundary Layer Techniques to be used in determining a good airfoil analysis.

Neural Network Backpropagation Algorithm

Sat, 18 Jul 2020 00:00:00 +0000

This is an implementation of a Neural Network Backpropagation Algorithm that was written purely in C++. It works, but is not very high performing. This was my first “large” project written in C++.

Mon, 01 Jan 0001 00:00:00 +0000

Proprietary Vs Free Software

When I have to make choices between 2 softwares, the very first thing that comes to mind is what kind of license does it use. If it is proprietary, then I would try to avoid it, but if it is open-sourced, I would use it.

The reason why I use open-sourced tools is because I can have easy access to the source code. I don’t have to pay premium member fees, nor am I fully dependent on the developers of said software. If I used for example Ansys Fluent for alot of my Computational Fluid Simulations, I have to either pirate the software, or pay an exorberant fee. I don’t like that one bit. I understand that there is a cost to manufacture of software, but the idea that I would be at the mercy of the developers upstream, for my work, is intolerable.

I emphasize independence alot. No matter where you are, you should have the freedom to pull all your configurations and system from some cloud server somwhere and have a workstation ready to be used within 15 minutes of just plugging a USB with a simple script in it. Excuses like “Oh Microsoft isn’t cooperating with me” or “I don’t have a license for CFX” shouldn’t be an issue.

As an engineer, you should have the complete array of your past experiences and tools fully performant when you best need them. This is why I avoid proprietary software like a plague. Mind you, I don’t mind paying for software, as long as I end up getting source code and I can do whatever I want with it.

GUI Vs CLI

This is a big one. I do understand how convenient the Graphical User Interface (GUI) really is, but I still prefer doing things using the command line interface (CLI). The reason to that is because often times, I am not interested in just one specific case. I am interested in a variety of cases. Now if you are used to perform tasks with the mouse, it is not replicable through the computer language, or is difficult to replicate. But if you use the command line interface, then we can write a simple Bash script to automate the testing of various cases as we please.

So the tradeoff between GUI and CLI is that GUI is certainly easier to use, but CLI is automatable, and automation is very important because you can make your computer do your job for you and move on with your life to do something else.