2 research outputs found
Resource Requirements for Fault-Tolerant Quantum Simulation: The Transverse Ising Model Ground State
We estimate the resource requirements, the total number of physical qubits
and computational time, required to compute the ground state energy of a 1-D
quantum Transverse Ising Model (TIM) of N spin-1/2 particles, as a function of
the system size and the numerical precision. This estimate is based on
analyzing the impact of fault-tolerant quantum error correction in the context
of the Quantum Logic Array (QLA) architecture. Our results show that due to the
exponential scaling of the computational time with the desired precision of the
energy, significant amount of error correciton is required to implement the TIM
problem. Comparison of our results to the resource requirements for a
fault-tolerant implementation of Shor's quantum factoring algorithm reveals
that the required logical qubit reliability is similar for both the TIM problem
and the factoring problem.Comment: 19 pages, 8 figure
CubeSat Model-Based Systems Engineering (MBSE) Reference Model –Model Distribution and Application –Interim Status #2
Model Based Systems Engineering (MBSE) is a key practice to advance systems engineering that can benefit CubeSat missions. MBSE creates a system model that helps integrate other discipline specific engineering models and simulations.
The International Council on Systems Engineering (INCOSE) established the MBSE Initiative to promote, advance, and institutionalize the practice of MBSE. The INCOSE Space Systems Working Group Challenge team has been investigating the applicability of MBSE for designing CubeSats since 2011.
Our application of MBSE uses System Modeling Language (SysML), a graphical modeling language, to model all aspects of a system either directly or through an interface with another model. SysML diagrams are used to describe requirements, structures, behaviors, and parametrics from the system down to the component level. Requirements and design are contained in the model rather than in a series of independent engineering artifacts.
In the past phases of the project, the team has created the initial iteration of the reference model, applied it to the Radio Aurora Explorer (RAX) mission, executed simulations of system behaviors, interfaced with commercial simulation tools, and demonstrated how behaviors can be executed to perform trade studies.
The goal of the current phase is to provide a sufficiently complete CubeSat Reference Model that can be adapted to any CubeSat project. The CubeSat Reference Model will have all the logical model elements for population by a mission specific CubeSat team as their foundation for a physical model.
The CubeSat Reference Model starts with an identification of potential stakeholders. A stakeholder is any entity that has an interest in the system including sponsor, end user, procurer, supplier, and regulatory agencies. The each stakeholder\u27s needs, objectives, constraints, and measures of effectiveness are incorporated in the model. Constraints are those items fixed and not subject to trades such as mission budget and schedule.
The CubeSat operational domain includes the CubeSat mission enterprise and the external environment. The external environment consists of the natural and induced environments. The CubeSat mission enterprise consists of the space system, ground system, launch services, launch vehicle interface system, and communication services.
The CubeSat model accommodates an entire project lifecycle from conception through retirement. The model accommodates all phases of operations from launch, early operations, normal operations and sustainment. Since we are just providing a reference model, another CubeSat team can apply their own mission lifecycle and engineering processes to customize and populate the model.
One of the stakeholders is the Cal Poly CubeSat project. The Cal Poly CubeSat Specification has been populated into its own SysML model to enable the content of the specification to be related to the CubeSat Reference Model.
The reference model is being developed by a team effort and there is an obligation to protect the investment of time and knowledge of each team member. There will be a licensing environment that is conducive to a user organization supporting the development of and use of the model