USGS demo models

[kbagstad]

A rehash of our email conversation titled "odds and ends San Joaquin errors" - two problems here:

1) model -d core.models.carbon-ca/percent-vegetation-cover core.contexts.beta/san_joaquin512 produces the error: "disjoint intervals for ordered range mapping of carbonService:PercentVegetationCoverClass: 0.0 -- Infinity"

As you point out, "This means exactly what it says - disjoint = non-contiguous or non-finite intervals. You can't determine the numeric midpoint of the intervals if they're like that (say [1 100] [101 200] instead of [1 100] [100 200]."

BUT, see my response: But look at the carbon_ca.clj file - and the percent-vegetation-cover defmodel statement. As near as I can tell, the intervals are NOT disjoint, at least not in the way you suggest above. Unless that is I'm using the :inclusive and :exclusive statements incorrectly - which is a distinct possibility, but I think they're used right.

2) model -d core.models.carbon-ca/identification-carbon-sj core.contexts.beta/san_joaquin512 produces the error: "resource not found: cannot observe any of the 1 contingencies of model core.models.carbon-ca/vegetation-type"

Your response: "Data missing for that context. Same story as before - should be taggable optional but isn't, remove dependency or wait for me to enable that. If data should be there but aren't you may need an initdb?"

My response: " OK, yes. But I DID remove the dependency again look in the model at the context list for identification-carbon-sj! It calls on source-sj and sink-sj, among others, and neither sink-sj nor source-sj calls on vegetation type in its context list! This is the source of my big confusion - it seems I'd manually removed offending items from the context lists, but am still having problems!"

Next steps??

[fvilla]

OK, part 1: you have written [0] for the No classifier, which is an interval without the second boundary. The proper classifier would be just a 0, without the brackets. Note however that we're talking about something that will end up in a BN so this would require special treatment, as all classes are supposed to map to a range of which the midpoint provide the maximum likelihood numeric value. I will implement the special case, but for the time being I suggest that the model (committed to dev) becomes

(defmodel percent-vegetation-cover PercentVegetationCoverClass (classification (ranking habitat:PercentVegetationCover :units "%") [80 100] VeryHighVegetationCover [60 80] HighVegetationCover [40 60] ModerateVegetationCover [20 40] LowVegetationCover [0.001 20] VeryLowVegetationCover [-0.001 0.001] NoVegetationCover))

this one will capture the 0 which is also the midpoint of the interval, so no problems undiscretizing and discretizing back, and everything is an interval so it works properly without having to write a code exceptions. In all cases, [0] is wrong and it's the reason for the error - it would default to 0 - infinite. The :exclusive and :inclusive are correct and useless, as the default behavior for ranges is exclusive left, inclusive right - exactly to be able to discretize ranges with a minimal syntax.

[fvilla]

OK, after 2 hours spent looking for a bug for #2, it's very obvious that carbon_ca.clj needs lots of attention. The dependency chain is messed up - the sink-sj model depends on veg-soil-storage-sj which classifies vegetation-soil-storage, that brings in the dependency. Classifying vegetation-soil-storage-sj, which would look like the fix, won't help as its dependencies are exactly the same as the non-sj version, except the keywords in the code are -sj so they would always be null.

So no bug, and it's been a very long while since any of these issues exposed bugs rather than model errors. I will try to enable the tracking of optional dependencies in BNs as fixing these dependency chains is obviously messy for modelers. Hopefully within a week or so, the problem is that adding features to this branch it holds me back developing a better version, but I'll do what I can.

[kbagstad]

Well, finally got that sucker running. You're right though - about fixing dependency chains as a messy process for modelers. More like there are landmines everywhere just waiting to be stepped on :) Look forward to a better long-run solution somewhere down the road.