[Unstructured] today's emails
jtao at cct.lsu.edu
Wed Jul 13 18:57:42 CDT 2005
On Wednesday 13 July 2005 04:47 pm, David Rideout wrote:
> 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.
#define UMT_MESHREADER_ARGLIST \
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, \
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
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