[MOAB-dev] problems reading meshes in MOAB in the 'read_part' mode

Dmitry Karpeev karpeev at mcs.anl.gov
Thu Apr 1 16:03:28 CDT 2010


Does mbconvert report read times?
Also, can you point me to the mesh file so I can try it?
Thanks!

Dmitry.

On Thu, Apr 1, 2010 at 3:00 PM, Jason Kraftcheck <kraftche at cae.wisc.edu> wrote:
> Dmitry Karpeev wrote:
>> I guess it was somewhat strong, but what I really meant is this:
>> "For whatever reason I can't seem to make 'read_part' work with any mesh
>> or any machine with any number of procs I have tried recently, so
>> for the purpose of my task at hand -- benchmarking of parallel reads --
>> I will avoid using 'read_part', at least for now."
>>
>> The reason I brought up the various reported errors was to marshal evidence
>> that the problem is probably with 'read_part' itself -- not the meshes
>> I feed it.
>>
>
> Well, this particular problem was definitely with the mesh that fed it.
>
> As for read_part in general, I it appears to work for me on both my local
> machine and cosmea.  Reading a file containing 64 blocks of 1000 hexes each
> worked fine for 4 to 32 processes (64-proc is still waiting in queue on
> Cosmea.)  My input was generated in cubit and converted to h5m using
> mbconvert before running the parallel test.  The cubit model was a 4x4x4
> grid of 10x10x10 bricks, merged, meshed with size 1, with one exodus block
> per brick.  I then tested the parallel read with:
>  ~/submit -n 32 ./mbconvert -O PARALLEL=READ_PART \
>      -O PARTITION=MATERIAL_SET -f VTK blocks-64.h5m /dev/null
>
> - jason
>


More information about the moab-dev mailing list