Thomas Weise (汤卫思)

A professor at Hefei University.

3 minute read

Recently, the fourth Space Optimization Competition (SpOC) organized by the Advanced Concepts Team of the European Space Agency (ESA) ended. This competition was about applying algorithms to problems from space and space . It had three challenges,

  1. a multi-route logistics problem, where the goal was to discover a set of routes forming a logistics network from Earth orbits to Moon orbits to the Moon surface,
  2. a single-route logistics problem, where the goal was to find an efficient tour that visits n satellites in the moon orbit, and
  3. a tie-breaker challenge, where the goal was to configure a set of spacecraft on certain Moon orbits to form a Morse code message by covering the moonlight.

Each of these challenges involved calculations regarding time, velocity changes, gravity, and orbits using integration of differential equations, trajectory computations, and that alike. Challenge 1 is divided into two types of problems, one (“beginner”) being strictly combinatorial and the other one additionally involving rather complex physics.

Despite having no background at all in any of these topics, we gave this challenge a go as team ScholORs_HFUU+Sunway. We did this mainly for fun and worked together remotely at three different locations, namely at Hefei University (合肥大学), at Sunway University (Malaysia, Sina Abdipoor (سینا عبدی‌پور)), and BUPT International School, Queen Mary University (Mingxuan LI (李明轩)).

To be honest, the physics behind the challenges were intractable for us. Since each of us is concurrently working on entirely different topics in our research and study areas, we also had limited time to invest into these challenges. Yet, we found them very interesting and wanted to know how far we can get with our ability to work the “ aspects” of the challenges but not the “physics aspects”. Space travel, after all, is one of the coolest things (not) on earth.

In the end, we arrived at the 9th place, which is not very good. Then again, we found feasible and not-too-bad solutions for every single challenge and problem instance. For most of the tasks, the vast majority of solutions are infeasible. Plugging the objective function into an optimization algorithm with the hope that the algorithm will sort it out and discover feasible solutions eventually is not going to work.

Surprisingly, for several of the challenges, we were the first team that found any solution. We even managed to hold rank 1 on several challenges and probably overall for several weeks, too. For participating just for fun, I think that’s not bad.

Screenshot of the final result of the SpOC 5 challenge, which came out on July 1st, 2026.
Screenshot of the final result of the SpOC 4 challenge taken from https://github.com/esa/SpOC4/discussions/13, which came out on July 1st, 2026.
Screenshot of the intermediate placements of our ScholORs_HFUU+Sunway team on May 2nd, 2026.
Screenshot of the intermediate placements of our ScholORs_HFUU+Sunway team on May 2nd, 2026.

For most of the tasks, we used simple like and with some special encodings and preprocessing. The reason is that the objective function (FEs) evaluations here were very costly, often involving integration of differential equation or otherwise “simulating” trajectories. Without better Maths and Physics understanding, there was no way around paying this cost — and this probably was one of the factors limiting our success. Anyway, if only few FEs can be done, then it is best to spend them on strict local search. Combining this approach with some preprocessing, we could find a feasible solution within only 187 seconds for the largest instance of the second challenge on an off-the-shelf laptop computer, for example. We describe our methods for three of the four problem types in two short papers:

  • Mingxuan LI (李明轩), Thomas Weise (汤卫思), Sina Abdipoor (سینا عبدی‌پور), Jourdan D'orville, Say Leng Goh, and Razali Yaakob: Integrative Hybrid Local Search with Luby's Restart Strategy for University Course Timetabling with Student Sectioning. 15th Conference on the Practice and Theory of Automated Timetabling (PATAT'2026), August 25-28, 2026, University of Nottingham, UK. Accepted for Publication.
    , , , , more infos.
  • Thomas Weise (汤卫思), Sina Abdipoor (سینا عبدی‌پور), Mingxuan LI (李明轩), and Zhize WU (吴志泽): Solving the SpOC 4 Challenge 2 with a Multi-Step Permutation Encoding for the Keplerian Traveling Salesperson. Genetic and Evolutionary Computation Conference (GECCO'2026) Companion, July 13-17, 2026, San José, Costa Rica, pages 33–34. New York, NY, USA: ACM.
    , , , , more infos.

We enjoyed participating in this challenge very much. Despite not understanding (and not having the spare time to really dig into) the astrophysics governing them, we solved all challenges. This shows how versatile skills in optimization, operations research, and metaheuristic optimization are. If you study this topic, you will be able to work in almost any field of research, engineering, or management and make valuable contributions, which will get better and better the more you understand about your field…

You May Also Enjoy

Limiting the Memory and CPU Cores of a Command

3 minute read

Sometimes we want to execute a command or program that may use too many CPU cores or too much memory and thus potentially crash our system. Instead of waiting for this to happen, we can also limit the number of CPU cores as well as the memory that a process can use/allocate. If the program can smoothly run within such limits, it will complete normally. If it tries to allocate more memory than what we permit, it will most likely simply crash. If we have 8 logical CPU cores, but we permit the program to only use 4, then it can also never happen that the computer becomes too slow because of the computational load. Regardless what happens, our computer will remain fully usable.

Finding Non-ASCII Characters in Text Documents

1 minute read

Sometimes we want to find whether a text documents contains only ASCII characters or whether there is some non-ASCII character in it. You see, ASCII is an old 7 bit-based encoding for text. Hence, it supports a very limited range of different characters and certainly not fancy stuff like “ä” let alone “你好”. Most tools today can understand the Unicode character set encoded with UTF-8, which is more or less compatible to that and can store all such characters. Some software, however, still takes offense if characters appear that are outside the ASCII range, e.g., in names of functions in some programming languages. Other software can deal with Unicode well, but dislikes only certain characters in certain places. If we have some strange LaTeX error when compiling a paper draft, sometimes it can help to check whether we accidentally had maybe a “。” instead of a “.” slip in somewhere.