Copy feature in inlabru

[Virgilio Gómez Rubio]

Hi,

I am trying to fit a model with inlabru in which one of the effects is a copy of another. Apparently, the name of the copied effect cannot be found. I include a replicable example below. I get the same error when trying to fit mi (bigger) model. What might be wrong when defining the copy’ed effect?

Best,

Virgilio

---


library("inlabru")
library("MASS")
data("cement")

# This works
bru(y ~ x1 + x2, data = cement)

# This doesn't work
bru(y ~ x1 + x2(x2, copy = "x1"), data = cement)
# *** ERROR *** ffield 0 is F_COPY and a copy of x1 which is not found

[Finn Lindgren]

This probably because x1 is a linear effect, where taking a “copy” isn’t very useful.
Have you tried the random effect case, e.g. with x1(x1, model=“iid”) ?

Ps. Be careful with “copy” in nonlinear predictor models; I’ve noticed issues with convergence for such models. But then using a direct product of a fixed effect and the model to be copied, tends to work very well as an alternative.

Generally, copy models are much less needed in inlabru, due to the nonlinear capabilities…

Finn

> On 19 Jul 2024, at 14:25, 'Virgilio Gómez Rubio' via R-inla discussion group <r-inla-disc...@googlegroups.com> wrote:
>
> Hi,

> --
> 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/C1ED9AFE-7FB3-4F50-82ED-21BFDF06C572%40uclm.es.

[Virgilio Gómez Rubio]

Hi,

> This probably because x1 is a linear effect, where taking a “copy” isn’t very useful.
> Have you tried the random effect case, e.g. with x1(x1, model=“iid”) ?

Yes, that would work.

In my original model I have two likelihoods of data defined at different scales. I have fixed effects based on different raster variables and I want them to share the same coefficient. I thought a “copy” effect would be useful here. Alternatively using iid on a single group (idx =1 for all values) will allow me to copy the effect safely, right?

> Ps. Be careful with “copy” in nonlinear predictor models; I’ve noticed issues with convergence for such models. But then using a direct product of a fixed effect and the model to be copied, tends to work very well as an alternative.

Thanks but I believe my model is simpler...

Best,

Virgilio

[Finn Lindgren]

For a completely shared coefficient, you can use
+ mycoefficient(1)
In the components, and in the formulas
Form1= … + mycoefficient * covar1
Form2=…+mycoefficient * covar2
The formulas are general R expression evaluated in the context of variables and effects…
Finn

> On 19 Jul 2024, at 14:37, 'Virgilio Gómez Rubio' via R-inla discussion group <r-inla-disc...@googlegroups.com> wrote:
>
> Hi,

> --
> 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/AC23E10F-3C48-4780-8540-E1195DB5E0FD%40uclm.es.

[Finn Lindgren]

…or even simpler:

Comp=~mycovar(covar,model=“linear”)
Like1=like(y1~mycovar, data=data.frame(y1,covar=covar1),…)
Like2=like(y2~mycovar, data=data.frame(y2,covar=covar2),…)

But some of these version are like copy with fixed=TRUE; that combination is really never needed with inlabru, as the above technique, and my previous reply, does exactly that.

For fixed=FALSE copies, it depends on how what type of control one needs over the prior, etc.

For spatial covariates and point process, one can need some eval_spatial() calls to evaluate the covariate(s) “on the fly”.

Finn

> On 19 Jul 2024, at 16:32, Finn Lindgren <finn.l...@gmail.com> wrote:
>
> For a completely shared coefficient, you can use

[Havard Rue]

If you write the fixed affect as iid with fixed precision , it can be copied , grouped etc 

-- 

Håvard Rue 

hr...@r-inla.org

To view this discussion on the web, visit https://groups.google.com/d/msgid/r-inla-discussion-group/6B28966A-7119-4D07-9BF0-3DDAABD334FC%40gmail.com.

[Finn Lindgren]

Yes, I realised that in a similar context in the thread on the list with Gabrielle today. :)

Finn

[Virgilio Gómez Rubio]

Hi,

Finn and Håvard, many thanks for your comments. I’ll check the different options but probably defining it as an iid and copy the effect might be easier given that my covariates are SpatRasters and these are handled quite nicely within a component.

Best,

Virgilio

[Virgilio Gómez Rubio]

Hi,

> For spatial covariates and point process, one can need some eval_spatial() calls to evaluate the covariate(s) “on the fly”.

As this is my case, I have implemented my model using two approaches and one likelihood (for now):

(1) components: IGlobal(1) + spatial (ans SPDE) + bio4(1) (the covariate effect)

Lik. Formula: IGlobal(1) + spatial + bio4 * f.raster(my_raster, “mylayer”) (calls eval_spatial() internally)

(2) components: IGlobal(1) + spatial (ans SPDE) + bio4(sp_covglo$bio4) (a SpatRaster)

Lik. Formula: IGlobal(1) + spatial + bio4

Approach (2) is way faster than (1). Is this to be expected? It seems bru() spends a long time pre-processing the data as I have run the model verbosely and I only see the INLA output from time to time...

The difference is considerable and I need approach (1) to share the coefficients easily between two likelihoods. BTW, for a single likelihood both models give very similar estimates (as it should be).

Best,

Virgilio

[Finn Lindgren]

Hi,

Yes, the problem is that method 1 evaluates the raster multiple times, but method 2 only when setting up the model.

This can be solved by using a constant component fir the raster, so it can reevaluate it:

Component:

+ covar(f.covar(...), model="const")

Formula:

+ bio4 * covar

--
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/3178E6F3-6CF1-4379-96B6-6AD737C356AA%40uclm.es.