Hi Roy, Thanks for this info. I did indeed change the "EIM" code, which affects reduced_basis_ex4 and reduced_basis_ex6. The change is related to the email thread with subject line: "Writing a handful of elements to disk" on libmesh-users. I didn't have any problems with these examples myself, but I haven't tried ParallelMesh, so it's not too surprising that there's a problem in that case.
Basically the EIM code constructs an interpolation based on sampling at various points in the mesh (EIM stands for "Empirical Interpolation Method"), e.g. see this paper if you're interested in more details: M Barrault, Y Maday, NC Nguyen, and AT Patera, An 'Empirical Interpolation' Method: Application to Efficient Reduced-Basis Discretization of Partial Differential Equations. CR Acad Sci Paris Series I 339:667–672, 2004. In order to generalize the EIM code for some apps I was working on, I needed access to the elements at which these samples occur. Hence I wanted to write out just those elements to disk, and read those elements in during the Online stage. As discussed in the thread I referred to, it seemed that the easiest way to do this way to build a mesh that contains these elements, and then write it using standard mesh I/O. But the samples can be anywhere in the mesh, so this typically results in a disconnected mesh, as you observed. So this is certainly a highly non-standard use of a mesh, but it has been working well for me and my colleagues so far. Though as I said, I haven't tested with ParallelMesh, so it'd be great to fix the issue that you have identified with elements that aren't semilocal to every processor. But one question: _interpolation_points_mesh is a SerialMesh (as defined in rb_eim_evaluation.h), so I thought that would mean that changing the configuration to --enable-parallel-mesh wouldn't affect this code? David On 01/04/2014 05:47 AM, Roy Stogner wrote: > > I should have been keeping a closer eye on the buildbot reports over > the holidays, I guess. > > reduced_basis_ex4 is currently dying in online mode when it tries to > get Metis to partition eim_data/interpolation_points_mesh.xda, which > is a mesh of 21 QUAD4 elements connecting 84 nodes. > > Yes, read that again: 4 unique nodes for each QUAD4, because none of > these elements are connected to any other of these elements. The > visualization looks kind of like a scatterplot of squares, like some > sort of poor man's gnuplot. > > I guess the thing to do is fix our METIS interface to handle > disconnected meshes (or possibly just remove an overzealous > assertion), but first I have to wonder: is this output deliberate? If > we've exposed a bug in the RB stuff we should fix it; if we haven't > then I'd like to know what the heck I'm looking at! > --- > Roy ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
