My name is Yan Lin. Computer science research is my career, and my research is centered on data mining, i.e., extracting and utilizing patterns from large-scale data, usually with machine learning models.
Beyond research, computer science is also one of my hobbies. I am interested in most topics in computer science, especially SysOps and full-stack development.
This is my personal blog site, where I share my experiences and thoughts on computer science research and hobbyist projects.
What are the hostnames you give to your computers and servers?
You might leave them as the default ones, which typically means that they will be composed of model numbers and other specifications, like falkenstein-debian-cpx22 or Apple iMac M3.
But that's too technical for me. I want my personal devices to be a bit more emotionally connectable.
That's why I name my devices after the characters from Oomuroke (大室家), a manga series that is a spin-off of the Yuru Yuri (ゆるゆり) series.
And you will soon see that each device is named after the character that (in my view) the device's property matches the best in terms of personality.
The host setup displayed on misaki alongside volume 4 of the Oomuroke manga series.
Below, the quote blocks are introductions to each character sourced from the official website.
Diffusion models have become a standard tool for the inverse design of materials, generating structures conditioned on target properties rather than searching for them by trial and error.
For crystalline materials this works well, with frameworks like MatterGen generating crystal structures for desired properties.
Amorphous materials, the disordered solids such as glasses, have lagged behind.
This post presents AMDEN, a diffusion framework for the inverse design of amorphous materials, and the problem that ended up at its center.
The AMDEN pipeline, where reverse diffusion turns a random sample into a structure, with the score predicted by an equivariant graph neural network conditioned on the target properties.
A diffusion model trained on glass structures can generate a sample that looks structurally close to the reference, with only minor differences in the radial distribution function (RDF) that captures how interatomic distances are distributed, while its energy is clearly wrong, sitting well above the relaxed, low-energy structures it was trained on, the ones whose atoms have settled into a local energy minimum.
This limitation comes from denoising on the energy landscapes that glasses occupy, and it is what stands between diffusion models and the relaxed structures that materials design actually targets.
Download the lecture slides for this module using this link.
Modality and Duration
Individual oral exam based on submitted project.
The duration will be 15 minutes, followed by 5 minutes of deliberation.
The agenda for each student is as follows.
The student gives a 5-minute presentation of their completed mini-project
We have a 10-minute discussion around topics and questions about the course and the mini-project
Start by randomly drawing a topic from the 6 topics listed below, using the random number generator
Should the student wish to, they may discuss their understanding of that topic. Otherwise, the examiner will start the conversation with questions related to that topic
The examiner and censor ask follow-up questions, which may relate to the student's mini-project report or other topics of the course
Deliberation will take place within 5 minutes, followed by the delivery of the assessment
The student will be asked to leave the exam room while the examiner and censor reach an agreement on the assessment
After that, the student will return to the room, where the examiner and censor will deliver the final assessment and explanation, plus personal comments and suggestions
Should the student have any doubts or questions, we can discuss them briefly
Download the lecture slides for this module using this link.
Using the knowledge from this course, we will develop and deploy an AI system in our mini project.
Outcome
The outcome of the project is an AI API server, similar to the one we implemented in Module A.4, deployed as a container running on a computer.
A client program, running on another computer, should be able to interact with this server.
Necessary Requirements
The API server should have more than one endpoint. You have the flexibility to plan the functionality of these endpoints.
Examples include:
One route <domain>/v1/image_classify for image classification and another route <domain>/v1/conversation for LLM-powered natural language conversation
Multiple versions <domain>/v1/image_classify and <domain>/v2/image_classify providing different sets of functionality
Utility routes like <domain>/v1/model for listing available AI models
Download the lecture slides for this module using this link.
In Module B.4 we deployed our AI server on a small cloud VM, gave it a domain name and an HTTPS certificate, and ended up with a real public AI service backed by infrastructure we did not have to own.
However, there are scenarios where running our system on a computer we have physical access to fits better than renting cloud capacity.
For example, a smart camera that has to react to people walking past it before they are gone, where a cloud round trip is too slow.
Or an app processing medical scans we are not allowed to send to a third party.
Maybe a long-running service we have run for years where the cumulative cloud bill has crossed the price of just buying a small server.
These cases fall under two related ideas.
Edge computing runs computation near where data is generated or where users interact with the system, instead of in a faraway data center.
Self-hosting runs services on hardware we own and control, instead of renting capacity from a cloud provider.
Download the lecture slides for this module using this link.
In Module B.3 we packaged our AI API server into a container image that anyone with Docker can pull and run.
That solves the how do we ship the software problem, but it leaves the whose machine does it run on problem wide open.
Running the container on our laptop is fine for development, but as soon as we want anyone else to use the API, our laptop becomes a bad host.
We probably do not want to leave it powered on 24/7, our home internet connection might not be reliable, and the moment the laptop goes to sleep the API stops responding.
The standard answer to this is to rent a computer somewhere else and run our container there.
That somewhere else is what people call "the cloud": a fleet of computers sitting in data centers operated by companies that specialize in keeping them powered, cooled, and connected to the internet.
We rent some slice of that capacity by the hour or the month, log into it remotely, and run whatever we want.
Download the lecture slides for this module using this link.
In Module B.2 we used Docker to run programs from images that someone else had already built and published.
That covers most off-the-shelf software, but our AI server from Module A.4 is not on Docker Hub. Nobody is going to package it for us.
If we want to run our server in a container on another machine, we have to build the image ourselves.
Building our own image is a different exercise from using one.
We have to decide what files go inside, install the Python dependencies our server needs, and pick a default command for the container to run.
On top of that, AI servers come with their own challenges that a typical web app does not have.
Model weights are large and have to live somewhere. Inference often wants a GPU, which the container needs explicit access to. The data our server collects, like users and request logs, needs to be stored somewhere that does not get wiped out when a container is removed.
