Attempt at a dual bound iterative deepening solver

[Dadams2]

Hi all,

I have really enjoyed using didp for the past little while and have tried to write a little dual bound heuristic solver. I do not expect this PR to be merged but instead exist more so as a thank you for creating such a great piece of software. That being said if this is of interest, I am very happy to bring it into main.

The intention of this solver was to be more memory efficient than weighted A* (theoretically linear space complexity) whilst maintaining speed and solution quality. Because I come from the planning community I wrote a little grid navigation benchmark:

I'm pretty sure this isn't the style of problem dip is supposed to solve but, it was helpful for my understanding.

I elected to use the python interface for testing (to understand the codebase better) so as you can imagine accurate memory benchmarks are a real pain. So please take the following with a grain of salt:

I believe the reason we are seeing worse memory usage is registry.clear()always keeps the current allocated capacity. This means we are held prisoner by the maximum number of nodes stored at any point in an iteration despite only needing to store the current search path. I will fix it in the future.

If you have some time to spare I would appreciate your feedback on if I have missed opportunities to reuse parts of existing heuristic search infrastructure, made poor assumptions or made mistakes. I am not the best rust developer, so am always open to suggestions on my code.

Thank you!

[chyr98]

Hi,

Thank you for using DIDP and bringing the point of view from the planning community. We also had implemented a iterative deepening a-star search algorithm, but it did not perform well on the OR problems we tested with. We are implementing another rust interface for DIDP: RPID, and we will include IDA-star in the RPID shortly.

May I ask which tool did you use for the memory usage monitoring, because I would like to see if the same memory usage behavior happens on my IDA-star algorithm as well.

Thanks

[Dadams2]

Because I was using the python interface I used process.memory_info() for my attached plots. To verify my results I used a tool called scalene which allows you to profile both python and system memory. If I were to use just for the rust part perf seems fine.

I would be curios to know what specific OR problems IDA-star struggled with.

May I ask if future algorithm development is going to shift to RPID? I have a few drafts of parallel algorithms that I intend to polish up at some point and am wondering if I should send them there instead of here at didp-rs. I also have a draft MCTS implementation I would be keen to test.

P.S if you are at NII we can discuss in person.

[Kurorororo]

May I ask if future algorithm development is going to shift to RPID? I have a few drafts of parallel algorithms that I intend to polish up at some point and am wondering if I should send them there instead of here at didp-rs. I also have a draft MCTS implementation I would be keen to test.

Yes, we are planning to use RPID as a backend of didp-rs in the near future. Most solving algorithms would be moved in RPID. We will still maintain didp-rs as a modeling framework providing declarative interfaces in Rust, Python, and YAML.

P.S if you are at NII we can discuss in person.

Are you at NII? I am working at NII, but I am away for a month. If you are there in December, we can talk in person.

Ryo

[chyr98]

I would be curios to know what specific OR problems IDA-star struggled with.

I used the OR benchmark in the DIDP paper, which contains almost 8000 instances from 11 problem classes.

@Kurorororo Do we have a public git repo of the or-baseline?

P.S I am at University of Toronto, so probably won't be able to join your in-person discussion.

Thanks,

Jasper

[Kurorororo]

I would be curios to know what specific OR problems IDA-star struggled with.

I used the OR benchmark in the DIDP paper, which contains almost 8000 instances from 11 problem classes.

@Kurorororo Do we have a public git repo of the or-baseline?

Here is the repository using DIDPPy and YAML-DyPDL: https://github.com/Kurorororo/didp-models
We also have the repository for Rust and RPID: https://github.com/Kurorororo/didp-rust-models

[Dadams2]

Thank you for linking the datasets, I will profile these with my current framework for fun just to see what the results are. If anything interesting comes up I will post here.

Given the direction is using rust as the interface to didp I may need to think about how to do proper memory profiling in rust.

I am currently at NII and will be there in December. Happy to hop on a call anytime.

[Dadams2]

I have had a preliminary look at some of the orlibrary problems. Perhaps I am mistaken as to which instances in the didp-models repository are directly from orlibrary but so far it seems only the MDKP readme directly mentions it so that is what I have investigated.

With the default settings of 8gb memory limit and 300 seconds timeout on the first 30 instances of MDKP (splitting one files as I had to write a utility to split them).

the results for cabs is as follows:

The results for my IDA* implementation are as follows:

It would appear my results agree with your findings of IDA* not working well for these problems. We save memory but have terrible solution quality in the earlier instances.

Perhaps there are alternative configurations/modifications to be made.

Thank you for the feedback on this PR, I think its probably time to close it as I don't think this algorithm belongs here anymore. Happy to have further discussion though.