A project and its two workspaces

What does a project represent?

Before considering a calculation, it helps to separate the plant being represented from the question being investigated. The process model describes materials, equipment and their connections. A study adds operating conditions and, for a dynamic calculation, the logic that changes them through time. A Developer project keeps the information needed to return to that study and change it.

The editable project has the extension .dpsdev. A result recording has the extension .dpsplay. The distinction follows their purposes: the project is the description used to produce a calculation, while the recording contains the states saved from a particular execution. A recording therefore does not replace the editable project.

Why are there two workspaces?

Process Simulator presents the process model as a flowsheet. Equipment, material streams, components, size classes and model inputs belong to this part of the project. Script Manager presents the study logic: variables that can be read or written, and scripts evaluated in an order.

These are two views of one project. A feeder shown on the flowsheet can also be the target of a tag used in a script. Switching windows changes the subject being edited; it does not create another simulation or transfer data between separate projects.

The common toolbar makes this relationship visible. File commands concern the project as a whole; the workspace buttons select the model or the logic. Online execution is a later stage, after both parts have been prepared. The manual’s workspace reference documents the commands individually.

The starting example and a new project

When Developer opens without a project path, it can load the bundled Dynamic startup example. This contains an existing circuit and six scripts. It is useful for studying relationships that are already configured. File → New project creates a new authoring project from the catalog’s empty-project definition; it does not reload the bundled example.

In the example, selecting ROM feed variation in Script Manager reveals a reference to the Parameterized Feeder. The feeder is an equipment item in Process Simulator. This is the first relationship to recognize: the code refers to model inputs through named bindings, rather than containing a second copy of the equipment model.

Exercise: follow one project through both views

1. With the startup example open, use File → Save project as to keep an independent .dpsdev copy. A name such as crushing-base-case.dpsdev makes its role clear. Local saving does not require an account.
2. In Process Simulator, locate the Parameterized Feeder. In Script Manager, select ROM feed variation.csx and find the two feeder tag names in its source.
3. Return to Process Simulator. The same circuit remains present. Use File → Project information to describe the question the copy is intended to investigate, then save it.
4. Reopen the saved .dpsdev file and check both workspaces. If an interrupted session is offered for recovery, recovering and saving a separate copy preserves the original while allowing its contents to be reviewed.

Keeping a base case and a scenario

A base case records the assumptions from which a comparison begins. A scenario is a separate project copy in which one or more assumptions change. Keeping them separate makes it possible to explain why two recordings differ.

For example, a change in feed behavior should be distinguishable from a change in initial inventory or equipment availability. Descriptive filenames help, but the project description should state the actual difference. The next lesson develops the material and equipment basis before introducing the script logic.