> ## Documentation Index
> Fetch the complete documentation index at: https://calcs.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Remote Widget

> Connect to server solvers for complex calculations and FEA analysis

The Remote Widget is the sheet widget used to communicate with server solvers. It enables templates to perform complex calculations that require server-side processing, such as finite element analysis (FEA).

<Note>
  See the [private API reference](https://app.clickup.com/6927027/docs/6kcnk-1766/6kcnk-618) for comprehensive documentation of all available solvers.
</Note>

## Example Code

```json theme={null}
{
  "type": "sheetTemplateWidgets",
  "attributes": {
    "type": "remote",
    "symbol": "",
    "equation": [],
    "solver": "",
    "referenceId": "remote",
    "references": "",
    "description": "",
    "authorNotes": ""
  }
}
```

## Key Attributes

### Core Configuration

<ParamField path="type" type="string" required>
  Must be "remote" - defines the widget type
</ParamField>

<ParamField path="symbol" type="string (KaTeX)" required>
  The symbol for the remote widget rendered in KaTeX. Appears in equations where values returned by the solver are called
</ParamField>

<ParamField path="solver" type="string" required>
  Indicates which solver the remote widget requests from the server. Solvers are written in Python and are specific in usage (e.g., portal frames, beams, concrete beams are individual solvers)
</ParamField>

<ParamField path="referenceId" type="string" required>
  Unique reference ID of the remote widget. Can be called by Field Reference Function, but returns the resolved object from the solver requiring specific property calls
</ParamField>

### Equation Configuration

<ParamField path="equation" type="array" required>
  Behaves like equations with conditions, but the `"result"` type is specific to solver communication
</ParamField>

The `equation` parameter expects a specific format:

```json theme={null}
{
  "condition": "@default",
  "result": "{L:L_total, r:supports, latitude:projectDefault(\"latitude\"), ...}"
}
```

<Warning>
  The `"result"` accepts a dictionary that is sent to the solver, where the solver recognizes the keys in the dictionary.
</Warning>

### Documentation Fields

<ParamField path="references" type="string" required>
  Standardized reference to the building code and major version from which the field is sourced/based upon
</ParamField>

<ParamField path="description" type="string">
  Minor explanation providing context, definitions, or clarifying information to the user about the field
</ParamField>

<ParamField path="authorNotes" type="string">
  Internal development notes never displayed to users. For Calcs.com developers to document implementation details, future updates, etc.
</ParamField>

## How It Works

1. **Data Preparation**: The remote widget collects input parameters from the template
2. **Solver Communication**: Sends a dictionary of parameters to the specified server solver
3. **Processing**: The solver performs complex calculations (often FEA or advanced structural analysis)
4. **Result Return**: The solver returns a complex object with calculated results
5. **Property Access**: Template accesses specific properties from the returned object using field references

## Available Solvers

Solvers are located in the `./solver` directory and include:

* **Portal Frame Solver** - For portal frame analysis
* **Beam Solver** - For beam calculations
* **Concrete Beam Solver** - For reinforced concrete beam design
* **Frame Solver** - For general frame analysis
* **Cross-section Solver** - For section property calculations

<Note>
  Each solver has specific input requirements and output formats. Refer to the solver documentation for detailed parameter specifications.
</Note>

## Field Reference Function

When calling a remote widget through field references, remember:

* The widget returns the complete solver object
* Specific property calls are required to obtain individual values
* Use dot notation to access nested properties in the solver response

## Best Practices

<Tip>
  * Always specify the correct solver for your calculation needs
  * Provide comprehensive input dictionaries with all required parameters
  * Use meaningful symbols that clearly indicate the solver's purpose
  * Document solver inputs and expected outputs in `authorNotes`
  * Test solver responses thoroughly during development
</Tip>