The report document

The report document is a proper A4 PDF: a calculation memo assembled from modules you tick, given a name, and generated on the server. It is created the way a sheet is created, in its own section of the Prints tab, and it arrives by email rather than in the browser, because a real one is too heavy to hand over any other way.

This is not the same thing as a report block on a sheet. A block is a table you place on paper and that goes out in the DXF. The document is a standalone PDF that arrives in your inbox. Both exist, and they are for different jobs.

Eight modules, in the order they print

Each module is a chapter. Ticking one adds it to the document and its position is fixed, so the section numbering always runs in order regardless of what you left out. An empty document is a valid document; so is one that is only the summary.

·

Cover and identification

on by default

The project, the engineer of record, the date and your letterhead.

1

Methodology

on by default

The code in force, the assumptions taken, and what the engine actually solves.

2

Engine benchmark

The published cases the engine reproduces, each with the deviation measured against them.

3

Model and design basis

on by default

Supports, load cases, and every combination written out in full.

4

Summary of checks

on by default

One line per bar, with the governing utilisation.

5

Bar by bar verification

on by defaultgrows with the model

Forces, diagrams and the code equation with the numbers substituted in, for every bar.

6

Appendix by class

on by default

A compact table of all the bars, grouped by class.

7

Connection reference by node

paid export

Which connection exists between which two bars, node by node, with its utilisation.

The bar by bar chapter is the one that decides the size of the file. It writes out the forces, the diagrams and the substituted code equation for every bar in the model, so it is the difference between a document of a dozen pages and one of a few thousand. That is exactly why the PDF is emailed and not downloaded from the tab.

Generating it

1ComposeName it, tick the chapters2GenerateThe project is sent up3The server printsPage count reported live4EmailA link to the finished PDF
The job lives on the server. Once it is accepted, the browser is only watching.

It needs a saved analysis

The server assembles the document from the analysis it has stored for the project, not from what is currently on your screen. If there is no saved run, generation is refused and says so. Run the analysis, let it save, then generate.

Closing the tab cancels nothing

Once accepted, the job runs on the server and the email is sent from there. Losing the page loses the progress bar, not the document. The screen says as much when it stops following a job that is still running.

The composition travels with the project

A report you composed is saved inside the project, the same as a sheet. Open the job on another machine and the document is there, with its name and its ticked chapters, ready to generate again.

Why the connections chapter carries a padlock

That chapter carries vector geometry of the structure: the minimap and the dimensioned figures. Measured on the real production path, its PDF converts into a DXF with one line per bar in the model, which is precisely what the DXF and IFC exports charge for. Gating it keeps the free memo from handing over the export through a side door.

The server is what enforces it. The padlock on screen exists so you can see the chapter is not included, instead of receiving a document that is quietly missing it.