missing cell problem

[yaolun]

Hi,

I have encountered this missing cell problem multiple time during the raytracing part of LIME, and am wondering if anyone has a similar experience, and suggestions to fix it.

This is the error message I got at the end of the run, and no image is produced at the end.

Error: Something weird going on. Cannot find a cell with ID 1396939

The cell ID changed from time to time.

I am running pylime with a grid with max radius ~ 60000 AU and a minimum scale of 0.2 AU. pylime is run in multi-threads mode, but this problem also occur when running in single thread. The image parameters I used are:

par.img[-1].imgres = 0.1
par.img[-1].pxls = 500
par.img[-1].distance = 200 (shown here in parsec, but in meters in the actual code)

I think the imaging parameters are well within the boundary of the grid and the resolution should be fine with the minimum scale of the grid.

The nature of this problem is unclear to me, so I poked around to observe its behavior. My first thought to fix this problem is to fix the imaging parameters, but I don't see how they can be wrong. This problem does get away if I set the image resolution to 1 arcsec, but I don't think this is how LIME suppose to work.

Then I started to wonder about other parameters and found out that reducing the number of the threads did help to fix this problem, but it does not always work. For instance, 20 threads with 1 arcsec resolution failed, but 5 threads with 1 arcsec resolution is fine. But 5 threads with 0.5 arcsec resolution doesn't work. Also using a single thread also failed with sub-arcsec resolution in this case.

So I am wondering if anyone has experienced this problem before, or has some insight about what could be the origin of this error. Thanks for the help!

[allegroLeiden]

I have not come across this myself, but my immediate feeling is that the problem is topological, rather than anything to do with resolution or number of threads. Changing such settings may mask or unmask the underlying problem but I doubt that they are causing it. The Achilles heel of Lime is its reliance on the package qhull to construct the grid connectivity from the set of grid points. Qhull has the undesirable feature of failing silently if the grid points do not meet a set of ill-defined criteria. I suspect this may be occurring now.

If you can mail me the model file (+ other input files) you are using, and tell me the version of Lime you use, I will try to find time to have a look myself.

[allegroLeiden]

Hmm, 1396939 is also quite a large number. Where I have added an integer-type field in Lime, I have usually made it unsigned long, but a lot of the original variables of this sort are simple integers, which is a type not guaranteed to hold a value larger than 32,767. How many grid points are you using?

[yaolun]

I am only using 50000 grid points with 8000 sink points. That's part of the reason that I am quite confused with this error message because of the large value in ID.

Let me prepare for a bit, and then I will send you the grid file. Thanks.

[allegroLeiden]

Ok, I got your mail and have downloaded the model.py, the lime_config.txt file, and the 5 grid files. I've also looked at your log files. However I don't yet have enough information to start looking for the bug.

Mostly, you need to tell me exactly what version of the code you are using. I don't mean the version number that appears in the output, I mean, did you download it from github from one of the numbered releases? Or just from the master track? Exact description of the code version is always the first thing you should mention when reporting any bug, anywhere. If (as many people do) you downloaded the master track as a zip file, the first thing I am going to ask you to do is to download the latest release instead (which has stable code) and try with that.

As soon as you tell me that, I think I have everything I need to run LIME with your grid5 file as input and your image params as specification. I don't have your dust file, but I can run with a standard one. That won't alter whatever bug is producing the error.

[yaolun]

Sorry, I forgot to mention that.

I was running LIME version 1.9 (commit dc4ed5f), and I then updated to version 1.9.2 (commit 81fdc0e), which I believe is the latest release. However, the same issue still occurs with the latest release of LIME. The qhull version I have is qhull_r 7.2.0 (2015.2.r 2016/01/18).

I've sent you the dust file via email. I don't think it will matter either.

[allegroLeiden]

Ok, I'm seeing a little way into this issue now. It is indeed related to qhull. This is called within raytracing if par->traceRayAlgorithm is set to 1, because raytrace then performs a linear interpolation within Delaunay cells. The routine calls qhull so as to set up the cells. I have not yet come across the exact error you report but the loop in which this error message occurs is taking far too long.

I'll keep looking for the error but in the meantime you could try running with par->traceRayAlgorithm = 0. That avoids the qhull call. It runs to completion for me with your supplied grid5 file.

[yaolun]

Thanks for the quick response. It does work with traceRayAlgorithm=0. I will use that option instead until further solution posted. Thanks again!