Thesis Workplace

REALM-Bench

2 min read

Paper: REALM-Bench.pdf
Github: https://github.com/genglongling/REALM-Bench

Doesn’t feel like a proper research

Good:

  • We have some numbers to compare our solution with. Their own solution is good (called ALAS)
    • Note: some numbers are wrong currently! their implementation on GitHub has some issues.
  • Cleaned and gathered a lot of the JSSP problems (>100)

BAD:

  • More or less, All problems are the same thing, just different size/numbers with different results
    • might not be suffient for our config variations
  • They don’t do anything to make it “multi-agent” specific, just a bunch of problems with some optimal or best-effort solutions or even no solutions sometimes..
  • No standard tools included.
  • No standard input format, meh. But they use one in there other paper about their own solver ALAS https://github.com/genglongling/M-APPLE-OS
Job Shop Scheduling Problem (JSSP) - Dataset: abz07

Problem Description:
- Number of jobs: 20
- Each job has multiple operations that must be performed in sequence
- Each operation requires a specific machine and has a duration
- Each machine can only process one operation at a time
- Goal: Find the minimum makespan (total completion time)

Job Specifications:
Job1:
  Step 1: Machine Machine2, Duration 24
  Step 2: Machine Machine3, Duration 12
  ...

REQUIRED OUTPUT FORMAT:
1. FINAL MAKESPAN: [integer value]
2. STRUCTURED SCHEDULE:
- Job: Job1, Step: 1, Machine: Machine0, Start Time: 0, End Time: 3, Duration: 3
...
Ensure all constraints are satisfied:
- Job precedence: operations within a job must be sequential
- Machine constraints: no overlapping operations on the same machine

QS:

  • How hard should things be?
    • What tools to give to the agents?
    • Also, diff arch will prefer different tools; central will like a central validator and individual agents will like something diff
  • The point is: We need a benchmark to evaluate multi-agents systems performance on planning
  • It’s more or less 2 problems styles — static and dynamic — I can feel it will not generate much variablity for solvers, probab each style will prefer only one arch all the time
  • Can be used for planning-dimension variability? Global agreements?
  • I think it was recommended because it assembles the task in the SOSEng project but it’s sufficient, I think It can be done in the end as a supplement analysis

Graph View

Backlinks