Alts Toolkit/EMGAATS: When upsizing a pipe that's also a stop pipe, some map workspaces cannot be produced

[GoogleCodeExporter]

Ruben was trying to map basement flooding results for a deployed
alternative.  One of the pipes that he changed happened to be a stop pipe
for the model.  The Alts Toolkit appears to be changing any pipe's MLinkID
to 0 if it gets modified.

EMGAATS has an issue with this when trying to map basement flooding results
because it uses those stop pipes to produce certain objects for display
(namely, locations where input flows should be coming into the model).

Current workaround is to modify the deployed alternative's stop links'
MLinkIDs that changed to zero back to the original MLinkID.

Possible Solutions:

Complex: change Alts Toolkit so that it doesn't change the MLinkID to zero
if it's a simple attribute change

Complex: change EMGAATS so that it ignores this issue if it pops up

If it's a fundamental philosophy of the Alts Toolkit to zero out the
MLinkID for any pipes that change an attribute for the alternative, then
this bug should switch over to EMGAATS.

Original issue reported on code.google.com by ArnelMan...@gmail.com on 24 Nov 2009 at 11:05

[GoogleCodeExporter]

Original comment by ArnelMan...@gmail.com on 24 Nov 2009 at 11:06

• Added labels: ALTERNATIVESTOOLKIT
• Removed labels: ALTERNATIVETOOLKIT

[GoogleCodeExporter]

Update to previously-stated workaround:

A more complete workaround is to remove any MLinkID, from the model .ini file, 
that was 
modified using the Alternatives Toolkit.

We tried to change the deployed model stop link's MLinkID back to the original 
(from 0) 
and then we also tried changing all modified links that were in the original 
.ini file 
(either start or stop pipes) back to the original MLinkID - to no avail.

In using this workaround, EMGAATS should create the model results map 
correctly, and at 
the proper scale.

Original comment by j.ruben.gonzalez.baird@gmail.com on 24 Nov 2009 at 11:26

[GoogleCodeExporter]

Albert and I discussed a work-around and wanted to present it to the group.  
The 
proposal is to provide the solution through the MapInfo template, rather than 
provide 
a solution through EMGAATS code.

The most likely solution would be for us to create dummy nodes that would act 
as the 
start/stop nodes and allow the MapInfo query to complete successfully in the 
case 
that there are no available start/stop nodes due to changes in the Alts Toolkit.

We are still investigating to find precisely what it is we need to do in order 
to 
resolve this issue. For now we want to get a general consensus on whether the 
group 
thinks the MapInfo template solution is advisable.

Original comment by j.ruben.gonzalez.baird@gmail.com on 4 Dec 2009 at 6:53

[GoogleCodeExporter]

Because we will be revamping EMGAATS to .NET, changes in EMGAATS at the moment 
will
likely be only for serious production-type bugs.  Because the MapInfo template
solution uses a more "plug-in" and flexible method, I would tend to go in that
direction.  And well, it's less effort on my part.

Original comment by ArnelMan...@gmail.com on 4 Dec 2009 at 7:02