[Unstructured] today's emails

Jian Tao jtao at cct.lsu.edu
Wed Jul 13 18:57:42 CDT 2005

On Wednesday 13 July 2005 04:47 pm, David Rideout wrote:
> CactusUMT/
>   UMTIO -- Opinions?  How about MeshIO?  This will output both the mesh
> itself and data defined on the mesh.

Why not do data output alone with UMTIO and call MeshWriter if necessary ?

>   UMTDriver -- I slightly prefer UMDriver, in part because I have already
> started with this name.  Also because it makes more sense as an acronym.
>   MeshWriter -- ?  This can write a (potentially modified) mesh to file.
> (this time just the mesh -- no data defined on the mesh)

Consider a user calls some external lib to read in mesh, he probably wants to 
do the same to write the mesh back if he wants to have a look at the mesh. We
probably want to do the same for MeshWriter as we did for MeshReader.

> CactusFVM/FVMDriver -- This thorn should not exist.  It is equivalent
> to CactusUMT/UMDriver.  Are you dependent on UMDriver for the current
> development of FEM code?
No, but everything now depends on MeshReader now.

> * Regarding mesh reading:
> I would like UMDriver to call a function which returns the mesh, much like
> how it is currently coded.  I don't particularly care what happens behind
> that function call.  I would like the arguments to this function to contain
> pointers to arrays of ints and reals, which describe the mesh (and its
> coordinates) as specified in the spec.  Is this o.k.?  This way we can work
> separately for the most part -- all you need to do is provide this function
> somehow.  This way UMDriver development will be completely independent of
> any AIF-related code.
Yes, UMT_ReadMesh will stay there. Unless we all agree upon a better 
replacement, it will not be changed.  

Let's have a close look at the user interface and the macro.


        CCTK_INT   *cell_dim, \
        CCTK_INT   *imbedding_dim, \
        CCTK_INT   *vert_count, \
        CCTK_INT   *cell_count, \
        CCTK_INT   *verts_per_cell, \
        CCTK_REAL  **x1, \
        CCTK_REAL  **x2, \
        CCTK_REAL  **x3, \
        CCTK_INT   **c2v_pos, \
        CCTK_INT   **c2v_data

I have a suggestion about CCTK_INT   *vert_count, which should probably be 
declared as CCTK_INT   **vert_count to consider more general cases with 
hybrid cells. Comments ?

As for the AIFReader, it will be just a registered reader, which is on the 
same level as the default mesh reader by Karen. It will be registered and 
called by the same interface above.

> * Regarding UMDriver:
> I am writing a driver thorn which implements the spec, and am placing it in
> CactusUMT/UMDriver.  I would like its sole connection to other code to be
> the above function call, at least for now.  This way we can work
> independently.
I have been updating MeshReader recently, but as I said the interface will not 
change. We are doing pretty well in parallelizing our work.


More information about the Unstructured mailing list