9 research outputs found

    Translating MAPGEN to ASPEN for MER

    Get PDF
    This software translates MAPGEN (Europa and APGEN) domains to ASPEN, and the resulting domain can be used to perform planning for the Mars Exploration Rover (MER). In other words, this is a conversion of two distinct planning languages (both declarative and procedural) to a third (declarative) planning language in order to solve the problem of faithful translation from mixed-domain representations into the ASPEN Modeling Language. The MAPGEN planning system is an example of a hybrid procedural/declarative system where the advantages of each are leveraged to produce an effective planner/scheduler for MER tactical planning. The adaptation of the planning system (ASPEN) was investigated, and, with some translation, much of the procedural knowledge encoding is amenable to declarative knowledge encoding. The approach was to compose translators from the core languages used for adapting MAGPEN, which consists of Europa and APGEN. Europa is a constraint- based planner/scheduler where domains are encoded using a declarative model. APGEN is also constraint-based, in that it tracks constraints on resources and states and other variables. Domains are encoded in both constraints and code snippets that execute according to a forward sweep through the plan. Europa and APGEN communicate to each other using proxy activities in APGEN that represent constraints and/or tokens in Europa. The composition of a translator from Europa to ASPEN was fairly straightforward, as ASPEN is also a declarative planning system, and the specific uses of Europa for the MER domain matched ASPEN s native encoding fairly closely. On the other hand, translating from APGEN to ASPEN was considerably more involved. On the surface, the types of activities and resources one encodes in APGEN appear to match oneto- one to the activities, state variables, and resources in ASPEN. But, when looking into the definitions of how resources are profiled and activities are expanded, one sees code snippets that access various information available during planning for the moment in time being planned to decide at the time what the appropriate profile or expansion is. APGEN is actually a forward (in time) sweeping discrete event simulator, where the model is composed of code snippets that are artfully interleaved by the engine to produce a plan/schedule. To solve this problem, representative code is simulated as a declarative series of task expansions. Predominantly, three types of procedural models were translated: loops, if statements, and code blocks. Loops and if statements were handled using controlled task expansion, and code blocks were handled using constraint networks that maintained the generation of results based on what the order of execution would be for a procedural representation. One advantage with respect to performance for MAPGEN is the use of APGEN s GUI. This GUI is written in C++ and Motif, and performs very well for large plans

    Finite-Temperature Transport in Finite-Size Hubbard Rings in the Strong-Coupling Limit

    Full text link
    We study the current, the curvature of levels, and the finite temperature charge stiffness, D(T,L), in the strongly correlated limit, U>>t, for Hubbard rings of L sites, with U the on-site Coulomb repulsion and t the hopping integral. Our study is done for finite-size systems and any band filling. Up to order t we derive our results following two independent approaches, namely, using the solution provided by the Bethe ansatz and the solution provided by an algebraic method, where the electronic operators are represented in a slave-fermion picture. We find that, in the U=\infty case, the finite-temperature charge stiffness is finite for electronic densities, n, smaller than one. These results are essencially those of spinless fermions in a lattice of size L, apart from small corrections coming from a statistical flux, due to the spin degrees of freedom. Up to order t, the Mott-Hubbard gap is \Delta_{MH}=U-4t, and we find that D(T) is finite for n<1, but is zero at half-filling. This result comes from the effective flux felt by the holon excitations, which, due to the presence of doubly occupied sites, is renormalized to \Phi^{eff}=\phi(N_h-N_d)/(N_d+N_h), and which is zero at half-filling, with N_d and N_h being the number of doubly occupied and empty lattice sites, respectively. Further, for half-filling, the current transported by any eigenstate of the system is zero and, therefore, D(T) is also zero.Comment: 15 pages and 6 figures; accepted for PR

    APGEN Scheduling: 15 Years of Experience in Planning Automation

    No full text
    In this paper, we discuss the scheduling capability of APGEN (Activity Plan Generator), a multi-mission planning application that is part of the NASA AMMOS (Advanced Multi- Mission Operations System), and how APGEN scheduling evolved over its applications to specific Space Missions. Our analysis identifies two major reasons for the successful application of APGEN scheduling to real problems: an expressive DSL (Domain-Specific Language) for formulating scheduling algorithms, and a well-defined process for enlisting the help of auxiliary modeling tools in providing high-fidelity, system-level simulations of the combined spacecraft and ground support system

    The Evolvable Advanced Multi-Mission Operations System (AMMOS): Making Systems Interoperable

    No full text
    The Advanced Multi-Mission Operations System (AMMOS) provides a common Mission Operation System (MOS) infrastructure to NASA deep space missions. The evolution of AMMOS has been driven by two factors: increasingly challenging requirements from space missions, and the emergence of new IT technology. The work described in this paper focuses on three key tasks related to IT technology requirements: first, to eliminate duplicate functionality; second, to promote the use of loosely coupled application programming interfaces, text based file interfaces, web-based frameworks and integrated Graphical User Interfaces (GUI) to connect users, data, and core functionality; and third, to build, develop, and deploy AMMOS services that are reusable, agile, adaptive to project MOS configurations, and responsive to industrially endorsed information technology standards
    corecore