Universal Parallelism
Computational Reconstruction of Osul-e Movazat (اصول موازات)
A long-term scientific software project based on the research and computational models of Siamak Zandpour
Original software implementation: 2007
Re-engineered: 2026
Original research and theoretical framework: Siamak Zandpour
Software engineering and computational implementation: Soroush Neyestani
Category: Scientific Computing / Computational Modeling / Data Engineering
Current implementation: Python
Project Overview
Universal Parallelism, originally titled Osul-e Movazat (اصول موازات), is one of the oldest and most unusual software projects in my personal archive.
The project is based on the research, theories and computational models developed by Siamak Zandpour.
My role in the project has been on the software and computational side: translating parts of the underlying models and calculation procedures into executable software, structuring the required data, generating calculated outputs and developing tools through which the models can be evaluated computationally.
I first worked on a software implementation of the project in 2007.
Nearly two decades later, in 2026, I returned to the original material and began reconstructing the software using a modern computational architecture.
This makes Universal Parallelism particularly interesting to me.
It is not simply a legacy application being upgraded from one programming language to another.
It is the reconstruction of a computational system created almost twenty years earlier, where preserving the meaning of the original calculations is more important than preserving the original implementation.
Background
Siamak Zandpour developed a theoretical framework that he referred to in Persian as:
اصول موازات
and in English as:
Universal Parallelism
The research attempts to model relationships between time, astronomical configurations, geographic parameters and recurring patterns through a structured system of calculations.
Over time, a substantial body of formulas, tables, calendars and calculated material was developed around the framework.
My involvement was focused on converting parts of this computational process into software.
This required more than simply storing formulas.
The software needed to represent:
- dates and times
- geographic locations
- astronomical parameters
- calculated angular relationships
- multiple calendar structures
- daily and hourly calculations
- derived values
- historical datasets
- generated time-series data
The resulting project sits at the intersection of legacy software reconstruction, scientific computing and data engineering.
Important Scientific Context
Universal Parallelism should be understood as an implementation of Siamak Zandpour's research framework.
The software does not itself establish the scientific validity of the underlying hypotheses.
This distinction is important.
There are two separate engineering and scientific questions:
- Can the original computational model be reconstructed accurately?
- Do the hypotheses represented by that model demonstrate predictive or explanatory validity when tested against independent data?
The first is primarily a software engineering and computational reproducibility problem.
The second requires empirical validation, statistical analysis and appropriate scientific methodology.
The current project is designed to make the first question reproducible and to provide a technical foundation on which the second can be investigated.
The Original 2007 Implementation
The original software environment was very different from the one available today.
The 2007 implementation relied primarily on:
- HTML
- Excel
- manually structured data
- spreadsheet-based calculations
- generated tables
- local files
At the time, this provided a practical way to convert a complex collection of calculations into something that could be repeatedly executed and inspected.
However, the architecture had significant limitations.
Calculations and data were closely coupled.
The system depended heavily on local files.
Reproducing a calculation required understanding the structure of the original spreadsheets and their relationships.
Large-scale historical analysis was difficult.
Automated validation was limited.
Extending the system with new datasets or analytical methods required considerable manual work.
The software worked as a computational tool, but it was not designed as a modern analytical platform.
Why Rebuild It After Almost 20 Years?
When I returned to the project in 2026, simply opening the original files and continuing development was not the right approach.
The first objective was reconstruction.
I needed to determine:
- which values were original inputs
- which values were derived
- which calculations depended on other calculations
- how calendar selection worked
- how time affected the model
- how geographic information affected calculations
- how astronomical parameters were represented
- which outputs were intermediate results
- which outputs represented final model results
This is essentially a reverse-engineering problem.
The objective is not:
"How can I rewrite this Excel file in Python?"
The more important question is:
"What computational model was this Excel file actually implementing?"
That difference defines the modernization strategy.
From Spreadsheet Logic to Computational Model
A spreadsheet can hide substantial complexity.
A cell may contain a simple number, but that number may depend on:
- another worksheet
- another date
- a lookup table
- a geographic parameter
- an astronomical value
- a previous calculation
- several intermediate formulas
When the system is viewed only as a spreadsheet, those relationships remain embedded in the document.
The modern implementation attempts to make those dependencies explicit.
Conceptually, the transformation is:
Spreadsheet Cells → Explicit Variables
Spreadsheet Formulas → Computational Functions
Manual Tables → Structured Data
Hidden Dependencies → Defined Processing Steps
Static Outputs → Reproducible Calculations
This makes the model significantly easier to inspect, test and extend.
The Four-Calendar Structure
One of the important structural elements of Universal Parallelism is its use of four calendar configurations.
These are represented computationally as:
- Calendar A
- Calendar B
- Calendar C
- Calendar D
The calendar assignment forms part of the broader computational model.
Rather than maintaining four independent manual calculation systems, the modern implementation treats them as configurations within a common calculation engine.
This allows the same processing pipeline to generate results consistently across all four calendar structures.
Astronomical Parameters
The computational model incorporates several astronomical parameters used by the original framework.
These include values associated with bodies such as:
- Moon
- Sun
- Mercury
- Venus
- Mars
- Jupiter
- Saturn
The model also includes additional calculated relationships such as:
- lunar-node related parameters
- Moon/Sun angular relationships
- Jupiter/Sun angular relationships
- Saturn/Sun angular relationships
These values are treated as computational inputs or derived parameters within the software.
Their role is to reproduce the mathematical structure defined by the original Universal Parallelism framework.
Time as a First-Class Dimension
Time is fundamental to the model.
The modern implementation therefore does not treat a date merely as a label attached to a result.
Calculations can be generated across different temporal resolutions.
The architecture supports concepts such as:
- yearly ranges
- daily calculations
- hourly calculations
- historical time series
- event-aligned windows
This makes it possible to move from individual manually calculated dates toward systematic temporal analysis.
For example, instead of calculating one selected day, the software can generate structured data across extended historical periods.
That capability becomes particularly important when attempting to evaluate hypotheses against historical observations.
Geographic Parameters
Location is another explicit dimension of the computational model.
Calculations may depend on:
- date
- time
- geographic location
- associated astronomical parameters
The modern architecture therefore treats location as structured input rather than embedding it manually into individual calculations.
This creates the possibility of running equivalent analyses across different locations using the same computational pipeline.
The objective is reproducibility:
the same inputs should generate the same calculated outputs regardless of when or by whom the calculation is executed.
Daily and Hourly Generation
One of the major differences between the legacy and modern implementations is the ability to generate calculations programmatically.
The Python implementation can produce structured output for the calendar models across daily datasets.
Where required, calculations can also be expanded into hourly resolution.
Instead of manually preparing individual spreadsheet calculations, the software can execute the same computational rules repeatedly across a time range.
Conceptually:
Model + Location + Date/Time → Structured Result
This transforms the project from a collection of manually operated calculation files into a computational engine.
Historical Time-Series Analysis
Once calculations can be generated automatically, a much more interesting engineering possibility appears:
historical analysis at scale.
The software can generate time-series datasets and compare calculated model states with historical observations.
This creates a clear separation between:
Model Generation
What does Universal Parallelism calculate for a given time and location?
and:
Model Evaluation
Do those calculated values show a measurable relationship with independently observed events?
Keeping these stages separate is essential for meaningful analysis.
Event Alignment
Historical events can be aligned with generated model data.
Conceptually:
Historical Event
↓
Date + Time + Location
↓
Generated Universal Parallelism State
↓
Comparison / Statistical Analysis
This allows the model to be investigated across many events rather than selecting individual examples manually.
Such an approach is important because manually selected examples are vulnerable to confirmation bias.
Systematic analysis requires evaluating both matching and non-matching periods.
Reproducibility
One of the primary objectives of the modern implementation is computational reproducibility.
Given the same:
- model version
- input parameters
- date
- time
- location
- source data
the system should generate the same result.
This sounds obvious, but it is an important improvement over calculations distributed across manually maintained spreadsheets and local files.
Reproducibility allows results to be:
- independently inspected
- compared across software versions
- regenerated after code changes
- validated against historical outputs
- processed statistically
This is one of the central engineering goals of the modernization.
Separation of Theory and Implementation
A deliberate architectural decision is to separate the theoretical model from its software implementation.
The research defines:
What should be calculated?
The software defines:
How can that calculation be represented and executed reliably?
This separation is important for long-term maintainability.
A formula should not depend on a particular user interface.
A historical dataset should not depend on a particular spreadsheet.
An astronomical calculation should not depend on where its result is displayed.
The modern architecture therefore aims to keep:
Research Model
Calculation Engine
Data Sources
Analysis
Output
as distinct concerns.
Python Reconstruction
Python was selected for the modern reconstruction because the project is fundamentally computational and data-oriented.
The ecosystem provides strong support for:
- numerical processing
- tabular data
- time-series analysis
- data transformation
- statistical analysis
- automation
- reproducible pipelines
More importantly, Python allows the original spreadsheet logic to be transformed into explicit, inspectable functions.
Instead of hiding a dependency inside a cell reference, calculations can be represented as named computational operations.
This significantly improves readability and maintainability.
Data Pipeline
At a high level, the modern system follows a processing pipeline similar to:
Input Parameters
↓
Date / Time / Location
↓
Astronomical Data
↓
Calendar Configuration
↓
Universal Parallelism Calculations
↓
Derived Parameters
↓
Structured Daily / Hourly Output
↓
Time-Series Dataset
↓
Historical Event Alignment
↓
Statistical Evaluation
This pipeline makes each stage independently inspectable.
If an unexpected result appears, the source of the difference can be investigated systematically rather than manually tracing spreadsheet cells.
Data Outputs
The modern system generates structured machine-readable output.
Depending on the analysis, this can include:
- daily calculated values
- hourly calculated values
- calendar-specific results
- astronomical parameters
- derived relationships
- time-series datasets
- event-alignment datasets
- analytical summaries
The objective is to keep calculated data independent from its presentation.
A generated dataset can therefore be consumed by:
- command-line tools
- analytical scripts
- reports
- visualizations
- databases
- future interfaces
without changing the underlying calculation engine.
Research Validation
An important part of rebuilding Universal Parallelism is making its hypotheses testable.
A computational implementation creates the possibility of evaluating claims using historical datasets rather than relying exclusively on individual examples.
A robust evaluation process can ask questions such as:
- Does the calculated signal occur more frequently around target events?
- How often does the same signal occur when no target event happens?
- Is an observed relationship statistically distinguishable from chance?
- Does the relationship remain stable across different time periods?
- Does it remain stable across different geographic regions?
- Does changing model parameters significantly change the result?
- Can the same result be reproduced on data that was not used while reconstructing the model?
These questions are separate from implementing the theory itself.
That separation protects the software project from assuming that successful implementation automatically implies scientific validation.
Avoiding Confirmation Bias
When working with historical events and complex models, confirmation bias is a significant methodological risk.
If enough variables are available, it is often possible to find interesting patterns after an event has already occurred.
For this reason, the modern analytical approach should distinguish between:
exploratory analysis
and
validation.
Exploratory analysis can help identify candidate relationships.
Validation should then test predefined relationships against independent or out-of-sample data.
The software architecture is designed to make this type of systematic evaluation possible.
Legacy Preservation
The 2007 implementation is historically valuable to the project.
It represents how the computational model was originally translated into software using the tools available at the time.
For that reason, modernization does not mean pretending that the old implementation never existed.
The legacy artifacts provide:
- historical reference
- calculation examples
- expected outputs
- clues about original dependencies
- evidence for reconstructing computational behavior
The old implementation therefore acts as an important reference during reverse engineering.
2007 vs. 2026
The technical evolution of Universal Parallelism can be summarized as:
2007
HTML + Excel
- spreadsheet-driven calculations
- local files
- manually structured data
- limited automation
- tightly coupled calculations and presentation
2026
Python-based computational architecture
- explicit calculation functions
- structured input data
- automated generation
- daily and hourly processing
- time-series datasets
- historical event alignment
- reproducible calculations
- scalable analytical workflows
The important change is therefore not simply:
Excel → Python
It is:
Manual Calculation → Reproducible Computation
Spreadsheet Dependencies → Explicit Data Flow
Individual Examples → Large-Scale Analysis
Static Tables → Time-Series Data
Implicit Logic → Inspectable Computational Model
Engineering Challenges
Universal Parallelism presents a different modernization problem from a typical business application.
There is no conventional CRUD system to redesign.
The primary challenge is preserving computational meaning.
A technically cleaner implementation is useless if it subtly changes the original formulas.
Likewise, reproducing the formulas perfectly is insufficient if the surrounding data pipeline introduces inconsistent inputs.
The engineering challenge therefore exists at several levels:
- Recover the original computational rules.
- Identify their dependencies.
- Represent those dependencies explicitly.
- Preserve calculation semantics.
- Generate deterministic outputs.
- Separate calculation from analysis.
- Validate implementation against known historical calculations.
- Build infrastructure for independent empirical evaluation.
This combination makes the project particularly interesting from a software engineering perspective.
My Role
My role in Universal Parallelism is specifically related to its software and computational implementation.
My responsibilities include:
- reconstruction of legacy software behavior
- transformation of spreadsheet logic into executable code
- software architecture
- computational modeling
- data structure design
- automated data generation
- time-series generation
- historical dataset processing
- event alignment
- analytical tooling
- reproducibility
- technical documentation
The underlying Universal Parallelism theory, research framework and original models are the work of Siamak Zandpour.
Maintaining this distinction is important both scientifically and historically.
Technical Highlights
- Scientific legacy software reconstruction
- Excel-to-Python migration
- Explicit computational modeling
- Multi-calendar calculation architecture
- Astronomical parameter processing
- Geographic parameterization
- Daily calculation generation
- Hourly calculation generation
- Historical time-series generation
- Event-alignment pipelines
- Structured machine-readable outputs
- Reproducible computation
- Data-processing automation
- Statistical evaluation infrastructure
- Separation of model generation and model validation
- Legacy calculation preservation
What Makes This Project Different
Most legacy modernization projects begin with an old application and ask:
How can this software be redesigned using modern architecture?
Universal Parallelism asks a more fundamental question:
What exactly was the old software calculating, and how can that computational meaning be reconstructed faithfully?
That changes the engineering process.
The legacy implementation is not merely obsolete code.
It is evidence.
Its spreadsheets, tables, formulas and generated outputs provide information about the original computational model.
The modernization process therefore resembles a combination of:
software archaeology
scientific computing
data engineering
and
computational reproducibility.
What I Learned Rebuilding It
Returning to a project originally implemented in 2007 provides an unusual perspective.
The programming tools have changed dramatically.
The fundamental engineering requirement has not.
A computational system must make its assumptions and transformations understandable.
In the original implementation, many of those transformations were embedded in spreadsheets and manually managed data.
The modern implementation attempts to expose them as explicit computational steps.
This does more than improve maintainability.
It makes the model easier to inspect, reproduce, challenge and evaluate.
For a research-oriented project, those properties are significantly more important than simply using newer technology.
Result
The modern Universal Parallelism project transforms a legacy collection of spreadsheet-based calculations into a structured computational platform.
The original research framework remains attributable to Siamak Zandpour.
My work focuses on making that framework computationally reproducible through modern software engineering.
The result provides a foundation for:
- repeatable calculations
- large-scale historical processing
- daily and hourly time-series generation
- geographic analysis
- event alignment
- statistical evaluation
- independent investigation of model behavior
The objective is not to use software to declare the theory correct.
The objective is to make the theory computationally explicit enough that its calculations can be reproduced and its hypotheses can be tested.
From Legacy Calculations to Reproducible Research Software
2007 → 2026
HTML + Excel → Python
Manual calculations → Automated computational pipelines
Individual historical examples → Systematic time-series analysis
Implicit spreadsheet logic → Explicit and inspectable computation
Universal Parallelism is therefore not simply one of my oldest software projects.
It is an example of how nearly twenty years of legacy computational work can be reconstructed into a modern platform without losing the distinction between the original research and the software built to investigate it.
