[MOAB-dev] loading a VTK mesh in parallel (.pvtu)

[Iulian Grindeanu]

Hi Lorenzo, 

----- Original Message -----

| Dear all,
| I have recently written a MOAB reader/writer for .vtu and .pvtu
| files, that is VTK unstructured grids and parallel VTK unstructured
| grids in xml format.
| The only issue for the inclusion in MOAB (let me know if that would
| be interesting for you) is that I’m using an open-source xml reader
| instead of the FileTokenizer included into MOAB.

what kind of license on the xml reader? 

| The .pvtu parallel reader works fine, each process loads an
| independent .vtu file containing his portion of the grid and creates
| a PARALLEL_PARTITION entity set for his ParallelComm.
| Actually the number of .vtu files must be equal to the number of
| processes, so the reader is less flexible than with the native .h5m
| file format.
| Eventually the reader could be modified to handle a number of
| partitions different from the number of processes.

| What I really would like to do next is to include in each .vtu
| portion of the grid the informations required to run in parallel
| (e.g. ghost cells, shared entities) so to avoid calling
| resolver_shared_entities(...) and exchange_ghost_cells(….) in
| parallel.

You cannot call resolve_shared_entities unless you have a tag like a global id tag, or a file id tag that uniquely identifies every node. 
You need to use ParallelMerge; 
in there, assuming that the meshes are matching between processes, within some tolerance, you just need to run merge. 

Basically, a skin is computed first on each processor, and the skin is "resolved" in parallel using a 2 way communication, similar to resolve shared entities. 

( each vertex on the skin is first sent to a "working processor" , established based on a pre-determined pattern; the working processor is guaranteed to receive all instances of the vertex on all processes; it decides then what vertices need to be "merged" because they are identical within some geometric tolerance; that information is then communicated back to all processes that sent that vertex) 

| Nevertheless, I would like to be able to call exchange_tags(….) and
| reduce_tags(….) in parallel, once the grid has been loaded.
After parallel merge, you should be able to use exchange tags and reduce tags as before. (you should be able to ghost too, on the fly) 

Currently, there are some issues with ghosting, but version 4.6.2 runs better (there are issues there too) 

| What would I need to do so? I guess that to exchange tags across
| processes each shared entity must know the processors it need to
| communicate with.
so for this to work, your independent meshes need to be almost perfect, with respect to geometry/distance. They have to "match", but other than that, you should be able to use ParallelMerge 

| How can I achieve this behaviour? Which informations I need to add to
| the mesh files?

You do not need to add anything to the file 

| Any help is appreciated, thanks!
| Lorenzo

Thanks, 
Iulian 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20131029/341f9297/attachment.html>