Meant to send the below reply to the list!
The gmap plot require the mesh to be constructed with
inla.mesh.2d(..., crs=CRS(proj4string(b_in)))
so that it knows how to convert it to longitude/latitude for plotting.
Finn
---------- Forwarded message ----------
From: Finn Lindgren <
finn.l...@gmail.com>
Date: 8 May 2018 at 20:10
Subject: Re: [r-inla] Predict on output of lgcp from inlabru gives
unexpected result
To: Virginia Morera Pujol <
morera....@gmail.com>
Hi,
I believe in your suspicion that it runs into problems due to the
geometry being tricky with so many points close to the boundary, but
I'll keep investigating why it fails so spectacularly.
Also, could you send me the example code for the 2km expanded buffer
as well? 2km however is a tiny buffer, since cutoff is 10 km. A 20km
buffer would be more reasonable (but see below about other model
options).
Predicting on the log-scale shows the problem more clearly:
lmbd1 <- predict(fit0, pixels(mesh), ~(Intercept + mySPDE))
ggplot() + gg(lmbd1["median"]) + coord_equal()
As you noted, there's a single hotspot near the coast where the model
breaks down. In the past, such hotspots were the cause of an invalid
numerical integration scheme in the lgcp likelihood approximation, but
the current method shouldn't behave like this.
Predicting log(abs(...)), just to see if there is any pattern hiding
underneath, does show a pattern that connects reasonably well to the
actual point pattern, so it seems it's just the one hotspot that cases
some numerical issue.
Since the current CRAN version, we have fixed a few minor bugs,
available in the development version; see
https://github.com/fbachl/inlabru/tree/devel for installation
instructions,
but since I was running the development version, this clearly did not
help in this case.
You should take a look at Haakon's "barrier" SPDE models, that deal
much better with this kind of situation; several recent threads
discuss those.
As far as I'm aware of, noone has used them in combination with
inlabru yet, but I'm keen to get those working, so if you try them and
run into problems, please let me know!
In principle, they should work seamlessly with inlabru::lgcp(), but
the inner workings of the inlabru&inla code may complain a bit...
Btw, you might find this code helpful (at least I did, since it helped
me verify that your coordinate system makes sense!)
inlabru::gmap(ds.df2) + gm(ds.df2,mapping=aes_(~x,~y)) + gm(mesh)
Resulting plot is attached.
Finn
On 8 May 2018 at 19:40, Finn Lindgren <
finn.l...@gmail.com> wrote:
> Hi,
> turning on verbose output with options=list(verbose=TRUE) reveals that
> inla() is struggling with the optimisation due to NaN or Inf
> appearing; I'm not sure of the precise reason for that.
>
> Finn
>> --
>> 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 post to this group, send email to
>>
r-inla-disc...@googlegroups.com.
>> Visit this group at
https://groups.google.com/group/r-inla-discussion-group.
>> For more options, visit
https://groups.google.com/d/optout.
>
>
>
> --
> Finn Lindgren
> email:
finn.l...@gmail.com
--
Finn Lindgren
email:
finn.l...@gmail.com
--
Finn Lindgren
email:
finn.l...@gmail.com