Flows, units & delays

[Jack Harich]

My, my, I thought I’d checked to see that unit checking was on. Turning it on, I saw 18 warnings. I was able to reduce these to 7, but am unable to go further due to lack of understanding.

In plain English, how would you read this warning: “Flow "set is abstain" -- flow "1/Year" * time "Year" => "1/Year" -- to stock is "dimensionless" in [G2_3 Support Decision]”

I can't see what is causing a unit conversion failure. Perhaps you could explain. I’ve examined the Ventity and Vensim doc, as well as sample Ventity model, no clues there. Thanks!

[Jack Harich]

I think the DELAY3 is fine; the flow formulation is acting like a discrete event.

Logically, it seems to me that putting a DELAY in any equation should cause a DELAY. What you say implies that's not the case if the equation is a flow. If a function is not going to work as expected, why not issue a warning?

Why, apparently, are DELAYs ignored in a flow?

What does "the flow formulation is acting like a discrete event" mean? That might help me understand this.

If you want to delay a flow, how do you do that? In my Vensim models, I see I did that with variables that feed into flows.

Thanks, Jack

[Jack Harich]

Re v40 - displays fine for me.

I think what we're seeing here is a bug that vanishes when Ventity is closed and reopened. But it's working fine now.

[tomfid]

The unit error indicates a conflict between stock and flow units. The relevant rule is flowUnit = stockUnit/timeUnit, except in actions where flows are discrete, so it's flowUnit=stockUnit.

[tomfid]

Working from memory, you have something like:

flow = if (event=1) then { value-DELAY3(target,tau) } else { 0 }

This is not a delay. The target is delayed, but the flow itself is not. If there's a value-target difference, it will flow immediately.

This is also the cause of the unit error I think. If target has the same units as the stock, the flow will too. You'd have to divide the difference by something with a time unit to make it integrate correctly. Model.Time Step can be used if you want the adjustment to happen all at once.

[Jack Harich]

Ventity continues to be a joy to use on a very hard problem, democratic backsliding. The model is evolving well. Ventity is able to simulate very complex system behavior with a bare minimum of declarative input.

But a problem persists. I worked quite a bit more on the unit check warnings. The problem pattern is I can eliminate warnings on entity type diagrams, but not on actions.

The attached model has identical structures for a test flow and stock on the Test entity type and the U Initialize Voters action. The units and equations are identical. The structure on the entity type produces no warning, while its twin on the entity type produces a warning. If I understand all this correctly, this suggests that the unit check warnings on actions are spurious. But of course, I may be missing something. Thanks!

I wrote the above before seeing your reply:

The unit error indicates a conflict between stock and flow units. The relevant rule is flowUnit = stockUnit/timeUnit, except in actions where flows are discrete, so it's flowUnit=stockUnit.

Thanks, this eliminates the unit check warnings. However, this behavior conflicts with the Ventity help doc, which says:

Note that the units of a flow should always be the same as the units of the source and destination stocks, divided by a suitable time unit. So if bank balance is in dollars, then deposits should have units of dollars/day, dollars/week, dollars/month etc.

Trying to be helpful and minimize people’s frustration and barriers to learning Ventity, there’s a feedback loop here that needs to be closed. The quality of Ventity would benefit enormously if every time you got feedback about a problem that was not covered in the doc or not covered well, you improved the doc. Related to this, I would suggest adding a troubleshooting section to the doc. If you want Ventity to catch on, then mere mortals like me need high quality documentation. Good luck here!

[Jack Harich]

I see Ventity supports empty foreign keys. But if they are empty, I get one warning for each entity. I’m getting 9 identical warnings every time I run the model, even though model output is fine:

Runtime voter.politician_supported [0] Unable to reference Entity Type [politician] from voter [voter[V1]] using Attribute [politician supported] = ""

An empty politician supported means that voter abstained in their last support decision.

What if I had 200 voters? Is there any way to suppress these warnings? I didn't see anything for this in Model Preferences.

This with Ventity 4.8. v4.9, as my email mentioned, still produces errors.

[tomfid]

I emailed you a nightly build that runs OK for me and handles many of the generated code errors.

There is no setting for reference failure suppression, but you can change the target type for the attribute from Politician to <none>. That may break the automatic paired reference, but you can recreate it if needed.

[Jack Harich]

I emailed you a nightly build that runs OK for me and handles many of the generated code errors.

v4.9 still causes errors on my model. I'm using v4.8 and doing fine. To minimize overloading you with lots of small problems, I will wait for a future version and try that.

There is no setting for reference failure suppression, but you can change the target type for the attribute from Politician to <none>.

Thanks, that did the trick. Makes perfect logical sense.

[tomfid]

Not sure what you mean by "v4.9 still causes errors". If it's simply that reference warnings are not suppressed, that's expected.