AMR Front Tracking
In SciDAC-1, ITAPS researchers merged the front tracking code, FronTierLite, with the AMR code Overture to create a combined, AMR-front tracking capability needed by fusion, groundwater, combustion, and astrophysics applications. This code was created in 2D, although both components function in 2D and 3D. In SciDAC-2 we will work on two tasks: to extend the merged operation to 3D and to bring all new and proposed improvements (conservative tracking, interface constrained hybrid meshes) of the code into an interoperable status, suitable for use on high performance parallel simulations.
FronTier (SUNY SB and BNL) has been used to apply the front-tracking method to different scientific problems such as gas dynamics, petroleum reservoir study, MHD and solid interface problems. Overture (LLNL) is a mesh management framework that has adopted the AMR method proposed by Berger and Colella to insert highly refined patches in regions where wave interaction demand increased resolution in the interior region. Our goal within the context of the TSTT center is to combine the strengths of the FronTier and Overture codes to develop a new, efficient front-tracking algorithm combined with the AMR technique, the so-called AMR Front Tracking Method.
This work was completed primarily at SUNY SB with help from the Overture team, and through the last year, this project moved through three phases. The first phase involved a complete understanding of the Overture algorithms and its implementation. This included understanding its objectives, the implementation of the relevant algorithms, as well as its data structures, functions, and the computational environment.
The second phase involved resolving the conflicting definitions and macros in the two codes. Because the two codes were developed independently, a number of conflicting definitions, function names and macros with identical names were used for similar (but not exactly the same) or different purposes. These conflicts were resolved by restricting most of the necessary changes to the FronTier code, thereby ensuring easy access to future Overture upgrades.
In the third phase, our objective was to construct a common interface for the communication of data in the two codes. The most difficult part of the work has been in the generalization of patch and subdomain communications. Although FronTier is parallelized, the data communication between patches inside the same parallel processor is outside of the development framework. As a result, we needed to find a practical method to synchronize the computation of different patches inside the same parallel processor. We finally decided to modify the entire functional structure of the interface propagation in the FronTier code to have it fully modularized at the synchronization points inside a single driver function. Figure 8 shows the adaptive patches with the tracked front.