OpenWaterAnalytics
Fatal error while parsing the vertices section for link ID's, which aren't declared properly
The C code errors out and fatally ends for extra links that are not declared in the link-related sections. However, the GUI (v2.2) is able to open and run the same input file.
This is an interesting one - I dug into this a bit with @ehsan-shafiee and I'd like some feedback from others.
Should it be a fatal error for undefined links to appear in the [VERTICES] section, or for undefined nodes to appear in the [COORDINATES] section? I would think it should be ignored verbosely.
On a related note, it is not currently a fatal error to have nodes defined which do not have corresponding coordinates. In fact, this case is simply not detected and silently ignored. Is this what we should expect? I would think some kind of warning should appear somewhere...
IMO a fatal error should not be issued if a bogus object ID appears in the [COORDINATES] or [VERTICES] sections since the engine never uses coordinates in its calculations. (This might change if the WQ solver were ever updated to compute incomplete mixing at 4-way junctions with automatic detection of the orientation of the connecting links.)
Regarding warning messages, it should be up to the host app to handle cases where it can't find coordinates for its nodes since only it knows if that has significance or not (e.g., none of the examples in the Toolkit documentation requires coordinates.)
@ehsan-shafiee correctly pointed out that the GUI can open such files. This is since the GUI does not use the DLL for parsing the INP file. One of the main reasons the GUI is built in this way is that a user can save a network while working on it and it is not complete (e.g., the DLL cannot open a file without a tank or reservoir). So this is a different question if we allow loading of incomplete data and have it checked just before the run.
For this case ([VERTICES] and [COORDINATES]) I'm fine with ignoring the entries.
I corrected my previous comment by deleting the statement that the v2.2 API does not have get/set functions for vertices - the existing functions EN_getVertex and EN_setVertices serve that purpose.