travelmodellinggroup / xtmf Goto Github PK

Perhaps update the bevaiour of clone model system on the projects page into a more standard copy / paste behaviour. Only when you paste back into a project should you be asked for what the new name should be (and perhaps have a default suffix already filled in).

One of the most lacking features of XTMF is the extensibility of the graphical user interface. Looking at issue #13 we have an instance of somewhere that could really be enhanced with a new dialog that could understand a multi-run file without forcing that knowledge into the XTMF core or graphical interface.

In XTMF.GUI if you edit a model system and try to close it you will be prompted by a dialog to see if you want to save. If you select cancel, you will no longer be able to close the dialog and it will be disabled in the menu.

Currently you can only import a model system that has already been imported into XTMF already. Often people only wish to import a model system directly into a project, making this a two step process. We can circumvent this use-case by modifying the Import UX to have an option to instead import from file.

Currently when you go to Open Project a new window is created. In extended use cases which open multiple projects people end up with multiple tabs for open project and it clutters the tab space.

To correct this, if a Open Project page already exists it should just be moved into focus.

When attempting to paste modules (specifically any file output modules - DirectorySeparatedPath, etc.), the program crashes.

Add drag and drop functionality for module reordering as an alternative to the keyboard shortcuts already present.

A project will fail to load if a used module has its submodule changed from a singular to an array of submodules.

Currently users need to type in a specific string for their parameters if the type is an enumeration. This could be far more user friendly if an alternative input was used for these specific cases.

If two "Projects" pages are opened then the first page will no longer be able to search through its contents.

