Support #294

[MOAB/FMDB] loading the same distributed mesh

Added by Seegyoung Seol about 6 years ago. Updated over 5 years ago.

Status:ResolvedStart date:08/09/2011
Priority:NormalDue date:
Assignee:Seegyoung Seol% Done:

0%

Category:-Spent time:-
Target version:1.4

Description

- This is needed to run MOAB_iMeshP test with both MOAB and FMDB.
- The mesh file will be of different format


Related issues

Duplicates ITAPS - Specification #218: Need common method/approach to load mesh in parallel Resolved 03/31/2011

History

#1 Updated by Seegyoung Seol about 6 years ago

  • Status changed from New to In Progress
  • Assignee set to Seegyoung Seol
  • Start date changed from 06/19/2011 to 08/09/2011

The purpose of this activity is two-fold
- providing FMDB-readable 4-part distributed mesh with topology of what MOAB_iMeshP_test constructs
- and availing MOAB_iMeshP_test to run either with MOAB or FMDB

This implies that MOAB_iMeshP_test needs to be modified to load distributed 4-part meshes instead of constructing the 4-part mesh from the scratch, if needed. (Tim, correct me if I am wrong)

#2 Updated by Seegyoung Seol almost 6 years ago

FMDB-readable 6-part, 24 quad distributed "sms" mesh files which mimic the mesh constributed by MOAB_iMeshP_unitTest.cc are downloadable from iMeshP/data.

However, MOAB iMeshP test needs at least two modifications to run with FMDB:
- removing "create_mesh" call
- getting mesh file name from input argument

In addition, further investigation in MOAB iMeshP test is needed to run it with FMDB to eliminate any non-general testing which is specific to this 6-part, 24 quad mesh or something beyond iMeshP specifications/agreement.

My speculation is, with MOAB-readable, 6-part, 24quad mesh files available, iMeshP_unitTest.cc can run either with MOAB or FMDB with slight modification in mesh loading options.

#3 Updated by Mark Miller over 5 years ago

  • Status changed from In Progress to Resolved

I adjusted MOAB_iMeshP_unitTest to accept input from file instead
always creating mesh from an new instance and then saving the file.

I manually ran the test on 6 processors and saved the native,
MOAB file to data/MOAB_iMeshP_test_file.h5m and then tested
running the test with this file and it it indeed works like
so...

mpirun -np 6 MOAB_iMeshP_unitTest -i ../../data/MOAB_iMeshP_test_file.h5m

...and that runs to completion successfully with no errors.

I also compiled MOAB_iMeshP_unitTest against FMDB 1.3.6 and
tried running with FMDB's input file like so...

mpirun -np 6 iMeshP_unitTest ../../data/24quad_p.sms

...which should cause it to read all 24quad_pi.sms files.
However, that test appears to hang.

Finally, I compiled and linked iMeshP_unitTest against MOAB and
tried to run it like so...

mpirun -np 6 iMeshP_unitTest ../../data/MOAB_iMeshP_test_file.h5m

and that immedately aborted...

rank 5 in job 44 itaps_53503 caused collective abort of all ranks
exit status of rank 5: return code 1
rank 4 in job 44 itaps_53503 caused collective abort of all ranks
exit status of rank 4: return code 1
rank 3 in job 44 itaps_53503 caused collective abort of all ranks
exit status of rank 3: return code 1
rank 1 in job 44 itaps_53503 caused collective abort of all ranks
exit status of rank 1: return code 1
rank 0 in job 44 itaps_53503 caused collective abort of all ranks
exit status of rank 0: return code 1

So, as far as cross-testing of MOAB and FMDB's unit tests against
the implementations, I have taken things as far as I can.

I am going to file a couple of tickets for these new test failures.

Also available in: Atom PDF