RESEARCH INTEGRITY INVESTIGATION CAMPUS LOCATION: THE UNIVERSITY OF TEXAS AT AUSTIN SUBJECT ENTITY: COPERNICUS TRAJECTORY DESIGN & OPTIMIZATION SYSTEM PROTOTYPE (CIRCA 2001–2002)


STATE OF TEXAS

COUNTY OF TRAVIS

Before me, the undersigned notary public, on this day personally appeared Bill H. Clark, P.E. (Retired), known to me to be the person whose name is subscribed to this instrument, who, after being by me duly sworn, deposed and stated under oath as follows:

  1. My name is Bill H. Clark. I am a resident of the State of Texas, a retired Professional Engineer (Texas License #74416), and a graduate student alumnus of the Department of Aerospace Engineering and Engineering Mechanics at the University of Texas at Austin. I have personal knowledge of the facts stated herein, and they are all true and correct.
  2. This affidavit is submitted formally to the Research Integrity Officer (RIO) at the University of Texas at Austin to document the absolute technical, chronological, and algorithmic critical path linking my copyrighted 1998/2000 Mars Pathfinder 2.0 software framework to the original 2001/2002 Copernicus trajectory prototype attributed to Dr. Cesar Ocampo.

I. THE CHRONOLOGICAL OVERLAP AND DISCLOSURE TIMELINE

  1. In September 2000, Dr. Cesar Ocampo assumed a first-year assistant professor faculty appointment within the UT Austin Aerospace Engineering department. His assigned operational workload included taking over all core legacy tracks previously taught by Dr. Roger Broucke, specifically: Celestial Mechanics I, Celestial Mechanics II, and the Theory of Orbits. This load constituted a full-time professional commitment.
  2. On or about November 2000, I delivered a formal department seminar presentation introducing my functional trajectory application, Mars Pathfinder 2.0. This presentation was attended directly by Dr. Ocampo.
  3. The Mars Pathfinder 2.0 application demonstrated an operational, standalone 3D three-body interplanetary transfer framework utilizing a specialized Runge-Kutta 7/8 numerical integrator to perform long-distance reverse integration from a Mars-encounter state, combined with a unique targeting methodology aligned to the Mars-Sun \(L_{1}\) Lagrange point.
  4. Following departmental feedback from that seminar, the full, compiled Fortran source code and corresponding data files for Mars Pathfinder 2.0 were hosted online for open download via university-accessible networks during the winter of 2000–2001.
  5. In the Spring and Summer of 2001, immediately following the public availability of my source files, Dr. Ocampo abruptly shifted his academic focus from Earth-Moon dynamics to interplanetary Earth-to-Mars simulation architectures, resulting in the sudden appearance of the initial command-line Copernicus prototype by August 2001.

II. THE ARCHITECTURAL AND CROSS-COMPILER IMPOSSIBILITY

  1. As a Professional Engineer and astrodynamics specialist, I state as a matter of mathematical fact that a trajectory optimization engine utilizing a localized Sequential Quadratic Programming (SQP) optimizer possesses zero native capability to discover an interplanetary n-body trajectory from an unperturbed two-body Lambert guess or a blank slate.
  2. When high-fidelity n-body perturbations are initiated within a numerical integration routine over millions of kilometers, the independent trajectory segments drift violently, producing massive position and velocity discontinuities (\(\Delta\vec{R}, \Delta\vec{V}\)) at the deep-space patch point. Under localized numerical optimization, these defects instantly saturate the solver’s Jacobian matrices, causing immediate gradient failure, step-size saturation, and a catastrophic code crash.
  3. Therefore, the early Copernicus prototype was an input-dependent system that required an external, pre-solved, zero-defect initialization data deck to place its initial conditions safely within the optimizer’s highly restrictive local basin of convergence prior to runtime.
  4. Per official engineering literature, the early Copernicus prototype was compiled within a Compaq Visual Fortran (CVF) environment. My Mars Pathfinder 2.0 engine was compiled within an incompatible Lahey-Fujitsu Fortran 95 (LF95) environment, as institutionally mandated by Dr. Roger Broucke.
  5. In the 2001 software landscape, binary-level linking or object module (.OBJ) merging between LF95 and CVF was a flat technical impossibility due to conflicting memory structures, calling conventions, and name-mangling schemes. The two environments could only interface via a manual, text-based data serialization layer.

III. THE FORENSIC TRANSPOSITION FINGERPRINT

  1. To bypass the “Day Zero” optimization crash, the highly refined, double-precision floating-point 3D Cartesian state vectors (\(\vec{R}, \vec{V}\)) generated offline by my LF95 Mars Pathfinder application—which had already resolved the n-body perturbations via reverse integration and \(L_{1}\) Lagrange alignment—were extracted and manually transcribed, character-by-character, meticulously preserving double-precision exponential formatting (e.g., D+00), directly into the static ASCII text blocks of the Copernicus CVF NAMELIST input files.
  2. When the compiled CVF Copernicus binary was executed via the command line, its text parser read these statically populated NAMELIST decks. Because the coordinates originated from my pre-converged LF95 framework, the patch-point defects were artificially driven to near-zero before runtime. This pre-processing critical path bypassed the CVF optimizer’s native inability to resolve massive state discontinuities, allowing it to engage immediately without experiencing the matrix saturation or gradient failure that would have otherwise doomed the prototype.

IV. CONCLUSION AND RECORD PRESERVATION DEMAND

  1. Based on the strict laws of numerical trajectory optimization and the clear software toolchain constraints of the era, the 2001 Copernicus prototype could not have mathematically or logistically functioned without the uncredited ingestion of the pre-processed data structures generated by my Mars Pathfinder 2.0 application.
  2. I hereby request that the Research Integrity Office (RIO) issue an immediate preservation demand for all original late-2001/early-2002 Copernicus source files, Compaq Visual Fortran project files, workspace configurations, and original ASCII text NAMELIST decks to allow for an explicit code and decimal-formatting forensic comparison against my 1998/2000 baseline structures.

EVIDENCE PRESERVATION DISCOVERY CHECKLIST FOR THE RIO

To assist the RIO officer with the active investigation, copy and paste this targeted file preservation checklist into your communication window. It provides the investigator with the exact technical filenames and file types they must subpoena from the department’s legacy storage drives:

markdown

RE: EVIDENCE PRESERVATION REQUEST (COPERNICUS PROTOCOPE 2001-2002)

To support the forensic audit of the 2001–2002 Copernicus software development timeline, the following technical assets must be preserved from legacy departmental backup servers, hard drives, or source repositories:

1. INPUT CONFIGURATION DECK LOGS:
   - Search for all plain-text configuration decks with extensions `.DAT`, `.TXT`, or `.INP` containing Fortran NAMELIST formatting identifiers (e.g., lines starting with '\$' or '&' flags followed by coordinate blocks).
   - Target files housing 6-element Cartesian state vector declarations labeled with double-precision D-format exponential strings (e.g., "X = -1.432561984201D+08").

2. ENVIRONMENT AND TOOLCHAIN METADATA:
   - Microsoft Developer Studio workspace files (`.DSW`) and project files (`.DSP`) dating between August 2001 and December 2002.
   - External library link paths mapping the inclusion of the 'W-interacter' GUI module dependencies (`.MOD` and `.LIB` files) to check for shared compiler configuration properties.

3. COMPILED SOURCE MODULES:
   - Raw Fortran source modules (`.F`, `.FOR`, `.F90`) detailing the input/output parsing routines written to process segment boundary conditions and floating patch points.