mars0i / bali Goto Github PK

But it might not. Either make 'data' part of the repo, or cause it to be created if missing. Or something

There are two numbering systems for cropplans. The original one, that represents indexes in all-cropplans, and indexes in cropplans. But cropplans can be reduced or shuffled, so indexes into it aren't canonical. But the numbers displayed in the UI are indexes into cropplans. The switches for what crop plans to include, however, are based on indexes into all-cropplans.

There seems to be a bias toward crop plan 0 and start month 0. This seems to happen even when the crop plans are shuffled, though it's most apparent when the 333033303330 plan exists and is crop plan 0.

Cropping plan 0 and start month 0 seems to be what the majority of subaks end up with on every run. Is this because it's really the best pattern, or is it an artifact--because it's the first plan and the first month, for example? What is the effect on yield and pests of varying this?

One way to experiment with this is to swap variable names in procedure cropplans.

10/2/2014 I rewrote Janssen's original growpest procedure, first by making incremental changes, then by taking out what seemed to be a mathematically irrelevant feature. (See source code: All three versions are still there.) Quick tests make it seem that Janssen's version produces marginally but significantly higher harvests than either of my versions. Is this right? Is it just a sampling problem? The behaviors should be identical.

There's a subak, kind of lower middle right on the right end of a plus sign or equilateral triangle that's connected above and below to other stuff. It's turtle number 164 in the run I'm looking at--not sure if it always gets that number.

It's displayed as connected to two other subaks, to its left and lower-left, but it behaves as if it's isolated. It always takes its own values, and doesn't appear to participate when a cropping pattern is sweeping through the group.

If you set the model to show subak's cropping plans using colors, most but not all of them turn black. If you make them all black, are the yields worse?

More specifically, nearly all but not all of the black subaks have cropping plan 0 and start month 0. If you set every subak to this pattern, is the yield worse than the usual outcome, in which there are a few subaks here and there with alternative patterns?

At present I collect pre-binned avgharvestha and mean relig-type for each year. Consider just storing the raw values--not binned. I can still plot them binned in the UI, and then can bin them later during analysis. Note that lattice graphics' histogram in R assumes that the data is not binned.

60,000 ticks of data is only 5000 years, i.e. 5000 data points. That's not so much to store during a run.

Even when you upgrade NetLogo

At least the mean and stddev or variance of harvest since burn-in. Maybe something more detailed like a distribution across bins.

Not required, but consistent organization is easier to understand.

data should be a link to a place to write data, but if the link doesn't exist, make a new directory. This can be done with https://github.com/cstaelin/Pathdir-Extension.

Or copy from farther away?

Beginning with the second run after loading the model, the Waterstress plot seems to go at about half speed relative to the other two plots. i.e. when they're at timestep (year) 20, Waterstress is at about 10.

But if I use only one cropplan, then the waterstress plot races ahead, going about 10x faster.

If you select a single cropplan only, and it's cropplan-a (3/0/3/0/3/0), and use a single global startmonth, the waterstress plot goes to zero. This is not what's supposed to happen. (I've tried this with a few other cropplans, the result isn't so clear, but more experimentation may be needed.)

I discovered that at some point the pestdispersal-rate slider had been changed to be extreme. The original version goes from 0.6 to 1.5, but I had it going up to 100. Crazy. This was producing a few subaks with enormous pest loads--6, 7 digits to the left of the decimal point. Now fixed.

However, I'm puzzled that the low end is 0.6, since Janssen p. 180 says that the original Lansing-Kremer model used dispersal rates between 0.18 and 0.45.

In the setup routine, there are three instances of ask subaks [...]. The first is very brief. The other two take up several lines, and both randomly choose a crop plan number and a starting month number. In both cases, the procedure cropplan is then called.

In between the two ask subaks some variables in each dam are set to calculated values.

Is there a reason for randomly initializing the cropping plans after they've been randomly initialized??

Also note that it's in the first of the two long ask subaks calls that the cropping plan colors of the subak turtles are set, which seems to mean that these colors are incorrect after the next ask subaks call.

10/2/2014 I rewrote Janssen's original growpest procedure, first by making incremental changes, then by taking out what seemed to be a mathematically irrelevant feature. (See source code: All three versions are still there.)

However, the incrementally modified version seems to have a lower average harvest (but maybe that's just sampling?), and the new, mathematically simplified version produces horrible harvest and pest behavior that's completely unlike Janssen's version. So there's something wrong with my reasoning.

(e.g. with pestgrowth-rate = 2.2, pestdispersal-rate = 30.0.)

Pest sensitivity of the three rice varieties doesn't seem to be as much of a trade-off as it should be. What happens when you vary it? Does that make the 3/1/3/1/3/1 cropplan less superior?

I think the calculation is wrong. The number displayed can't be right.

The subaks-own damneighbors var just contains a bunch of references to the containing subak. Whatever this variable is supposed to be doing, it's not doing it. Maybe it's not needed?