Scenario Unreadable & Reporting Issue

[ryan-ambrose-gc]

Ran into an odd scenario "corrupting" issue today. Unfortunately, I'm not sure what specific action caused the issue as many things were altered before the issue was discovered.

After modifying the scenario (adding sheets, linking parts, writing functions...again cannot narrow down the cause) I was able to run the simulation normally through the main simulation control (simulation run until wall time, no errors reported). Upon starting a batch run, it would end immediately with the error:

origame.scenario.defn_parts.part_link.LinkIfxLevelsTooLowError: Link source '/Initialization/Parameters/SetNode' (ID 45) FRAME not linkable to '/hub' (ID 134) FRAME (At least one link frame has insufficient interface level: source level=1 should be >= 2)'

which is odd as the SetNode entity is not linked to the hub entity (in fact, entirely different interfaces...should be no way of them to link). I then saved the scenario (fatal mistake), which did not raise any errors. Now the scenario will not open citing the same error. My attempted fixes are below, all required digging through the .ORI file:

1) Change the ifx_level of "SetNode" to 2. I encounter an assertion error (with a wall of a stack trace).

2) Remove "SetNode" entity (and all references to it). Error window with just the key vale of SetNode (I.E. error window just reporting 45)

3) Remove "SetNode" entity but placing in a "dummy" entity under key 45. Error window expecting "name" under outgoing_links (note, this error is persistent across all entity types)

4) Add "hub" to outgoing links of "SetNode" manually. Assertion error, wall of stack trace.

I will just revert the scenario to an earlier commit point and manually integrate my changes...but that's a non-ideal solution. I can upload the "corrupted" version if people are interested to try and pinpoint the cause/solution.

[ryan-ambrose-gc]

Also, this issue is persistent across both 2017 and 2023 versions of Origame

[stan-isbrandt]

It may be that the problem is corruption of the ORIGAME scenario file that happens to influence only the batch code, rather than an explicit error within ORIGAME. I have often run batch scenarios and typically if they fail, it's possible to figure out what went wrong. However, it is also the case that the ORIGAME environment is complex - substantial ORIGAME code is written in python, various modules can be used within a scenario, and all running in the PyQt GUI environment in MS Windows. Amongst other things, I suspect that sometime Windows gets things twisted around in an odd way. I once had a situation where closing down a scenario, reverting to a previous version that used to work, and having it fail as well - and got it working again by shutting down windows and starting fresh again. Complex environments can be problematic - I used Arena for several years and had several instances where I had models that would run well, but after saving and re-loading I would only get a corrupted file error.

One of the most common ways that my ORIGAME scenarios would have problems was when they used Matplotlib intensively. When I had a problem with these scenarios I learned to (1) try to figure out what was wrong, and (2) exit my working scenario, reload the original scenario, and try to fix the problem then (as opposed to trying to fix the scenario immediately when the error was found).

If your scenario is a large .ori file and you want to examine the code, you might try saving your scenario as an .orib file. It is smaller, being more compressed, and it may be easier to sift through your code. I also find that saving scenarios as orib files, and running them as .orib files, works just as well as using *.ori files. Also if you are saving scenarios with lots of code and data, the file size can be much smaller.