raster layers hanging on San Pedro carbon-sink

[kbagstad]

Ciao Ferd -

Another major problem (along with the bayesian statement email I sent earlier today - this is big problem #2 that is holding up a number of our source/sink/use models). In the carbon-san-pedro model, I can get the source and use models, as well as all the inputs in the sink model to run in model -d or -o just fine. Problems arise when model -d or -o'ing vegetation-carbon-storage or soil-carbon storage. Simple BNs, and the "source" BN behaves just fine. However when I try to run either model -d core.models.carbon-san-pedro/vegetation-carbon-storage core.contexts.beta/san_pedro_us256 or model -d core.models.carbon-san-pedro/soil-carbon-storage core.contexts.beta/san_pedro_us256 I get the following "hanging" on the usa:canopy_5 layer, which behaves fine in geoserver and when it's called on in the source model or individually in percent-vegetation-cover. Very perplexing...

2011-05-13 13:27:37,960 [main] INFO org.integratedmodelling.geospace.Geospace reading WCS source http://ecoinformatics.uvm.edu/geoserver/wcs#sanPedro:swregap_lulc accessing: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=sanPedro:swregap_lulc 2011-05-13 13:27:38,204 [main] INFO org.integratedmodelling.geospace.Geospace parsing descriptor for sanPedro:swregap_lulc 2011-05-13 13:27:38,304 [main] INFO org.integratedmodelling.geospace.Geospace reading WCS source http://ecoinformatics.uvm.edu/geoserver/wcs#global:annual_precip_global accessing: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=global:annual_precip_global 2011-05-13 13:27:38,441 [main] INFO org.integratedmodelling.geospace.Geospace parsing descriptor for global:annual_precip_global 2011-05-13 13:27:38,664 [main] INFO org.integratedmodelling.geospace.Geospace reading WCS source http://ecoinformatics.uvm.edu/geoserver/wcs#usa:canopy_5 accessing: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=DescribeCoverage&coverage=usa:canopy_5 2011-05-13 13:27:38,797 [main] INFO org.integratedmodelling.geospace.Geospace parsing descriptor for usa:canopy_5 2011-05-13 13:27:38,881 [main] INFO org.integratedmodelling.thinklab.riskwiz.RiskWizPlugin bayesian engine set to riskwiz WCS URL: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=GetCoverage&coverage=global:annual_precip_global&bbox=-111.012,31.328,-109.845,33.281&crs=EPSG:4326&responseCRS=E PSG:4326&width=153&height=256&format=geotiff WCS URL: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=GetCoverage&coverage=sanPedro:swregap_lulc&bbox=-111.012,31.328,-109.845,33.281&crs=EPSG:4326&responseCRS=EPSG:43 26&width=153&height=256&format=geotiff WCS URL: http://ecoinformatics.uvm.edu/geoserver/wcs?service=WCS&version=1.0.0&request=GetCoverage&coverage=usa:canopy_5&bbox=-111.012,31.328,-109.845,33.281&crs=EPSG:4326&responseCRS=EPSG:4326&width= 153&height=256&format=geotiff

Ken

[fvilla]

I just tried both of these and they both ran to completion without a problem. Are you still getting it? Looks like geoserver collateral damage to me.

[kbagstad]

Ciao Ferd -

Tried it again this morning, and this time it hung on the global:slope90m layer. Indeed seems like a geoserver problem is the root cause, but I can't diagnose a thing since it just hangs and doesn't produce any error messages. Gary, can you add anything on the subject based on our debugging session and conversation friday afternoon? You were getting the same hanging behavior too, right?

Thanks, Ken

On Sat, May 14, 2011 at 3:50 PM, fvilla < reply@reply.github.com>wrote:

I just tried both of these and they both ran to completion without a problem. Are you still getting it? Looks like geoserver collateral damage to me.

Reply to this email directly or view it on GitHub: https://github.com/ariesteam/aries/issues/1#comment_1163834

[lambdatronic]

I pulled in the most recent changes to thinklab and aries, cleaned and rebuilt everything. When running the two model commands on the dev branch, I get the same hanging error. I cannot run them on master because your XML is out of sync with the geoserver, and therefore run aries.initdb fails with a NullPointerException.

[kbagstad]

Blech. Try merging dev to master (at least getting kb1.xml into the master). I'd do it, but am out my computer for the afternoon. If you don't get to it today (guess it is getting late in VT) I can do it tomorrow...

Thanks, Ken

On Mon, May 16, 2011 at 4:11 PM, lambdatronic < reply@reply.github.com>wrote:

I pulled in the most recent changes to thinklab and aries, cleaned and rebuilt everything. When running the two model commands on the dev branch, I get the same hanging error. I cannot run them on master because your XML is out of sync with the geoserver, and therefore run aries.initdb fails with a NullPointerException.

Reply to this email directly or view it on GitHub: https://github.com/ariesteam/aries/issues/1#comment_1184930

[lambdatronic]

As an additional piece of information, I would like to point out that when ARIES hangs after running these models on the most recent build, the Geoserver is not hung. I can still navigate to http://ecoinformatics.uvm.edu/geoserver, login, and browse the layers. Also, the usa:canopy_5 layer cannot be the problem. My most recent run of

model -d core.models.carbon-san-pedro/vegetation-carbon-storage core.contexts.beta/san_pedro_us256

actually hung after the INFO message for the sanPedro:swregap_lulc GetCoverage request. If I copy and paste the URL used in the ARIES log message into my browser, I successfully download that layer just fine. This means that there should not be a problem downloading the layers from Geoserver (i.e. it's not a Geoserver problem). ARIES is hanging after it gets all the layers for some reason.

Thanks for investigating this one, Ferd.

[fvilla]

guys, I just ran this one 10 times in a loop, from Tunisia with a wobbly connection, and every time it completes in seconds. Are you getting it consistently? If not, remember that this stuff has completely deterministic behavior, so it can't be Thinklab, either. Gary, the obvious things you should do when you're blessed enough to get this are 1) look at the GS logs to see if anything looks strange - after checking that there is only one instance running etc. - and 2) you have the code, if this still hangs run it with a debugger and see where it hangs. I'll run this again between presentations, but until I get an error I can't really fix it, sorry.

[fvilla]

...while if it does hang consistently, and consistently doesn't for me, the obvious thing to suspect is the 64-bit setup you're running and I'm not (and won't until I spend my savings on another computer and stay home long enough to set it up). The obvious thing to suspect if so is the imageio library that reads the TIFFs in, particularly if you have it in your JVM and is also in the plugin (which it now is, as Gary suggested before). I'd play with plugin.xml, commenting out the jai_imageio entry and/or with the JVM, see if that changes anything. It certainly works at my side but still I need the 32bit imageio installed otherwise nothing works...

[fvilla]

All related problems should be fixed by now.