Custom Code fails to execute (or respond)

[Former user]

Custom code prepared for 8.3.2 fails to provide values for links in 8.4.1.

Attached zip file contains model and custom code.

[e-mail]

[Bob Lounsbury]

Hello smacey,

Unfortunately you have not given me enough information to assist here. First, we need to clarify the issue, the issue title seems to indicate that you are unable to run a custom code executable you have created? But then the issue description says the custom code is not providing the expected solution?

Are these two separate issues?

Your custom code executable successfully ran on my machine. My first reaction or question for you is, Do you have the MODSIM dll's in the same folder as your custom code executable? You need to have libsim.dll, ModsimModel.dll, NetworkUtils.dll, A2CM.dll, and XYFile.dll in the same directory as your Equus-Losses_v2.exe.

[Scott Macey]

Specifically, I am looking for losses or gains from an aquifer to a river, represented by links 40-45. I get all zeros for these links when I run the model in 8.4.1.

[Scott Macey]

And yes the necessary files are present.

[Bob Lounsbury]

Right, that would have been a better description for this issue, saying it fails to provide values for links is very nondescript for me to help you debug what may be causing a problem since I don't even know where the problem is.

Looking at the network in the GUI all those links except for 41 (which has a flow of 1 when I run the model) have a max rate of 0??? Is your custom code altering this constraint? If not, then that's the solution I would expect.

[Bob Lounsbury]

FYI, when I run the network with 8.3.2 there is no flow in those links either.

[Bob Lounsbury]

Your model runs in 20 seconds in 8.4.1 instead of 60 seconds as in 8.3.2, that's a nice 66.67% decrease in runtime :)

Of course we need to make sure the solution is correct.

[Scott Macey]

I get the expected values on these links when running 8.3.2, even with those links set at max zero, because the code writes to the database after the network arrives at a solution. I will try your suggestion nonetheless. I am thinking this is a .net connectivity issue, and I am hoping we can find an expert in that topic.

[Scott Macey]

Experimenting at another pc, I am successful with the custom code in 8.4.1.

Another user has the 3.5 .net installed, and runs the model with no error messages, while getting erroneous results. I will suggest the 32 bit office fix from the wiki.

I have no office installed, and was successful nonetheless, after installing the database engine.

Thank you for looking at this. Although I think you could consider this issue closed, it might be good to warn users of custom code to look out for this.

[Bob Lounsbury]

This is a really tough issue, there's a lot going on in the model and with your custom code. Also, I don't fully understand the basin and what you're trying to do. It's certainly possible there was a bug in 8.3.2 that was fixed in 8.4.0 or 8.4.1 that changes the solution. Those changes and fixes are described in the release notes here: http://modsim.engr.colostate.edu/modsim.php.

I decompiled your exe to try and see what your custom code is doing. It seems strange to me to have your SetFlowRate calls inside of OnIterationConverge/ConvergedDelegate because at that point the solution is finished, if you set the flow, wouldn't you need to do more interating because the flow affects storage and the flow affects the flow throughout the network. Maybe it would make more sense to put SetFlowRate inside of OnIterationBottom and allow Modsim to iteratively solve as intended.

Anyway, if you're getting unexpected results we should figure it out. I might need your custom code project to really step through the solution in a debugger. Or if you can reproduce the issue without custom code that would be really really beneficial.

We state in the release notes and on the download page that Microsoft Office is required for MODSIM to produce Access Database output or as you mentioned the database engine will work as well. That's the case for MODSIM itself or custom code, if you have a good idea of where else to better inform users, please let us know.

I'm going to mark this issue as Invalid at this point, as we have no way to prove that it is a MODSIM issue currently. If you come up with other tests/examples that demonstrate incorrect solutions, we can reopen this issue or you can create a new one. Thanks.

[Bob Lounsbury]

This could be a MODSIM issue, but given the information it can't be confirmed at this point. So there's nothing I can do to resolve it.

[Scott Macey]

I can identify two separate issues:

First, a machine with all the prerequisite components fails to generate any values for the links which are modified by custom code. The model runs very quickly, and therefore I believe the subroutines are not being called. The links' results match the set capacities. This topic is not one I really care to pursue, as it's an IT problem.

Second, the links are performing correctly for one condition, which is when the aquifer provides flow to the rivers, are therefore the Gains are zero. When the reverse is true, the gains links should be populated from the elevation/flow tables in the code, and losses should be zero. It is in this condition that the code fails to provide the logical results, even though it works fine in 8.3.2.

I will develop some demonstrative data and share it with you in the next couple of weeks. In the meantime, I will also try your decompiler idea.

Thanks for looking at this.

[Bob Lounsbury]

I've continued to investigate various possibilities with little success. But, I just I had a breakthrough, and I think we might have a MODSIM bug on our hands. I ran your model in 8.3.2 and 8.4.1 with simple custom code. For my simple test I set the max rate for EquusToLArkRAtHalsteadLoss to 100 and then reset it in custom code in the same way your custom code does using link.m.maxConstant. In this simple test link.m.maxConstant has no affect in 8.4.1 but works in 8.3.2. Now I have something I can look into within MODSIM. I'll let you know how it goes.

Just an FYI, the model runs very quickly in 8.4.1 because we significantly decreased runtimes within MODSIM code in the 8.4.0 release. So, I think your custom code is being executed, MODSIM is simply that much faster now due to some changes we made.

[Bob Lounsbury]

Confirmed this is an issue within MODSIM. Re-opening to further discussion and resolution.

[Bob Lounsbury]

Bug fix - Closes #17, MODSIM was filling link timeseries data when the data did not vary by year. This made the variable link.m.maxConstant invalid for use in custom code.

→ <<cset febf62967c57>>

[Bob Lounsbury]

Well this fix seems to correct the issue, though the model results are a bit different from 8.3.2.

[Bob Lounsbury]

ref #17, the last fix was not quite right, it set a max rate that did not follow unit conversions and it caused other models to fail with infeasible solutions. This corrects it.

→ <<cset 6fb9ff313e43>>