Hi all,
I've been digging into this, and I believe I found a bug in the source
code of meep (version 1.1.1). I wrote basically the C++ version of the
example scheme file and found similar behavior. With the aid of
valgrind, it seems that memory is lost due to
meep::structure::add_polarizability(). Meep apparently allocates
chains of polarizability instances for calculating the polarization of
dispersive materials, in meep::structure_chunk::add_polarizability():
00203 void structure_chunk::add_polarizability(material_function &sigma,
00204 field_type ft, double omega,
00205 double gamma) {
00206 sigma.set_polarizability(ft, omega, gamma);
00207 const double freq_conversion = 2*pi*dt;
00208 double sigma_scale = freq_conversion*freq_conversion*omega*omega;
00209 polarizability *npb = new polarizability(this, sigma,
00210 ft, freq_conversion*omega,
00211 freq_conversion*gamma,
00212 sigma_scale, is_mine());
00213 npb->next = pb;
00214 pb = npb;
00215 }
However, the destructor of structure_chunk does this:
00478 structure_chunk::~structure_chunk() {
00479 FOR_COMPONENTS(c) {
00480 FOR_DIRECTIONS(d) {
00481 delete[] chi1inv[c][d];
00482 delete[] conductivity[c][d];
00483 delete[] condinv[c][d];
00484 }
00485 delete[] chi2[c];
00486 delete[] chi3[c];
00487 }
00488 FOR_DIRECTIONS(d) {
00489 delete[] sig[d];
00490 delete[] siginv[d];
00491 }
00492 if (pb) delete pb;
00493 }
That is, a simple delete for the first pb. I changed this to
structure_chunk::~structure_chunk() {
FOR_COMPONENTS(c) {
FOR_DIRECTIONS(d) {
delete[] chi1inv[c][d];
delete[] conductivity[c][d];
delete[] condinv[c][d];
}
delete[] chi2[c];
delete[] chi3[c];
}
FOR_DIRECTIONS(d) {
delete[] sig[d];
delete[] siginv[d];
}
while (pb)
{
polarizability* nextpb = pb->next;
delete pb;
pb = nextpb;
}
}
This seems to eradicate the memory loss issues in my C++ test file,
and largely solves it for the original scheme file.
Suspicious to me, but what I haven't changed, is the implementation of
void structure_chunk::remove_polarizabilities() {
delete pb;
pb = NULL;
}
Maybe the same kind of code should be used here too.
Regards
Robert
On Fri, Jul 29, 2011 at 7:39 PM, Eguiluz Madariaga Lur
<[email protected]> wrote:
>
> Dear all,
>
> I am having a problem with meep. I am trying to optimize a geometry with it
> by searching for the maximum of a function, but after a while I run our of
> memory and the process cannot be completed. At each iteration the required
> memory increases, so I guess it is keeping something in memory.
>
> I have written a simplified scheme file that shows the basic issue: meep is
> run in a function and the function is called 6 times, simulating an
> optimization run. The actual geometry that is defined in this function does
> not change, so basically it is the same calculation over and over. I have
> traced the memory usage during the simulated optimization and plotted the
> results. The resulting graph is attached as well. The graph clearly shows a
> step-wise increment on each iteration.
>
> Using this example scheme file I made the following observations: if I
> comment out the (set! geometry ...) statement, the memory usage keeps
> constant. If I just comment out the dispersive material, there is still an
> increment in memory but not nearly as bad, so it seems that it is keeping the
> geometry in memory after each iteration. Is there any way to force meep to
> clear the memory used for the geometry? I tried forcing a garbage collection
> with the command (gc), but it had no effect.
>
> I append the code i have been working with and a plot of the memory usage
> during the 6 iterations. I would be grateful for any suggestion about how to
> avoid this.
>
> Best Regards
> Lur Eguiluz
> _______________________________________________
> meep-discuss mailing list
> [email protected]
> http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
_______________________________________________
meep-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
