More flexible mesh specification

[jkbest2]

I've started looking at how we could make mesh specification more flexible, and possibly provide some guidance so that people are using meshes that provide a good approximation of a Matern GRF. I've seen advice about this in a few of the INLA group's papers, but it seems to be gathered fairly well into Section 1.3 (p. 31) of

https://www.math.ntnu.no/inla/r-inla.org/tutorials/spde/spde-tutorial.pdf

Some of their specific recommendations include:

• Making sure max edge lengths are ~1/3 of the effective range of the covariance kernel. Presumably this applies to the shortest range in the anisotropic case. Playing around with INLA::meshbuilder, you can see the distortion effects with this is violated.
• Use the cutoff argument to avoid very small triangles.
• Use the min.angle argument to avoid triangles with small angles.
• Define a 'buffer' area outside the area of interest to avoid edge effects.

Based on our discussions at CAPAM, one of the major decisions that needs to be made in an analysis is the domain of interest. I'd suggest that this domain should be defined explicitly, and then a buffer produced outside this. Any indices would only use the inner area.

I'm still digging through the code, but it looks like the there are a couple approaches here (while trying to maintain backward-compatibility)

• Let users pass the refine argument to Spatial_Information_Fn through Calc_Anisotropic_Mesh for INLA::inla.mesh.create.
• Let users pass other arguments to the ... in Calc_Anisotropic_Mesh through Spatial_Information_Fn. This will be trickier because the ... is currently used to pass extra arguments to the clustering function.
• Allow passing a mesh created using INLA::inla.mesh.create through Spatial_Information_Fn to Calc_Anisotropic_Mesh. This could probably be done by just adding an argument anisotropic_mesh = NULL argument. This may be the easiest option for now.

I'm open to suggestions, alternate approaches, and anything I missed. I'm still figuring out how everything fits together.

[James-Thorson]

Thanks for laying out the options so clearly and thoroughly! Very helpful.

I think option 3 is the best for now, and then another function could be added to explore mesh generators. Are you willing to branch and explore, or is this more a record for future reference.

[jkbest2]

I've branched and added option 3, but I'd like to add a test. It's only a couple changed lines, so I may submit a preliminary PR in the next few days.

[James-Thorson]

Ok I recommend adding a function that would generate a new mesh using their mesh GUI to explore options, and adding doxygen documentation that includes those suggestions in the details section. But open to ideas (within reason)

…

On Mar 2, 2018 2:47 PM, "John Best" ***@***.***> wrote: I've branched and added option 3, but I'd like to add a test. It's only a couple changed lines, so I may submit a preliminary PR in the next few days. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHnqTXu6CcxpU4h9cW1x1Ir6sOpFcyksks5tacwPgaJpZM4SafC1> .

[jkbest2]

That sounds like a good idea. It will probably be a week or so before I can work on it, but I don't think it should be too hard to get working.

[zeroyin]

Just my thought: is it too much to pass a user defined function so that the user can create a mesh using these kmeans centers calculated within Spatial_Information_Fn.R...

[smormede]

Hi there,
On a slightly different but related subject, I have locally slightly modified the function Spatial_information_Fn to allow a user-defined grid (not mesh) to be provided. I wanted my output to be in exactly the same projection and grid as other data required. It's only a couple lines of code. Happy to provide if anyone else is interested.