Lab Manual

Lab Manual

Publications

Authorship

Rebuttal

• Start with a thank you note to the reviewers for their time and feedback. I insist on this because reviewing is a thankless job and reviewers often put in lots of time and effort to provide feedback. Even if the reviews are harsh and you disagree, do it anyway.

Data Availability

• We will always make the data available. So make sure prototypes, tools, results, etc are avail on Github.
• Github repo:
  • README.md: include a description of the project, how to install and use the tool.
  • For tools submitted to conferences, include scripts to generate the data and run the experiments.

Letters of Recommendation (LoRs)

Asking

• If you want a letter from me, you should ask at least 2 weeks in advance (ideally a month).

  • DO NOT put my name in the application system without explicitly asking me first.

• If I don't know you well enough, I will let you know and advise you to find someone else. But if you insist, I will still write you a letter.

• You need to waive your right to view the letter. It is a confidential evaluation, and I will not write one if you insist on seeing what I write.

• You should provide me your CV and, if you'd like, your SOP, so I can determine whether I could complement some of the things you've said.

  • Feel free to provide me with any other information that you think is relevant, e.g., your grades, projects, research experience, awards, etc. I might not use them if I don't think they are relevant, but they might help if I miss something.

Writing

• I will not ask you to draft a letter for me. My reputation is on the line, and I do not want a student (or AI) writing a letter on my behalf.
• I do not write negative letters, i.e., I don't say bad things about you (even if you're bad). However, if I don't know you well then a neutral, short, or generic letter will not help your case given the competitiveness.
• It takes me about an hour for a strong letter for someone I know well, and about 10 minutes for a letter for someone I don't know well.
• In all letters, at the end I will include a short paragraph about an area you need to improve, regardless of whether you're super strong or weak. But I will phrase it in such a way that the graduate study environment or a good advisor can help you overcome it. It makes the letter more complete and not just full of praise.
• I do not customize the letter for specific schools.
  • You customize your SOP to explain why you want to apply to school X and work with professor Y. I do not need to explain why you want to go to school X or why you would be a good fit for professor Y. Note that if I know you and Y very well, then I might send a letter directly to Y to mention you.
• My letter will have the university logo and my (digital) signature.
  • However, I should note that when I read a LoR, I do not pay attention to whether it has a logo or signature.

Sending

• After you put my email into the application system, it will send me a request email with a unique url to go to. It will also give me some deadline that is likely not the same as yours---usually later.
  • In some cases the systems don't even give me a deadline (various LoR request examples are shown in my Demystify book, e.g., Section 3.2.3: https://github.com/dynaroars/phd-cs-us/).
• I **do not mind if the student is anxious and sends me multiple reminders. I will likely not respond to them. But I am not bothered by reminders. Over-communication is better than under.
• Most systems simply ask me to upload the letter---though a few have short questions like comparing the applicant to undergrads or grad students. As an adcom reviewer, I don't really pay attention to these comparisons---only the letter matters.
• I usually send my letter (in PDF) in batch mode, e.g., I just sent out 10+ letters all at once and cleared my inbox of these requests.
  • For each request, it took me less than 30 seconds to upload the PDF and hit submit. So do not worry that it is time-consuming or a burden; it's not.
• After I send my batch, I'll let you know I just sent everything and ask if I missed any.
  • I would appreciate if you share an online spreadsheet showing what schools you have asked me to write letters for so I know what to expect (and if I miss something).

Updating

• Let me know your progress and especially your outcomes, e.g., interviews, offers, and where you eventually go to. I'd love to hear these updates from students.

🖥️ Servers for Dynaroars Lab

Server Specs

Our ROARS lab has four servers (pictures).

1. 🧋 Boba

   • NVIDIA DGX Spark
   • CPU: NVidia GB10 Chip, 20 core Arm (10 Cortex-X925 + 10 Cortex-A725 Arm)
   • Unified Memory/Graphic: 128GB RAM
   • OS: NVIDIA DGX OS (based on Ubuntu LTS)

   This system is ideal for AI-based projects, e.g., generative LLMs

2. 🍕 Pizza

   • Custom built
     • CPU: 32 cores, 64 threads, 3.6GHz (AMD Ryzen Threadripper PRO 5975WX)
     • Graphic: 2x Nvidia RTX 4090 24GB RAM
     • Memory: 128GB RAM
     • OS: Debian Stable

   This system is ideal for projects that can leverage many cores and specialized GPU.

3. 🍣 Sushi

   • Lenovo ThinkStation P620
     • CPU: 64 cores, 128 threads, 4.3GHz (AMD Ryzen Threadripper PRO 3995WX)
     • Graphic: Nvidia RTX 5090 RTX 24GB RAM
     • Memory: 128GB RAM
     • OS: Debian Stable

   This system is ideal for projects that can leverage many cores and specialized GPU.

4. 🌮 Taco

   • Alienware Aurora
     • CPU: 16 cores, 24 threads, 5.20GHz (Intel 12th Gen Core i9-12900KF)
     • Graphic: Nvidia RTX 3080 Ti 12GB RAM
     • Memory: 64GB RAM
     • OS: Debian Stable

   This system is ideal for experiments that need fast CPU (but not lots of core) and fast GPU.

⚠️ For Debian machines, DO NOT install any thing other than Debian stable packages to these computers (e.g., do not mix unstable or new repositories to apt sources list). You can download and install anything in your home (local) directory. If in doubt, contact us.

Getting an account

• To get an account on the server, send a request and your SSH public key (for password-less log in)

Miscs

1. You can use an IDE such as VSCode to do remote development on these servers (just connect to the server via the builtin remote login method in VSCode). You can also use other editors that support remote development (e.g., Emac + TRAMP).
2. Do take advantage of the multicores these machine have. Most programming languages support multiprocessing (e.g., Python) and can significantly reduce program runtime.
3. Periodically check top and htop to make sure you are not taking too much CPU or memory.
4. Periodically check /var/tmp or /tmp/ to make sure you are not taking too much space there.

Pictures

🍣 Sushi

🍣 Sushi Cooling System

🍕 Pizza

🧋 Boba