Projects

Why?

You start working in a new engineering project. You create a folder on your computer and put all your files in there: the model, the load case definitions, the controller. After some iterations and many changes in your initial files, it gets quite difficult to keep track of input to outputs connection.

With a project in Pencilroads, you have a single source of truth for your work. Every file, every change, every output, every discussion lives in the same place and accessible to all collaborators. All collaborators can see the full history of the project and understand the context and progress at a glance. No more hunting for the latest version of a file in email threads or shared drives. No more confusion about which model was used for a particular result.

Inside a project you will find:

• Files -- simulation input decks, model definitions, design load case tables, and any other assets your workflows need.
• Workflows -- the orchestration recipes that wire actions together into complete pipelines. They are stored in a special folder .pencilroads/workflows

Public vs private projects

Public projects

A public project is visible to anyone on the internet, whether they have a Pencilroads account or not. This is the mechanism that enables knowledge transfer from academic research into industry.

Consider a university research group that has spent three years validating an aeroelastic simulation setup for the NREL 5MW reference turbine. By publishing it as a public project, they make their validated models, design load case tables, and post-processing workflows available to the entire community. A consulting firm in another continent can fork that project and build on proven foundations instead of starting from scratch.

Public projects are ideal for:

• Reference turbine models and benchmark cases
• Open-source simulation toolchains
• Educational material and tutorials
• Industry-wide standards and shared methodologies

Private projects

A private project is only visible to members of the organization that owns it. Your proprietary blade geometry, your site-specific load cases, your client deliverables -- these stay behind closed doors.

Private projects are the default for commercial engineering work where intellectual property protection matters.

Access control

Who can see and work on a project depends on two mechanisms: organization membership and project-level collaboration.

Organization members

Every project belongs to an organization. All members of that organization can access all of its projects. If your organization represents your engineering team, then everyone on the team can see every project.

Project collaborators

Sometimes you need to bring in people from outside your organization. A subcontractor running fatigue simulations, an external reviewer auditing your load case definitions, a partner providing aerodynamic input data. Project collaborators let you grant access to specific people for specific projects, without exposing your entire organization's work.

This is particularly useful for:

• Subcontractors -- give them access to exactly the projects they need. A structural analysis consultant sees only the tower assessment project, not your blade design or site data.
• Cross-company partnerships -- two firms collaborating on a joint venture can share selected projects without merging their organizations.
• External reviewers -- certification bodies or independent engineers can access the project under review.

Forking projects

Forking is how work propagates across organizations in Pencilroads. When you fork a project, your organization gets its own copy -- its own workflows, its own jobs, its own modifications. But the commit history and original assets still trace back to the source.

Think of it as branching off from a reference design. An OEM publishes a reference turbine model as a public project. Three different consultancies fork it, each adapting it for their own site conditions, regulatory requirements, and proprietary tools. When the OEM updates the reference model (new aerodynamic coefficients, corrected structural properties), each fork can sync with the upstream project to pull in those improvements.

Forking enables several patterns:

• Standardized starting points -- a company maintains a "template" project with their approved simulation setup. Every new site assessment starts as a fork.
• Community improvement -- public projects evolve as people fork, improve, and share their changes back.
• Controlled divergence -- teams can experiment freely in their fork without risk to the original project.

What comes next

A project gives you the structure to organize your engineering work: files, history, access control, and collaboration. But the real power comes from what you put inside it.

The building blocks of automation in Pencilroads are actions -- reusable, encapsulated tools that do one thing well. A file converter, a simulation runner, a data validator. Actions live inside projects and can be shared across the platform.

Continue to Actions to learn how to create and use the tools that power your workflows.