In a project, I attempted to delete a model system (both through the delete key and through the context menu), but the model system element does not disappear. Attempting to open the still-visible model system brings up an entirely different model system (I'm not sure what the pattern is for which comes up). I worry that repeated attempts to delete the single undeletable model system will cause others to be deleted. Once the project is closed and reopened, the model system is no longer visible.

Add the ability to redirect a previous module name to a new module name using a new attribute tag at the code level of the new module. This will help with fixing spelling mistakes and moving modules between different DLLs without breaking older model systems.

Add the ability to run a model system from the graphical interface.

If a linked parameter (in the linked parameter pop-up box) contains no value, then assigning any parameter to that linked parameter will not save.

After enough tabs are opened in XTMF, they start to disappear. Although they are all still listed in the drop down menu on the side, there is no visual indication that a tab has disappeared, resulting in potential confusion about the seemingly lost tab. Would be nice to have some intuitive visual sign that there are additional hidden tabs.

Also, at some point tabs start opening on the left rather than the right. Would also be good to have consistency on this.

Add the ability to save model systems back to the disk.

In the estimation framework a parameter will not be properly assigned if a non-in-list module has had it's name changed. The model system will currently throw an error that the path could not be found but this should work in any case.

After saving a change to the model system, and returning to the project page, I am unable to clone that changed model system. The error I receive states that the model system does not exist in the project.

For XTMF 1.4 we should look at implementing a stronger cancellation interface for XTMF modules. At the moment only certain module interfaces expose an "exit request" function. I propose adding an ICancellableModule interface to allow fine tuned control around exiting / cancelling running modules while a run is active.

In some rare circumstances, modules that rely on IO or other conditions external to XTMF can prevent run completion, or worse -- completely prevent a run from being able to be cancelled at all.

Another addition that might be useful is adding a timeout interface on modules that should be expected to complete in reasonable time - or those that might be prone to problems related to problems outside the control of XTMF (e.g. Emme).

Currently we can create a meta-module for a single module and it's children. The next step would be to allow the creation of a meta-module that contains a whole collection of modules.

Ensure that all RootModule, ParentModule, and parameters are publicly available fields as per the XTMF specification to help reduce bugs in modules.

As quick parameters are designed to be easy to change without digging through the model system, they should be immediately visible when opening ms. Also this way new xtmf users become immediately familiar with their functionality.

XTMF should be refactored to separate nondependent module code (GTAModel etc.) from the XTMF core functionality for both simplification and overall design purposes. This possibly involves introducing a new repository for the changes to place modules.

I am a big fan of the disabling modules feature; however I sometimes forget whether my current ms has disabled modules or not, and have to dig through to check. It would be great to have some indicator, either in the root module, or some other visible area, that the model system contains disabled modules, as a warning to the user. Probably would be best if the number of disabled modules was indicated as well.

Adding an expand all button (maybe when right clicking) so that it is is easy to see all the modules

Right now a single dark blue theme is used. Providing the user with different customization options would improve the user experience.

You will not be able to close a model system editing window if you have previously selected to close it but canceled after it informs you that you have not saved.

If you do this the children are not properly destroyed in the GUI.

I just had a problem in which the XTMF could not find the toolbox while it was running, and instead of raising any caution (or error), it kept on running without any suggestion that something was broken aside from the lengthy run time. I only stumbled onto the fact that I hadn't loaded in a toolbox once I tried to go do it manually.

Not sure if this can be fixed, but a small message box would be very helpful.

If you delete a linked parameter in the GUI an unrelated linked parameter gets removed from the interface. If you try to delete the linked parameter again it will inform you that it doesn't exist. Reloading the Linked Parameter window will show that it is no longer there.

I accidentally deleted my Zone Data module and then "undid" it by pressing control-z. The module was recovered and everything seemed fine, even the parameters themselves. I tried to run the model system, and it failed saying that it couldn't find a parameter from my Zone Data module. I went to look at it, and I couldn't find the problem because all of the parameters were correct. The problem kept on going until I closed XTMF and re-opened it. It is at that point that I saw that the Zone Data Module had "recovered" to all of it's default values - and hence wrong parameters.

The arrows for expanded modules are currently a dark grey and hard to see. This should be modified to be white like the initial state so it stands out from the background.

Currently Previous Runs are ordered alphabetically. When searching for the most recent run, it would be easier to find it if these runs were ordered by the date and time they were run instead.

This may be more of a discussion than a request. I have noticed that if you have more than one XTMF, and you open one and change the project settings, they are automatically modified for all other XTMFs. Myabe it is better to have different settings for each XTMF? For example, one may have multiple versions of XTMF on one's computer, in case one has to rerun old projects and wants consistent results. In this scenario, it would be good to keep the projects of each version in separate directories, in order to ensure that the correct project is always run with the correct version, and there are no modifications made to the model system due to lack of backwards compatibility (missing modules, wrong number of parameters, etc). Thoughts?

Currently text in the XTMF GUI is done with hard coded strings. There is no reason that this could not be improved to properly support multiple languages.

Currently model runs are being executed within the current XTMF process. This can lead to issues with static variables and other resource allocation not being cleaned up between runs. Putting each run in its own process avoids this issue. It can also allow us to be smarter about NUMA systems and run multiple model systems at the same time on different CPU groups.

Currently when you right-click on a Previous run you load the model system. This behaviour should be modified to instead bring up a context menu, one option of which would be to open the run's output directory.

The Export Boardings TMGToolbox tool contains an option to individually write routes that are not found in an aggregation file (this is the default state if there is no aggregation file). However, this option is not included in the XTMF call function. I would suggest adding it to the call function and to XTMF.
I've encountered many situations where an out-of-date aggregation file has been used unknowingly because there is no indication that any lines have been ignored; I would prefer the option to fully capture every line's boardings in some way each and every run.

We have been requested to look into creating a system that would allow multiple model system runs to be scheduled and executed in order.

Although I think the multi-run capability in XTMF is very much an incredibly useful feature, one problem that I have with it is that, when running a lot of runs, the "Batch File" gets too large and very confusing to read in its current format. More importantly, it becomes somewhat difficult to read through the paths when doing a QA before I launch a run. A more readable format would most definitely be welcomed.

Add the ability to save the projects back to disk.

XTMF should provide the option to log error information to file.

A link should be provided in the about box in order to properly comply with the license and to help promote open source software.

Hi,

Very nice that the Toronto efforts are now available.

Was trying to compile it on mac. Am no C# expert, so I may be getting everything completely wrong. I installed Xamarin, and it seems to make halfway sense out of the code. But I have consistent problems with expressions of type
if((var oldType = RealModelSystemStructure.Type) != value)
; it is ok with
var oldType = RealModelSystemStructure.Type ;
if( oldType != value)
Presumably, my compiler is just not modern enough, but I don't think there is anything I can do about it. Any chance to convince you to stay at compiler levels that are available across many platforms?

(It looks like there will be additional problems beyond the above one, but I thought I could still ask.)

Thank you and best regards

Kai Nagel, TU Berlin

Give the ability to group modules in a list through XTMF for better visual representation.

Currently model systems can be compared when they are copied out in text form. This will flag inconsequential differences, such as module index changes, making it difficult to sift through and determine what actual changes have been made to the model system. It would be especially useful for troubleshooting run results to have a way of easily obtaining a list of changes to both model system structure, as well as parameter values.

Currently meta-modules hide parameters by changing the text from white to grey. Would be helpful to have the parameters disappear from view fully to make meta-modules more compact.

It would be very helpful to have the ability to disable (grey out) a specific module from running. This way, I do not have to delete and re-add modules every time I want to run a specific model system.

When assigning (or removing) a linked parameter to a parameter while in quick parameters view, the link icon does not change as it should.

I have attempted to run Full Network Set Generator via XTMF with a .nup file assigned to one time period. I was able to set this up in Modeller, but the XTMF side is failing:

EMME Parameter Error: The module "tmg.network_editing.full_network_set_generator" was executed with the wrong number of arguments or of invalid types.
at TMG.Emme.ModellerController.WaitForEmmeResponce(String& returnValue, Action1 updateProgress) in C:\Documents\GITXTMF\Code\TMG.Emme\ModellerController.cs:line 274 at TMG.Emme.ModellerController.Run(String macroName, String arguments, Action1 progressUpdate, String& returnValue) in C:\Documents\GITXTMF\Code\TMG.Emme\ModellerController.cs:line 365
at TMG.Emme.ModellerController.Run(String macroName, String arguments) in C:\Documents\GITXTMF\Code\TMG.Emme\ModellerController.cs:line 338
at TMG.Emme.ExecuteToolsFromModellerResource.Start() in C:\Documents\GITXTMF\Code\TMG.Emme\ExecuteToolsFromModellerResource.cs:line 43
at Tasha.Utilities.BasicTravelDemandModel.Start() in C:\Documents\GITXTMF\Tasha\Utilities\BasicTravelDemandModel.cs:line 83
at XTMF.XTMFRun.OurRun() in C:\Documents\GITXTMF\Code\XTMF1.1\XTMFRun.cs:line 334

One possibility: the code does not like that I put a .nup file in only one of the time periods.

I've attached the model system I used.

NetworkGenSnippet08-22.txt