HiMCM 2026 runs 4 to 17 November, and none of those fourteen days should be spent learning software syntax or discovering that two people cannot open the same file. Four tool decisions — what you compute in, how data is handled, how figures are made, and what the paper is written in — are worth settling in September, because every one of them is cheap now and expensive on day nine.
Four jobs, four decisions
A HiMCM toolchain is not a list of impressive software. It exists to do one thing: get defensible numbers and readable figures into a single written English paper, with a trail that shows where each of them came from. Everything else is decoration. Whatever you choose, the submitted deliverable is the paper — confirm the current file format, page and submission requirements on comap.org.
| Job | The decision | Decide it by | What happens if you leave it to the window |
|---|---|---|---|
| Computation | One language, one person who can debug it unaided | September, with a practice run | Two members write incompatible code, and the team spends day six reconciling instead of modelling. |
| Data handling | Where raw files live, what cleaned data looks like, who owns the results file | September | Numbers circulate by chat message. Nobody can say which version is current, and the paper quotes two of them. |
| Figures | Produced by code from the results file, not drawn by hand | October at the latest | The model changes on day ten and every figure has to be redrawn manually, so most of them are not redrawn at all. |
| The document | LaTeX, Word, or a shared editor — and one owner of the master file | September, then draft in it | The team merges four documents on the final evening, and the page limit is discovered at the worst moment. |
The pattern behind all four rows is the same. HiMCM is a modelling contest, not a timed problem-solving contest, so the model will change during the fortnight — that is normal and healthy. A toolchain is good if a change on day ten costs twenty minutes, and bad if it costs an evening.
Choosing the computation language
There is one criterion, and it is not the one students reach for. The right language is the one your computation person can debug alone at 23:00 on day nine, when something returns a number that is obviously wrong and nobody else is awake. Power comes second. A team that picks an unfamiliar tool because it looks serious has bought itself a second problem to solve alongside the modelling one.
- Python is the safe default for most teams. It is free, it installs everywhere, and one language covers data handling, numerical work and plotting, which keeps the pipeline short. It is also the most transferable skill beyond the contest.
- MATLAB is a good choice where the school licence genuinely covers every member, and it is comfortable for differential-equation and optimisation work. Check the licence before you commit: a stack that only three of four students can run is not a team stack.
- R earns its place when the core of the problem is statistical — fitting, regression diagnostics, uncertainty — and someone already works in it.
- A spreadsheet is a legitimate answer, not a fallback to apologise for. A small deterministic model, computed transparently in a spreadsheet and clearly explained, is far better than an ambitious simulation nobody could debug. Its limits are real: version control is awkward, and repeated randomised runs are painful.
- Desmos or GeoGebra are for exploring behaviour quickly — seeing what a functional form does before you commit to it — rather than for producing final results.
LaTeX, Word, or a shared editor
The document decision deserves more thought than it usually gets, because the paper is the product. Per COMAP’s contest instructions the solution runs to a limit of 25 total pages covering all solution work and additional material, with formatting expectations including a control number in the page header; confirm the current limit, header and file requirements on comap.org. Whatever you use has to hit those requirements without a crisis on the last evening.
| LaTeX (including a shared online editor) | Word or an equivalent processor | |
|---|---|---|
| Equations | Excellent, and consistent throughout a long paper | Workable, but slow and easy to make inconsistent |
| Numbering and cross-references | Automatic and stable when sections move | Manual discipline required; breaks quietly |
| Collaboration | Very good in a shared online editor; awkward if everyone edits locally | Good in a cloud version; painful when files are emailed around |
| Page-limit behaviour | Predictable; figure placement can need coaxing | Predictable, but pagination shifts as figures are resized |
| Learning cost | Real, if nobody has used it — do not learn it in November | Near zero |
The honest rule: if at least one member already writes LaTeX, use it, and set the document up in September with the section skeleton and header in place. If nobody does, use the processor everyone knows and spend the saved time on the model. A team that learns LaTeX during the contest window has traded modelling hours for typesetting hours, which is a bad exchange rate. If you want a starting skeleton, the LaTeX and section templates in our compiled preparation material are our own material, obtained by scanning the WeChat QR code in the site footer rather than from an official download, and worked material is not available for every year.
One rule regardless of choice: the master document has a single owner. Four people editing four copies produces a merge on the final night, and merges are where sections go missing.
Figures are produced, not drawn
Every figure in the paper should be generated by a script that reads the results file. This is not perfectionism; it is insurance. The moment your sensitivity analysis changes a parameter, a hand-drawn chart becomes wrong and silently stays in the document. A generated one is corrected by rerunning three lines.
- Axes labelled with units, always. An unlabelled axis makes a judge guess, and guessing is how a defensible result gets marked down.
- The caption states the claim, not the contents. “Peak load exceeds capacity above 1.4 times current demand” is worth more than “Graph of load against demand”.
- Readable in greyscale. Distinguish series by marker or line style as well as colour.
- Vector output where your document tool accepts it, so nothing is blurred at print size. Confirm accepted file formats on comap.org.
- One figure, one job. A chart that shows five things persuades of none of them.
Reproducibility, in the version a school student can actually keep
You do not need professional version control. You need four habits, all of which fit in a shared cloud folder.
- One folder, one naming convention, agreed on day zero: raw data, cleaned data, code, results, figures, document. Dates in filenames, not the word “final”.
- One results file that owns the numbers. Anything quoted in the paper is copied from it. If a number cannot be traced back to a row in that file, it does not go in the paper.
- Fix the seed for anything random. A simulation that gives a different answer each run cannot be discussed precisely, and the paper will end up hedging where it should be exact.
- Record which run produced the current draft. One line at the top of the results file is enough. This is what lets you answer, on day thirteen, whether the table in section 4 predates the assumption you changed on day eleven.
This discipline is also what makes validation possible at all. With no answer key to check against, the credibility of your results rests entirely on the visible trail from source to number to figure to claim.
Log AI assistance the day it happens
Per COMAP’s contest instructions, a team submits a separate report on its use of AI tools alongside the modelling paper, stating whether such tools were used, which models, and for what purpose — text generation, coding support, data analysis. Confirm the current requirement and its exact wording on comap.org.
The toolchain implication is practical rather than philosophical: put a plain log file in the shared folder now, with three columns — date, tool, what it was used for. Anyone who uses a tool adds a line the same day. Reconstructing that log from memory on the final evening is unpleasant, unreliable, and entirely avoidable for the price of a text file. Agreeing the habit in September also means the team decides its tooling posture deliberately rather than improvising it under deadline pressure.
The September dry run that proves the stack works
One afternoon, three hours, all four students. Take any small question — how many buses a school needs at peak times, anything with numbers — and go end to end. This is not modelling practice; it is a systems test, and the point is to break things now.
- Put a small dataset in the shared folder, cleaned by the agreed recipe.
- Write twenty lines of code that produce two or three results, and save them to the results file.
- Generate two figures from that file with a script.
- Drop them into a three-page document with the section skeleton, a control-number placeholder in the header, and captions.
- Export to PDF, check the page count behaves, and open it on a different machine.
- Then change one input, rerun, and time how long the whole chain takes to update.
That last step is the whole exercise. If a single input change takes twenty minutes to flow through to a corrected PDF, your stack is ready for November. If it takes two hours, you have found the problem in September, when fixing it is free.
Frequently asked questions
Does COMAP require a particular programming language?
Your submitted deliverable is the paper. Choose a language your team can run and defend, and confirm file requirements on comap.org.
Do we need LaTeX to do well in HiMCM?
No. Use LaTeX if someone already writes it; otherwise use the processor everyone knows and spend the saved hours on the model instead.
Is a spreadsheet model good enough?
Yes, when the model is small, deterministic and clearly explained. A transparent model you can defend beats a large one nobody can debug.
How should we record our use of AI tools?
Keep a shared log of date, tool and purpose from day one. Per COMAP’s contest instructions a separate AI report is submitted — confirm on comap.org.
This is an independent guide operated by Hanlin Education for China-based international-school students. We are not affiliated with, endorsed by, or sponsored by COMAP or the High School Mathematical Contest in Modeling, and no software named here is endorsed by or associated with the contest organisers. Rules, dates, file formats, page limits and submission requirements are set by COMAP — confirm current details on comap.org before acting on anything here. Factual errors are corrected within 7 working days of notice.