The included XDMF writer only works for DMPlex objects.

Pixmesh example (Pixmesh Octopants) - some missing functionality in Pixmesh ?

(https://github.com/underworld-community/quagmire-examples-and-workflows/blob/master/Notebooks/IdealisedExamples/PixMeshOctoPants.ipynb)

~/+Codes/Python/quagmire/quagmire/topomesh/topomesh.py in _build_down_neighbour_arrays(self, nearest)
    189         nheightn = nheight.copy()
    190         # nheightn[~self.near_neighbour_mask] += self.height.max()
--> 191         nheightn[~self.near_neighbour_mask] += self._heightVariable.data.max()
    192         nheightnidx = np.argsort(nheightn, axis=1)
    193 

AttributeError: 'SurfaceProcessMeshClass' object has no attribute 'near_neighbour_mask'

Something to do with feedstock:

https://github.com/conda-forge/petsc-feedstock/issues

mesh.topography.load("global_OC_8.4_topography.h5")

should fail because the topography variable is locked (because it should be used within a context manager). The following is not allowed without the context manager

mesh.topography.data = 0.0

We want to be able to save the mesh to an HDF5 file along with mesh variables, and rebuild all the relevant data structures using that same file.

I think the .quag extension is pretty cute too.

Still need to decide whether to include a stripped back user manual for Quagmire, but all workflow stuff should be moved out of the man repository.

I still like the idea of using Quagmire to install the documentation.

quagmire.documentation.install_documentation(path="./Quagmire-Notebooks")

Perhaps a good solution is for this function to clone the examples/community repo to the install location, and download all the data to run the examples from CloudStor.

Points are randomised in create_DMPlex_from_points to improve triangulation performance, but this breaks some existing code in the notebooks. It can be easily fixed, but I'm not sure which is better...

1. Put the permutation routine in the other mesh generation functions, and assume the x,y vectors are shuffled prior to making the DM.
2. Have a convenience method get_xy in trimesh to return the shuffled (local) x,y vectors.

The second option might be wiser since refinement will add new points anyway.

The updated petsc etc (#10) has broken the old conda-based build and test workflow. Should be simple to update but does need to be done.

I don't think I understood this at the time... here are you including the two closest neighbours outside the immediate node neighbours? Sort of a limited extended-neighbours search?

Everything in sTriMesh is currently in radians to be compatible with stripy, but perhaps mesh creation, interpolation and derivatives should all be in degrees to match geospatial data.

In SurfaceProcessMesh, the context manager to update the topography rebuilds the downhill matrix and integrates the upstream area, whereas the downhill_neighbours setter just rebuilds the downhill matrix. This is because the property is defined only on the TopoMesh class while the context manager is overridden on the SurfMesh class. I'm not sure if this is intended?

Also it would be good to have the option to set the downhill neighbours from the context manager, e.g.

class Surfmesh_Height_Update_Manager(object):
    """Manage when changes to the height information trigger a rebuild
    of the topomesh matrices and other internal data.
    """

    def __init__(inner_self, downhill_neighbours=downhill_neighbours):
        inner_self._surfmesh = surfmesh
        inner_self._topovar = topographyVariable
        inner_self._downhill_neighbours = int(downhill_neighbours)
        return

    def __enter__(inner_self):
        # unlock
        inner_self._topovar.unlock()
        inner_self._surfmesh._downhill_neighbours = inner_self._downhill_neighbours
        return

    def __exit__(inner_self, *args):
        inner_self._surfmesh._update_height()
        inner_self._surfmesh._update_height_for_surface_flows()
        inner_self._topovar.lock()
        return

Not sure if anyone else has encountered this, but if underworld is imported before stripy then the triangulation routines break on my machine. I only discovered this when I merged #20 and all my tests broke because underworld was being imported by the scaling module. I've fixed that now, but something to be aware of in the future. (Though it may just be my machine...)

@lmoresi flagged that a function like this works in underworld but not in quagmire (#13):

my_annoying_fn = fn.math.sin(mymeshvar.fn_gradient[1]**2)

But maybe it's better if fn_gradient gets a list of derivative functions for each direction. So where you may currently do something like this:

interpolate_derivatives_fn = mymeshvar.fn_gradient(1)
interpolate_derivatives_fn.evaluate(xi, yi)

which interpolates derivatives in the y direction at (xi,yi), you would instead write:

interpolate_derivatives_fn = mymeshvar.fn_gradient[1]
interpolate_derivatives_fn.evaluate(xi, yi)

What should we go with? If the second one is more compatible with the UW way of things then I'd to go with that, but it would require a bit of patience to dig out all instances of the former implementation.