Architecture Overview

The application naturally presents a client/server structure. The Solver acts as a client for a service of mesh refinement and domain decomposition provided by the Domain Manager. Here, the most important point the computation of a new mesh and the progress in computing a solution based on the old mesh can overlap, at least for a certain time, which is the tolerance delay. Thus, delegating the computation of the new mesh makes sense. As seen before, it is also natural that the two programs run of different machines, because they require different architectures.

The Solver and the Domain Manager are coordinated through Java-based interfaces. These interfaces have two functions: the native/Java wrapper and the mechanism for accessing remote objects. Fig 1 describes what would be an ideal architecture. On the left hand side Java objects wrap the HPF data and/or code for the Solver; on the right hand side Java objects wrap the Fortran 90 data and/or code for the Domain Manager; on both sides, at least some data can be accessed by both Java and the native codes and each can hold its own data. Finally, method invocation from the Solver to the Domain Manager is asynchronous: invoking the mesh refinement tool should not block the caller.

  

Figure 1: Architecture Overview

Actually, only some of the ideal feature are directly available. A very important one is memory management. Simply put, complex dynamic Fortran variables can be allocated and operated on (as Objects) in a Java environment. Hence wrapping true Fortran 90 code is possible, except the numerous restrictions of C/F90 interoperability, even for the very simple data structure of an array section.

No JNI does exist for HPF. Various proposals are ongoing to define how a data-parallel object should be wrapped, either as a mere Object or with more information about its distribution properties. This would clearly be mandatory to have an authentic HPF JNI. However, we observed that the most important need in the PPADD project was a Java-based mechanism to escape from data-parallelism. This takes place when the Solver requests a new mesh. The semantics of this call is strongly not symmetric: currently one, and later some domains, actively call for remeshing, while other domains may be created as a result of the remeshing process. The semantics of HPF_LOCAL answers this need. The semantics of this call also is strongly asynchronous: first, the Solver computation should overlap with the Domain Manager computation, but also with the communication of the new mesh data. Thus, the request for a new mesh must be a true asynchronous RPC, with return parameters set by the called service. This is definitely not the semantics of any data-parallel construct, which imply one thread of execution, nor the semantics of the Java RMI, which is synchronous. However, we show below that the functionality can be implemented through the Java multithreading facility.