Page 1 of 1

Best practice to avoid data warnings?

Posted: Thu Apr 08, 2021 3:08 pm
by Travis
When our model is simulated, we're getting quite a few warnings that are data related. This is making seeing other, potentially more useful, warnings difficult. My question is, "What is the best practice for reducing these warnings?"

The warnings I'm seeing are similar to:

1."WARNING: No data found for -variableName[sub]- in the exogenous data files.
2. WARNING: No values computed for exogenous entry -variableName[sub]-.
3. WARNING: Simulation starts before first time for exogenous variable -variableName[sub]
4. WARNING: Lookup out of bounds at 1990 Below -varName- computing -"varName2"-.

So some of these are read in from VDF files. Some originate in Excel. Some are lookup tables. I acknowledge that means there could be four different solutions.

My hunch is that :NA: should be used to explicitly indicate that there is no data but this is not an error. I don't see on the help page for :NA: that this is the intent. If it is the intent, a pointer of how to add that to a VDF file would be great.
https://vensim.com/documentation/na.html

Thanks for the help.

Re: Best practice to avoid data warnings?

Posted: Thu Apr 08, 2021 4:50 pm
by tomfid
There isn't an explicit formalism for reading an NA in the input and therefore suppressing warnings as intentionally missing data, but that would be a useful addition.

However, there is a way to suppress these warnings with .cin files, using :NODATA and some related statements.
https://vensim.com/documentation/cin_files.html
I think these are not widely used, so we'd be interested to hear how this works out.

Re: Best practice to avoid data warnings?

Posted: Thu Apr 08, 2021 5:38 pm
by Travis
I'm inclined not to suppress warnings in development software (Vensim, compilers, etc.) since they are there for a reason. This is under the assumption that they were added to point out something that could be error prone.

In that vein, I'm not too keen on the CIN file solution. The CIN file solution is (apparently) more precise than the Ignore Warnings checkbox since it is variable-specific. I guess modelers would be need to be intentional since they have to add a variable to the CIN file.

I would like to see some formal steps that modelers could take to avoid these warnings. That way, after a dataset change, errors might be caught again. I assume the CIN file would potentially mask all future warnings/errors.

We also don't normally required a CIN file for a basic run, and this solution would require a CIN file for normal model use. I don't know how big of a deal that is, TBH, but a change in practice.

Re: Best practice to avoid data warnings?

Posted: Mon Apr 12, 2021 9:21 pm
by tomfid
Thinking further about this, I would guess that many of the warnings are of the "starts before"/"ends after" type. It might make sense to have a global way to suppress those. Requiring explicit NA in the input data doesn't seem like a great solution - it would create a lot of clutter.

What about having some higher level logic about the use of the data? For example, ignore warnings about x if it's not used. Provide a way to indicate that x is expected to be complete roughly through the present. Etc.

Re: Best practice to avoid data warnings?

Posted: Tue Apr 13, 2021 12:56 am
by Travis
We have a lot of the four types of errors in my first post above. We do have some "starts before/after", but we also have a lot of the other three types.

Stepping back and thinking about the nature of the problem is a good idea. I think this is an issue of sparse data being read into a model. The goal would be to make sure that error/warning messages are useful, so to me it is something that gets the user to declare their intent explicitly. This could be flag sort of like the "Supplemental" flag, but for data. Or it could be another time of list. But the main thing is to have data warnings become useful an catch potential errors, which we're definitely just ignoring now. ;)

Of course, if you need the model, just let me know.

Re: Best practice to avoid data warnings?

Posted: Sun May 09, 2021 9:15 pm
by rob_n
Jumping on this thread, how can we avoid errors when reading in .cin files with comments?

Vensim help says anything after a tilde (~) in a .cin file is a comment. See: https://www.vensim.com/documentation/cin_files.html This is useful to indicate the units of the constants, for example. But the tilde throws a error, like

Reading changes from file B.cin
ERROR: FILE:B.cin, line 1 : Too many values or unrecognizable value format.
Const B = 2 ~ month.
------------^.

Lines starting with ":C" work ok.

Re: Best practice to avoid data warnings?

Posted: Mon May 10, 2021 12:04 pm
by rob_n
Following up, I tested whether a "recognizable value format" would work, like Vensim code:

ERROR: FILE:B.cin, line 2 : Too many values or unrecognizable value format.
Const B = 2 ~ units ~ comment |.
------------^.

The alternative in-line comment with curly braces also throws a warning.

ERROR: FILE:B.cin, line 2 : Too many values or unrecognizable value format.
Const B = 2 {3}.

So the help file is definitely wrong.

Re: Best practice to avoid data warnings?

Posted: Mon May 10, 2021 1:35 pm
by Administrator
Do things work ok for you if they are on separate lines?

Re: Best practice to avoid data warnings?

Posted: Mon May 10, 2021 2:19 pm
by rob_n
Good thought! But unfortunately no. Viewing the model as text (so as to grab the syntax exactly), then copy and paste into a .cin file:

:C Constant file for B
Const B = 0
~ unit
~ comment
|

Running the model gives the following errors:

ERROR: FILE:B.cin, line 3 : Bad line in file, not recognized.
~ unit.
-^.
ERROR: FILE:B.cin, line 4 : Bad line in file, not recognized.
~ comment.
-^.
ERROR: FILE:B.cin, line 5 : Bad line in file, not recognized.
|.
-^.

Re: Best practice to avoid data warnings?

Posted: Wed May 12, 2021 12:08 pm
by Administrator
I'm not sure why ~ no longer works, I've added it back into the source code so it will be in the next release.

For now, the following should work.

Code: Select all

:C This is a comment
Available Operational Days in Year = 32
:C This is another comment