Exporting to Excel
Choose the export that matches what your colleague needs: editable spreadsheet calculations, current results, or the complete Grid model.
Exporting to Excel
Choose the export that matches what your colleague needs: editable spreadsheet calculations, current results, or the complete Grid model.
| Export | What the recipient receives |
|---|---|
| Export as Excel / Export Excel | Supported calculations as spreadsheet formulas, with their named dependencies and current editable input values. |
| Export Excel values | Current worksheet and named results without model formulas. The filename ends in .values.xlsx. |
Grid document (.gridoc) |
A portable Grid archive carrying supported model-owned source, assets, and state. The receiving Grid installation must provide its required capabilities and connections. |
The formula and values choices described here are recorded in the 0.66.5 draft and require a matching new build. The installed 0.66.4 application used in the materials-science evaluation predates these fixes; authoring the source changes does not update an existing installation.
Share an editable calculation
- Check the model's inputs and results in Grid. If you are using a saved scenario, restore its inputs before exporting.
- Choose File → Export as Excel, or Export Excel in the import/export controls. This is the formula export.
- Read any diagnostics. If the export cannot represent a required part of the calculation, it stops with an explanation and the available alternatives.
- Open the workbook in the receiving spreadsheet application. Change an input within its intended numeric domain and check a known result before sharing the workbook further.
Formula export uses the current values of declared inputs, including active input overrides. Other supported calculations retain formulas. The receiving spreadsheet is asked to recalculate when opening the workbook. The exported workbook is an independent copy; changing it does not update the Grid model.
Where named equations go
Grid can name an input or intermediate equation without placing it in a worksheet cell. Excel formulas still need a resolvable reference to that value. The export therefore adds a Grid Values worksheet containing the required named inputs and calculations. If that sheet name is already used, it chooses a numbered alternative.
The first column identifies each Grid name. Values and formulas occupy the adjacent cells, and editable declared inputs are highlighted in yellow and annotated. Worksheet formulas reference these supporting cells. Names from different Grid scopes remain distinct. Keep the supporting worksheet when moving or sharing the exported workbook.
Supported named arrays of values are represented as rectangles on this sheet,
so a calculation such as SUM(Measurements) retains its data range. A named
array alias can refer to that same rectangle. This does not promise support
for arbitrary dynamic arrays or worksheet spill behavior.
Calculation scope
The formula path targets supported numeric calculations at their current input types. It preserves explicit expression grouping, ordinary named dependency chains, supported scalar literals, compatible function calls, and bounded worksheet ranges and shared formulas. Small constant arrays can be used where the exported expression has an equivalent spreadsheet form.
Keep inputs in the documented units and numeric domain. For a model that uses numbers labeled in meters, enter meters. Replacing a numeric input with text, a different representation, or a different unit convention can invoke the receiving application's coercion rules. An export is not a proof that every future edit will behave identically in Grid and every spreadsheet application.
Grid validation contracts and some presentation policies are not enforced by
spreadsheet formulas; their loss is reported. Review those diagnostics along
with the model's assumptions. Preserve a .gridoc copy when Grid's type,
validation, or execution behavior is part of the intended calculation.
This includes VALIDATE FIELD rules on individual record members. Formula
export reports their loss even when the record has no whole-record VALIDATE
rule. Excel export does not convert these rules into spreadsheet data validation
or preserve Grid's atomic validation of sibling input changes. Other unsupported
record expressions may still cause formula export to refuse the model. A values
export remains a static snapshot and does not enforce either kind of rule.
Unsupported behavior
Formula export refuses constructs it cannot preserve. Examples include:
- Physical-unit or currency tags, custom unit declarations, exchange-rate
directives, and
CONVERT. Unit labels written as ordinary text or included in a variable name remain usable; they do not perform unit conversion. - Strict dimensional or coercion enforcement, typed tensor precision contracts, and other Grid-specific value representations.
- Reactive rules, state/default override behavior, schedules, lazy or conditional assignments, external capabilities, and declarative solvers.
- Grid-specific functions without a supported spreadsheet translation, including the PDE and nonlinear-fit workflows used in the materials study.
- Worksheet array outputs that require spill behavior, including references to a multi-cell named array. Supporting a named data rectangle does not make every array-returning calculation portable.
- Arithmetic or comparisons that require nonnumeric or unknown operand coercion; text concatenation is supported when its operands are known strings.
- Circular dependencies, external workbook references, unresolved named dependencies, ambiguous overlapping assignments, and forms outside the supported range representation.
- A blank literal inside a formula when translating it would turn a genuinely
blank value into an empty string. An empty worksheet cell remains distinct
from the string
"".
When an export is refused, choose Export Excel values to share the current
worksheet results, reduce the calculation to a supported subset, or share a
.gridoc document for continued work in Grid. Formula export does not silently
replace an unsupported calculation with a static value.
Size limits
The exchange operation has a budget of 100,000 cells. This is not a limit on Grid models: it bounds source cells, addressed range cells, materialized formula cells, and exported cells during this particular conversion. Repeated range references can consume the cumulative addressed-range budget even when the worksheet contains fewer than 100,000 distinct cells.
The exporter also refuses dependency or expression nesting beyond 256 levels, more than 1,000,000 expression or expanded-reference nodes, formulas longer than 8,192 characters, text cells longer than 32,767 characters, and coordinates outside Excel's worksheet limits. Use a smaller model or share the Grid archive when these bounds are part of the calculation's size. Values export also has a 100,000-cell bound; it is not an unlimited route around the formula budget.
Share current results
Choose Export Excel values when the recipient needs the current worksheet results without editable model calculations. The export reports that it is a values snapshot and includes no model formulas. Current named values appear on a supporting Grid Values sheet; arrays, objects and native records are represented as JSON text with a diagnostic. Nested typed values and report fields are retained. A structured value exceeding Excel's 32,767-character cell limit stops export with a Grid-document alternative. Editing those values does not re-run the Grid calculation.
This option is useful for solver outputs or other supported result displays whose generating calculation depends on Grid. It is not a complete model backup, a saved scenario, or a guarantee that rich Grid objects become spreadsheet-native objects. Check the receiving workbook's representation of any non-scalar result.
Example: diffusion during heat treatment
The canonical materials-diffusion-exchange.grid example in Core
uses synthetic inputs for constant-temperature diffusion into a semi-infinite
solid. It assumes constant diffusivity during the treatment, a fixed surface
concentration, and an initially uniform bulk concentration. Units are explicit
in names and labels; the portable calculation uses ordinary numeric values.
At 1000 K, a 3600-second treatment and a depth of 0.0001 m give approximately:
| Quantity | Reference value |
|---|---|
| Diffusivity | 9.7347136e-13 m²/s |
Diffusion length, sqrt(D*t) |
5.9198791e-5 m |
| Concentration | 0.3858379883 wt% |
After changing the temperature input to 1100 K, diffusivity is approximately 4.4989867e-12 m²/s and concentration is 0.6627775552 wt%. These checkpoints make it possible to verify that the recipient can edit the input and recalculate the dependency chain. They are educational calculation checks, not fitted properties of a specific material or experimental validation.
A compact version of the calculation is:
input Temperature_K = 1000
input Time_s = 3600
input Depth_m = 0.0001
# Synthetic parameters; use temperature > 0, time > 0, and depth >= 0.
Diffusivity_m2_s = 0.00002 * EXP(
-(140000 / (8.31446261815324 * Temperature_K))
)
DiffusionLength_m = SQRT(Diffusivity_m2_s * Time_s)
SurfaceFraction = ERFC(Depth_m / (2 * DiffusionLength_m))
A1 = "Concentration (wt pct)"
B1 IS number = 0.2 + 0.8 * SurfaceFraction
For the PDE_SOLVE_1D options-record contract, see the
function catalog. PDE results can be shared as
values; the solver itself remains a Grid calculation.