A. Dozier, O. David, Y. Zhang, and M. Arabi

1. MODPI: A parallel MOdel Data Passing Interface for integrating legacy environmental system models A. Dozier, O. David, Y. Zhang, and M. Arabi

2. Motivations • Different languages, frameworks, operating systems • Two-way feedbacks between legacy models • Refactoring legacy code is difficult • To program • Many lines of code • Reproducing model outputs correctly • To maintain • Updating model versions • To adopt • Little to no community adoption of code • When refactored by thirdparty • When significantly changed

3. Goals & Objectives • Goal • “to facilitate and abstract the legacy model integration process to include complex, multi-directional interactions between models… of different architectures and maintain model individuality” • Objectives • Design abstractinterface for simplicity • Apply the interface

4. Comparison between two methods of integration Using MODPI Calling one as subroutine Model 2 Read inputs Execute Write outputs Model 2 Read inputs Execute Write outputs Model 1 Read inputs Execute Write outputs Model 1 Read inputs Execute Write outputs Execute Write outputs MPI networkcommunication

5. MOdel Data Passing Interface (MODPI) mpirun or mpiexec Model 1 Wrapper (User-specified) Model 2 Wrapper MODPI Implementation • MODPI Implementation • modpi_init() • Subscribes to events by name • Initializes MPI • modpi_finalize() Model 1 Start Daily Loop …Perform work… End Daily Loop End Model 2 Start Daily Loop …Perform work… End Daily Loop End Events On Start On Top Loop Receivers On Top Loop On Bottom Loop Senders On End

6. Sample implementation • DayCent-HYDRUS • DayCent estimates biogeochemical fluxes • HYDRUS provides physically-based representation of soil water content • Two different implementations • “SUB”: call HYDRUS as a subroutine within DayCent • “MODPI”: DayCent-HYDRUS linked using MODPI

7. Sample implementation • Code changes

8. Sample implementation • Runtime and overhead

9. Discussion • Advantages • Framework and language independent • Multi-lingual and (hopefully) multi-platform • Non-intrusive event-based system • Built-in parallelization and communication via MPI • Limitations • May produce overhead in virtualized environments • Requires MPI • Framework must be compatible with MPI • May require some knowledge of MPI programming

10. Future Work • Use “reflection” to lookup variable by string • Use a range of processes to broadcast values • Automate data transformations • Run tests across Windows and Linux • Generate Fortanor C code for initial model integration wrapper

11. Questions?

13. References • Images • Language • Stop and listen

14. Option 1 – Iterative Model 1 • Advantages • Simple concept • Simple programming • Disadvantages • Computationally inefficient • Convergence of iterations? Write new inputs Model 2 No? Converged? Yes! Read outputs Exit

15. Option 2 – Call model as sub-model • Advantages • Computationally efficient • Disadvantages • Medium to hard concept • Medium to hard programming • Maintain separate code base Model 2 Read inputs Execute Write outputs Model 1 Read inputs Execute Write outputs Execute Write outputs

16. Implementing MODPI • Add events • Minimal model refactoring • Build sender and receiver subroutines • Build subroutine to point to events within the model • Build a wrapper program • Call modpi_init() • Run model • Call modpi_finalize() • Define input text files • Run mpirun or mpiexec