At least to plot the same function to the same window. Maybe it only needs the function.id()?
Martin On 29 April 2014 09:49, Garth N. Wells <[email protected]> wrote: > > On 28 Apr 2014, at 20:05, Anders Logg <[email protected]> wrote: > > > On Mon, Apr 28, 2014 at 06:46:14PM +0200, Garth N. Wells wrote: > >> We have a memory leak in the plotting code because the class > GenericVTKPlottable does not have a (virtual) destructor. The consequence > is that for objects like VTKPlottableGenericFunction, their destructor is > never called. This problem was picked up by a static analysis tool. > >> > >> In GenericVTKPlottable, the destructor was commented out with the > message: > >> > >> // This destructor should be uncommented, but it causes a problem > >> // in parallel with MPI calls being made after MPI is shutdown. Needs > >> // further investigation. > >> > >> This should have been sorted out. The problem is that the code skips > over the plot command, and shuts down MPI before the plot code has > destroyed all of its objects (some of which depend on MPI). We’re back in a > situation where the automatic initialisation and finalisation of MPI isn't > work. Solutions are > >> > >> 1. Require MPI to be initialised and finalised manually by the user > (the most robust option) > >> 2. Do not allow plotting with MPI > >> 3. Something else? > >> > >> Opinions or suggestions? > > > > Will it really help to finalize MPI explicitly in this case? > > > > Isn't the problem plots that are active until someone presses 'q' or > > the program exits? The call to the destructor of the plot objects will > > still happen late, and finalizing MPI *sooner* wont't make that > > problem go away. > > > > Maybe. I’d have to test. > > I should have added that the problem only appears from Python. > > > What seems to be needed in this case is something like this: > > > > plot_finalize(); // just as ugly as mpi_finalize() > > > > Why does the plot code need to store a Function object? If it didn’t store > a Function, this problem would vanish. > > Garth > > > > -- > > Anders > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
