Challenge: Certifying ground-state properties of quantum 1/2-spin systems via the coarse-grained NPA hierarchy
This is the knowledge garden for the project about quantum manybody bootstrap, see the [[issue]] which was posted originally on GitHub and the [[plan]] for solution.
To view this wiki, install SilverBullet under the instructions. The SilverBullet website also has nice introductions. Then, run the following command from within this folder,
silverbullet . --port 5050where the port 5050 is randomly chosen; use the port you like. You can also deploy this wiki as a website and expose it to the public; for example via nginx to reverse-proxy your server’s live localhost to some domain name you own.
You may want to visit https://silverbullet.md for a tour of a nicely built SilverBullet space; in particular, be sure to use the Navigate: Tag Picker command, and try to understand what a Lua Integrated Query can do.
Read [[project_wiki]] to understand the underlying motivations for this wiki. Read [[Skills/knowledge-garden]] and [[Skills/technical-note]] for best practices, but you can also leave them to your agent.
Various best practices are written in the “For agents” section below, you can also read them, but be sure to copy them into your AGENTS.md files. You can also take over and use this very file as your AGENTS.md; just sym-link it to your project root!
For agents: this page (i.e. markdown file) is sym-linked to the project root’s AGENTS.md. Whenever you find patterns or workflows worthy of documenting, write them here. Log your progress and questions in the [[log]] file.
The project folder is ../hackthon-bootstrap/. That folder is stored in parallel with this garden so that they don't interfere.
You should load the [[Skills/knowledge-garden]] and [[Skills/technical-note]] skills to write into markdown files and link them via wikilinks. Only use the tag system when instructed, and always ask for specific tagging instructions: a) which domain tags we are using, and b) what tags should be attached to specific pages that we wrote.
All markdown technical notes must have yaml frontmatter
geometry:
- margin=1inso that when converted to PDF via pandoc, they have nice page margins.
Do not use linebreaks within paragraphs, instead always write each paragraph as a single line.
All math should be written as KaTeX syntax objects, and displayed formulas need one blank line before and after it. Displayed math should never be indented, its delimiters $$ should never have white-spaces before them, they should occupy the first character on a line. For example, write
Consider the formula
$$
x=1
$$
Some other text, blabla...instead of
Consider the formula
$$
x=1
$$
Some other text, blabla...Your writing style should mostly consist of simple natural paragraphs, and you can use at most one level of bullet/numbered lists. Never use nested lists.
Each numbered list or bullet list should have blank lines between each entry, so that when converting via pandoc to PDF, they don't get confused as natural paragraphs.
When you write markdown tables, never put too much content inside a single cell, and never put math formulas in tables.
Use a dedicated markdown page in the root of this space for each reference, and use a wikilink for in-line citation. This page is called a reference page, all reference pages need to have the tag #ref. Name the page in the Chicago author-year style, but add 2-3 words from the work’s title in the end, which is separated from the author-year part by an underscore. These 2-3 words should be a self-contained coherent phrase indicating the key topic of the reference. When in doubt of how many or which words to include in the title, ask the user. Use title cases in reference page names, use the underscore to join words. For example,
[[Prosen_2008_Third_Quantization]]
can refer to the reference
- Prosen, Tomaz. 2008. Third Quantization: A General Method to Solve Master Equations for Quadratic Open Fermi Systems. https://doi.org/10.48550/arxiv.0801.1257.
Here, the paper’s key topic is the technique that the author calls “third quantization”, so these two words are appended to the author-year page name Prosen2008.
The year of the paper should be determined as follows: if the paper is an arXiv preprint, then infer the year from the first two digits of its arXiv number; if the paper is already published in a journal, then the publish date determines its year.
When citing a paper in-line or pointing to its PDF, always use wiki-links without any alias, so that it is clear from the link’s name whether it points to a PDF file. Usually you should cite the reference page markdown file, not the PDF. Never use plain-text citation like “Prosen 2008”, always use a wikilink, with the exception that in a reference page, you can refer to the reference as “this work”, “this paper”, etc.
When taking notes regarding a reference, these notes should go into the reference page itself; however, when some frequently mentioned key concept requires nontrivial effort to understand, write the notes on this concept to a new page reference_page/concept_name. We will call this a “concept page”. Such key concepts can be mentioned as wikilinks in the reference page; this prevents the reference page from being too long or too unstructured.
All PDF files for the references are stored inside ./Refs/, their filenames should be identical to their page names, i.e. markdown filenames. When the ./Refs/ folder is already supplied with PDF files whose names conform to the specification above, then you should simply copy their names and create markdown pages for them. In reference pages, use the Lua function refLink defined in [[custom_functions]] to provide a link to the PDF.
The references are processed through OCR and the results are stored in ../OCR/. Folder inside ../OCR/ should always have the same name as the PDF files’ base names, which also are identical to the names of the reference pages.
You should write about the code in the manner specified in [[docs_as_code]]. All documentation that are close to the source are put in this folder, and the folder structure of ./Docs/ should match that of the source code folder of the working repository. We call such markdown pages "doc pages".
A doc page should focus on one source file and its relevant files only; all high-level technical notes that mention doc pages should be placed in the root folder of this SilverBullet space. All doc pages and technical notes about source code and how to run them should be tagged #code.
The ./Skills folder stores some skills you might want to copy to the project folder’s appropriate skills folder. Make sure to read them. They don’t have the name field yet, because SilverBullet prohibits setting this attribute manually; add this attribute to your actual SKILL.md file.