Referee 1 *******************************************

E: Referee Comments (For Author and Editor)  ------------------------------

The paper presents general overview of authors efforts to develop mechanisms
for coupling distributed applications. They have laid good foundation for
distributed data access and interchange based on standard format like HDF and XML
and extensions.

This paper does not raise nor addresses issues such as how to locate distributed application
components while coupling. It is yet to take advantage of any GRID specific technologies,
but has potential to use them. They do not talk about the use of some
smart tools for selecting services based on QoS mechanisms. The whole
experiment appears like "Static"!  Hence, it may appear like ODD-paper in the 
special issue of GCE Problem Solving Environment. 

F: Presentation Changes

Overall paper tells good story of data management aspects while coupling distributed
applications. It will be great if you can show how such secure and dynamic coupling
can be carried out in a Grid environment where things significantly change during
runtime including failures. You may create a General Architecture diagram to
create a linkage between your work with other emerging Grid technologies.

Also, in the paper there are few acronyms exist for there is no description exist.

Can you check if Ref[1] is correct ?

Referee 2 *******************************************

E: Referee Comments (For Author and Editor)  
The authors develop a new eXtensible Data Model and Format (called XDMF)for addressing
interdisciplinary applications. In addition to providing a common data model and format that
allows for the development of powerful and reusable tools, XDMF allows efficient active
updates to facilitate runtime visualization and HPC code coupling. The applicability of the
approach is demonstrated for an interdisciplinary blast-structure interaction application.
For this demonstration purpose, the coupled application used widely accepted individual
discipline software, namely, CTH for blast simulations and ParaDyn for structural
simulations.

The authors can add to the paper by briefly describing some alternate approaches that people
have used in the past.


Referee 3 *******************************************

E: Referee Comments to Author and Editor

This paper needs to be substantially revised before it is suitable for journal
publication.  Overall, the paper lacks  motivation for why this work was
performed and how this work provides something that is new or is an improvement
over other Non-Uniform Memory Access (NUMA) approaches.  There isn't enough
detail in the paper to assess the benefits of this approach and if it can be
beneficial to a wider community (is it limited to 3D field data?).  Most of the
paper provides background on the technologies they used, but few details on the
work that was actually performed, the limitations of this approach, what was
learned, and establishing how this effort relates to the Grid community.

The direction of the Grid is focused primarily on protocols, whereas the
approach outlined here uses a fairly heavyweight API.  Are Grid services going
to use this API, at what layer of the grid is this work relevant? 

There are interesting aspects to the work but it appears to have originated with
a specific focus, and this paper attempts to describe it in a general sense
without adequate discussion or comparison to other research.  The potential for
a good technical paper exists with further development of the content, tying it
more closely to the Grid, and reorganizing the presentation using the
suggestions below.

F: Presentation Changes

"The technology" starting the 2nd paragraph of the abstract needs to be defined.

Several sentences in the abstract are strings of adjectives that together do not
make coherent sentences.

Acronyms are used without being defined.

References are provided after something has already been defined and discussed.

The figures are not discussed or referenced in the paper.  Currently, they don't
contribute to the paper.

Terms such as heavy data are used early and defined much later.  Use of
"enormous" to describe data conveys very little information.

Background information is dispersed throughout paper.

SWIG is not referenced.