Ventana software support forum

Right ... it's (775,000-433,000) people/year for 1/8 year in the first time step, so the expected change is 43,000 - which is what you get.

With Euler integration:

stock(t+dt) = stock(t) + (inflow-outflow)*dt

with units

people = people + (people/year)*year

where dt = time step = .0125

There may be a bug in SHIFT IF TRUE in your version - I get the expected decrease of about 500/yr when I run with 6.3. Time for a maintenance extension - 5.0 is ten years old!

Here's a model with a checksum that is what I'd expect from your description. There are slight numerical discrepancies - about .01% - presumably due to roundoff. Nothing like what you're describing. As an extra check, the final population should be 172.5M when you run this.

See http://vensim.com/vensim-6-3-released/ for details & downloads.

I think the error persists because "error" is in some of the subscript definition fields. How it got there in the first place appears to be a bug in the Add Subscripts menu command. However, the bug only occurs when subscripts are added to a particularly anomalous model, like the original ...

Right - there's a sample model in the help system that illustrates this. http://www.vensim.com/documentation/fn_pulse_train.htm

Try starting from this:

I can replicate the varformat error. But it seems that the original model is not in a working state, prior to attempting to add the subscript. Many of the variables are defined as data, and therefore are missing their equations.

Also, is this a venapp, or just a model? If the latter, the first places I'd look would be (a) the simulation control dialog (Model>Simulate menu), Changes tab, Based On field, (b) simulation control Advanced tab, Data Sources field, and (c) the filename passed in GET VDF functions in the equations,...

BTW, what's your interest here? Migrating a few big models? Browsing models across platforms? ... ? (We're curious because it affects how we prioritize different aspects of the implementation.)

Not yet. We do plan to support it at some point, but we've been too busy working on new tools.

The general strategy here is to plug in the parameters reported as causing the error, and run an ordinary simulation to see what the error is.

See http://www.vensim.com/documentation/usr16.htm or http://www.vensim.com/documentation/fn_get_xls_data.htm

If that's not it, I think I'd have to see an example.

No - but one thing to check is whether you inadvertently exited without saving your analysis toolbar settings - you may be back to "Selected Vars" on the graph tool.

This can be done with VECTOR LOOKUP - http://www.vensim.com/documentation/fn_ ... lookup.htm

I think this may be a bug - we'll have to investigate - but I think something goes wrong when the "Selected Vars" option is checked in the graph tool. Try right-clicking your graph tool in the analysis toolbar and unchecking that setting (near bottom left).

One strategy to think about, somewhat common in electric power modeling, would be to simulate only representative times per day or days per month/season. You could also potentially move some of the hourly detail off the time axis and into an array dimension, if serial correlation isn't a big deal.

Are you actually developing a model with graphs on the diagrams, using the Input/Output object with a workbench variable? (If so, I think I may know what's happening.)

If you can send us a copy of the model, we might be able to track it down. We haven't changed anything in the diagramming that I'm aware of.

If your errors are normally distributed and the payoff is properly weighted according to the standard errors, the expected value of the payoff is the number of data points.

Also, check the payoff report (*.rep file) for additional diagnostic stats.

That's the right syntax. What do you mean by "not working" ?

When a model has explosive floating point errors like this, it's generally useful to re-run it for a short time (like 2014-2018 in this case) to make it easier to see what's going on. Also, if you're using an advanced version, right-click the Table tool and set it to show "Causes" rather t...

You can often transform a UNIFORM variable to the needed distribution, for example:
http://en.wikipedia.org/wiki/Fr%C3%A9ch ... tributions

I think your solution is about as good as it gets, unfortunately. Will ponder...