spatially varying effect in a coregionalisation model (inlabru)

[Christos Kokaliaris]

Dear INLA group,

I would like to assess the hypothesis that the effect of a coregional outcome (or a continuous transformation of it) on another outcome may vary in space and was wondering if this can be modeled straightforwardly through INLA/inlabru.

e.g.
Assume X(s) is an observed spatial covariate modeled as
X(s) ~ m + W(s), where W(s) is a zero-mean GRF

and Y(s) is another observed spatial covariate that is coregional with X(s).
A basic model for Y(s) is:

Y(s) ~ a + lamda*W(s) + Z(s), with W(s) as above and Z(s) a spatial field related purely to Y(s).
However, (if my understanding is correct) in the above model we assume that the effect of the common hidden factor on the outcome Y is constant over space, which might be unrealistic.
Therefore, I was wondering if it would be possible given the current INLA/inlabru framework to compute something like the following:

Y(s) ~ a + lamda(s)*W(s) + Z(s).

Considering the examples from spatially varying coefficients and coregionalisation, I am wondering if the below approach is appropriate:

1) define the model for X(s) as per usual with the appropriate component m(1) + W(coordinates, model = spde) and build the according formula e.g. X ~ m + W
2) define the model for Y(s) with components a(1) + Z(coordinates, model = spde) + lambda(weights = W, coordinates, model = spde) and formula e.g. Y ~ a + lambda + Z.
3) If I wish to include transformations in X(s) within the model i.e X in truth might be count data modeled after a binomial distribution, in that case I would like to estimate the effect of the logit-inverse transformed W(s) field. Is it correct to simply include this in the component definition in 2) i.e. lambda(weights = plogis(W), coordinates, model = spde)?

Thank you in advance for any input you could provide!
With kind regards,
Christos.

[Finn Lindgren]

Hi,

In principle this kind of model can work, yes, but you can’t use one component (W) as weight in another (lambda). Instead, you need to define W and lambda as separate unweighted components, and then define the combination directly in the precinct or expressions, with

X ~ m + W

Y ~ a + lambda*W + Z

The predictor expressions can be arbitrary R expressions, so you could have things like

Y ~ a + lambda*plogis(W) + Z

The main restriction is that you will run into problems if the resulting joint posterior distribution for the latent fields isn’t unimodal. (So in the example above, X needs to be sufficiently informative about W to prevent the product lambda*W in the Y-predictor from leading to multimodality.

Finn

On 1 Mar 2023, at 23:36, Christos Kokaliaris <chris...@gmail.com> wrote:

Dear INLA group,

--
You received this message because you are subscribed to the Google Groups "R-inla discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to r-inla-discussion...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/c6c9f6a0-63b1-4e95-ab94-620a0aecaf18n%40googlegroups.com.

[Christos Kokaliaris]

Thank you for the quick reply, Finn!
This is great news, I will therefore implement the direct model as suggested above. One question though, in this case, it appears similar to an interaction component and I am wondering if then I should include also the main components separately for the Y model i.e. Y ~ a  + lambda + W + lambda*W + Z?
As an alternative, I was considering using the "copy trick" for W (or parts of the linear predictor "copy and zero trick") and plug the copied component as weights, if this would make any sense.
With kind regards,
Christos.

[Finn Lindgren]

For a model with spatially varying lambda, the copy trick won't help you at all.

Whether including lambda and W separately as well as their product
doesn't seem to match your use case at all.
So called "interactions" are usually when you start with a basic
additive linear model with "main effects" and then need some
nonlinearity. product interactions are then sensible for binary
covaraites, as the resulting model fully spans the nonlinear function
space, but for continuous values it's a very different story.
Unfortunately, this distinction is typically ignored in the
literature; if non-linearity is the issue, one should really _also_
add lambda^2 and W^2 to get a second order Taylor approximation to the
non-linearity (which wouldn't make sense in the binary case).

You should carefully consider what makes sense as a predictor
expression in _your_ model/problem, and act accordingly.

Finn

> To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/6f09c6cf-637e-4f55-a914-323d5a9353b7n%40googlegroups.com.



--
Finn Lindgren
email: finn.l...@gmail.com

[Christos Kokaliaris]

This is crystal clear, thank you very much Finn!

Regarding the copy trick, I was considering storing a copy of W with the option fixed = T. (I tried it earlier today and the results came controversial!)

The rationale was, to structure the problem in the same way as we would have done with a fully observed spatially varying covariate (svc) model.

i.e. If we could observe W in space then we would simply implement an svc model where lambda is a spatial field weighted by observed W.
But I understand now this is not equivalent to what we truly have here, since W is randomly generated, and I would erroneously be forcing a single realization (or point estimate) from W as weights to the spatially varying effect.
With kind regards,
Christos.

[Finn Lindgren]

Yes, in inlabru, the "copy" feature is nearly only needed when
estimating a single scaling factor, since internally in inla it's
implemented as a "observed constraint" that the copy should be equal
to the original.
With inlabru, using the original W component directly simply attaches
the observation model directly to the original component, eliminating
the need for a "pseudo copy".

Finn

> To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/f6014ad0-cbe1-4095-b758-5908998addacn%40googlegroups.com.