GMRFLib: Fail to factorize Q

[Facundo Muñoz]

Hi again,

I'm getting this error now:

file: smtp-taucs.c hgid: 670edc82d6b9 date: Fri Jun 24 11:02:50
2011 +0200
Function: GMRFLib_factorise_sparse_matrix_TAUCS(), Line: 771, Thread: 0
Fail to factorize Q. I will try to fix it...

it repeats six times, and then...

GMRFLib version 3.0-0-snapshot, has recived error no [12]
Reason : The Newton-Raphson optimizer did not converge
Function : GMRFLib_ai_marginal_hyperparam
File : approx-inference.c
Line : 552
RCSId : file: approx-inference.c hgid: 670edc82d6b9 date: Fri
Jun 24 11:02:50 2011 +0200

Which I assume is a consequence of the first.

Could it be because I have too many vertices in the mesh (9460)?

Is there any control parameter related with this, so I can play with?
Maybe, tolerance in control.inla? But I don't know from the help what
values are default to have as a reference.

Thank you!
Facundo.-

[Håvard Rue]

On Wed, 2011-06-29 at 12:55 +0200, Facundo Muñoz wrote:
> Hi again,
>
> I'm getting this error now:
>
> file: smtp-taucs.c hgid: 670edc82d6b9 date: Fri Jun 24 11:02:50
> 2011 +0200
> Function: GMRFLib_factorise_sparse_matrix_TAUCS(), Line: 771, Thread: 0
> Fail to factorize Q. I will try to fix it...
>
> it repeats six times, and then...
>
> GMRFLib version 3.0-0-snapshot, has recived error no [12]
> Reason : The Newton-Raphson optimizer did not converge
> Function : GMRFLib_ai_marginal_hyperparam
> File : approx-inference.c
> Line : 552
> RCSId : file: approx-inference.c hgid: 670edc82d6b9 date: Fri
> Jun 24 11:02:50 2011 +0200
>
> Which I assume is a consequence of the first.

this is correct.

> Could it be because I have too many vertices in the mesh (9460)?

no, that's not the issue. it simply fail to converge. since it say that
'Q' fail to factorize, some eigenvalues of Q are very small. without
seeing the code, often the impropr default prior of the intercep is the
issue, so try this

inla(..., control.fixed= list(prec.intercept = 1))

or something, and check if that helps. then its the issue.

if that does not solve the problem, send me data and code so I can rerun
it here.

Best
H

--
Håvard Rue
Department of Mathematical Sciences
Norwegian University of Science and Technology
N-7491 Trondheim, Norway
Voice: +47-7359-3533 URL : http://www.math.ntnu.no/~hrue
Fax : +47-7359-3524 Email: havar...@math.ntnu.no

This message was created in a Microsoft-free computing environment.

[Facundo Muñoz]

El 30/06/11 11:01, Håvard Rue escribió:

On Wed, 2011-06-29 at 12:55 +0200, Facundo Muñoz wrote:

Hi again,

I'm getting this error now:

    file: smtp-taucs.c  hgid: 670edc82d6b9  date: Fri Jun 24 11:02:50
2011 +0200
    Function: GMRFLib_factorise_sparse_matrix_TAUCS(), Line: 771, Thread: 0
    Fail to factorize Q. I will try to fix it...

it repeats six times, and then...

    GMRFLib version 3.0-0-snapshot, has recived error no [12]
    Reason    : The Newton-Raphson optimizer did not converge
    Function  : GMRFLib_ai_marginal_hyperparam
    File      : approx-inference.c
    Line      : 552
    RCSId     : file: approx-inference.c  hgid: 670edc82d6b9  date: Fri
Jun 24 11:02:50 2011 +0200

Which I assume is a consequence of the first.

this is correct.

Could it be because I have too many vertices in the mesh (9460)?

no, that's not the issue. it simply fail to converge. since it say that
'Q' fail to factorize, some eigenvalues of Q are very small. without
seeing the code, often the impropr default prior of the intercep is the
issue, so try this

inla(..., control.fixed= list(prec.intercept = 1))

or something, and check if that helps. then its the issue.

Well, now it gives the error only once, instead of six.
I tried with precisions 1, 10 and 100.
So it seems there is something else

if that does not solve the problem, send me data and code so I can rerun
it here. 

Thank you.
Before that, could it be because the mesh has some vertices too close to their neighbours?
Take a look at the image below.
I constructed a boundary from a coastline.
So vertices along the coast are really close each other.

Thanks!
Facundo.-

[Håvard Rue]

On Thu, 2011-06-30 at 11:49 +0200, Facundo Muñoz wrote:

> Before that, could it be because the mesh has some vertices too close
> to their neighbours?
> Take a look at the image below.
> I constructed a boundary from a coastline.
> So vertices along the coast are really close each other.

yes... if they are really close then they can easily be numerically
singular. I think the option to use is

cutoff: The minimum allowed distance between points. Point at most
as far apart as this are replaced by a single vertex.

in inla.mesh.create. If not, contact the wizard, Finn Lindgren.

[Finn Lindgren]

Yes, try the "cutoff" option for mesh=inla.mesh.create(loc,...).

Setting, for example, cutoff=4 only allows the triangulation algorithm to use input locations at an euclidean distance greater than 4.
The indices in
mesh$idx$loc
are then assigned, for each input point in  loc, the closest vertex in the resulting mesh.

In your case, this will smooth the boundary of the mesh.  From your picture, it looks as your'e using boundary=..., which can result in some of the interior "loc" points falling outside the resulting smoothed region.  That will not handled handled correctly by mesh$idx$loc, but apparently you don't have any "loc" input points so this may not be a problem, depending on how you use the resulting mesh later in the analysis.  Can't say anything more specific without the actual code.

/Finn

[Facundo Muñoz]

This helps.
I got rid of the errors.

Thank you very much!

Facundo.-

El 01/07/11 07:44, Finn Lindgren escribió: