fix segmentation fault in material_grids_addgradient of adjoint solver

[oskooi]

Fixes a segmentation fault in the function material_grids_addgradient_point of src/meepgeom.cpp in the following lines:

meep/src/meepgeom.cpp

Lines 2600 to 2603 in 8e2b0a0

	// no object tree -- the whole domain is the material grid
	if (!tp && is_material_grid(default_material)) {
	vector3 pb = to_geom_box_coords(p, &tp->objects[oi]);
	vector3 sz = mg->grid_size;

The problem is that tp (a pointer to a geometry tree) is a NULL pointer when entering this if-statement block which causes a segmentation fault when &tp->objects[oi] is invoked.

[smartalecH]

Seems fine after initial inspection -- would be good to add a simple test before merging.

[smartalecH]

I've never used this before, but I assume it's the same as above but assumes a box the size of the simulation cell (the lattice in this case)?

Maybe make sure there's no weird issues with the boundaries (when I read lattice I assume periodic boundaries, which obviously isn't always the case) just make sure the last edge in each dimension is mapped to "1" and not back to "0" (or vice-versa).

(Ideally the two routines use the same mapping logic and the only difference is the default geometry in this case)

[oskooi]

The function map_lattice_coordinates maps elements of the vector3 parameter p into the range [0,1]:

meep/src/meepgeom.cpp

Lines 374 to 381 in 8e2b0a0

	void map_lattice_coordinates(double &px, double &py, double &pz) {
	px = geometry_lattice.size.x == 0 ? 0
	: 0.5 + (px - geometry_center.x) / geometry_lattice.size.x;
	py = geometry_lattice.size.y == 0 ? 0
	: 0.5 + (py - geometry_center.y) / geometry_lattice.size.y;
	pz = geometry_lattice.size.z == 0 ? 0
	: 0.5 + (pz - geometry_center.z) / geometry_lattice.size.z;
	}

I think you were the one that set up the mapping this way. As long as p is defined to be within geometry_lattice, it should map points along the boundaries correctly.

[smartalecH]

Note that this fix is only for the case where the MaterialGrid is passed as a default material, which has never been rigorously tested (obviously since a pointer was being dereferenced when it was already determined to be NULL)

This seg fault is not associated with normal use with MaterialGrids inside of Block geometry objects (not clear from above synopsis).

[oskooi]

#1539 added a new unit test for MaterialGrid as the default material but only as part of a "forward" simulation (i.e., no gradient calculation). We do not yet have a similar test involving the adjoint solver which is why this bug has gone undetected.

[ianwilliamson]

This seg fault is not associated with normal use with MaterialGrids inside of Block geometry objects (not clear from above synopsis).

Just wanted to jump in and say that I have observed segfaults from this function under the normal use that you describe (MaterialGrid in an mp.Block). I agree that what you're saying should be the case, but since the function doesn't have a unit test it's hard to say for sure what's actually happening here.