[FLASH-USERS] larger FLASH hdf5 files in visit

[McFarland, Jacob A.]

All,

I just wanted to ping the community one more time to see if anyone has any suggestions on this issue. I have not received any feedback yet but I have received emails from some other users with this issue.

Thanks for any help you can provide.

- Jacob
________________________________
From: flash-users-bounces at flash.uchicago.edu [flash-users-bounces at flash.uchicago.edu] on behalf of McFarland, Jacob A.
Sent: Tuesday, July 05, 2016 9:00 AM
To: flash-users at flash.uchicago.edu
Subject: [FLASH-USERS] larger FLASH hdf5 files in visit

Hello all,

I emailed the visit users group with this issue but I have not received any info back yet. As this is a problem many of you may have encountered with FLASH data I thought the FLASH users group might have some advice as well.

I am having a problem with Visit consuming a lot of memory when opening FLASH hdf5 files. I have simulations with about 50E6 nodes on the fluid mesh and about 20k particles. The hdf5 files are written with parallel hdf5 (I ran the setup with +hdf5TypeIO). The chk files are 5-16gb or so in size, getting larger in time as there are more nodes at later times.

When I open the files with Visit each processor seems to consume enough memory to open the whole chk file no matter how many processor I throw at it. This means I end up memory limited and have to rune with very few processor on each computer node.

I expected visit would be able to break up the hdf5 files so that each processor would not need the whole file in memory. This is the behavior I have seen when using other codes with data in the silo format.

Is this the normal behavior for visit with large FLASH data files?

If not, any suggestions on what I am doing wrong?

If so, any suggestions on how to mitigate this memory problem?

Thanks,
Jacob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20160708/75bc1a63/attachment.htm>