Oh wow, that is low memory. Is that per core or per node? If it's the latter you can simply run fewer cores if necessary to get your calculation done using ReplicatedMesh.
I'm currently running 5 million elements using ReplicatedMesh for my problem and have no plans to switch to DistributedMesh any time soon since I do have the memory to spare. Yes it does take more memory per core but it's generally much faster, especially if you are running with adaptivity. I guess since I am working at this level I might experiment with the two mesh types and report actual memory usage for people to look at. Hopefully Roy's enhancements to the system will help you out. On Thu, Aug 11, 2016 at 2:53 PM Manav Bhatia <[email protected]> wrote: > About a million elements. > > I have tried serial mesh in the past, but that seems to be running into > memory issues on our local HPC machines. We have about 2GB per node, not > sure if that is enough. > > -Manav > > > On Aug 11, 2016, at 3:48 PM, Cody Permann <[email protected]> wrote: > > No pointers (no pun intended) but how big is your mesh? Just curious. > > On Thu, Aug 11, 2016 at 2:47 PM Manav Bhatia <[email protected]> > wrote: > >> So, I did manage to get the combination of >> DistributedMesh::add_extra_ghost_elem() and DofMap::augment_send_list() to >> work, but it ended up not giving me the result I was hoping. >> >> Basically, my intent is to use MeshFunction to return solution values on >> a specified boundary, and I want this to work on all processors for a >> distributed mesh. >> >> I was hoping that if I make the elements at the specified boundary >> available (through ghost elements), along with their their dofs (through >> send list), the point locator would use this info to find the element >> containing a boundary point, and the mesh function would have access to the >> dofs for interpolation. >> >> However, the point locator does not seem to work with the ghost elements. >> >> Is there another way for me to get this desired result? >> >> I would appreciate any pointers. >> >> Thanks, >> Manav >> >> >> >> > On Aug 11, 2016, at 10:16 AM, Roy Stogner <[email protected]> >> wrote: >> > >> > >> > On Thu, 11 Aug 2016, Manav Bhatia wrote: >> > >> >> So if I understand correctly, the current implementation of >> >> DistributedMesh::add_extra_ghost_elem() only provides the G() >> >> version of your new API >> > >> > Not even that. It provides the G() version of the old API - you can >> > flag current elements that should remain ghosted, when you're ready to >> > delete remote elements you're responsible for having flagged the extra >> > ghosted elements first, and IIRC you can't redistribute the mesh after >> > it's been initally distributed. >> > >> >> without an “evaluable” entity? If my interest is in the E() entity, >> >> would it be best to wait for your API, or is there a way to get it >> >> to work in current libMesh? >> > >> > You can combine the ghost element flagging with calls to >> > DofMap::augment_send_list() to make sure all dofs on the ghost >> > elements remain distributed. The new API ought to make that much >> > easier though. >> > >> >> Perhaps follow the implementation in MOOSE? >> > >> > That's a good idea. We've also got 2 augment_send_list() uses in the >> > libMesh examples, IIRC. >> > --- >> > Roy >> >> >> >> ------------------------------------------------------------------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. http://sdm.link/zohodev2dev >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> > > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
