tentative fix to ALL exit bug

[amartyads]

Description

Simulation now exits gracefully when ALL update frequency < number of simsteps

Resolved Issues

• fixes ALL + AutoPas exit error when ALL updateFrequency < total number of sim steps #244

How Has This Been Tested?

Same test case as outlined in issue

[FG-TUM]

Just a comment: I find it a bit unintuitive to pass the number of timesteps to the constructor because why should the decomposition actually care about that info (yes for the ALL bugfix but actually it shouldn't). The other way to get to the information of the number of timesteps would be by querying the xmlconfig during the readXML() step. However, I suppose then you would miss the number of steps when it is passed via the command line. For this you could query global_simulation->getNumTimesteps(). On the other hand, accessing the singleton is always an ugly workaround, but already widely used throughout ls1. So maybe an ok-ish solution in readXML() could be

1. check if global_simulation != nullptr and query that if available
2. otherwise query xmlconfig.

In the end, I feel all of the options are ugly in their own way, so decide for yourself what you prefer.

[cniethammer]

I agree with@FG-TUM that the domain decomposition should not require the number of time steps to simulate. Note also that ls1 could be run using a time limit instead a fixed number of steps.
I did not follow the details of the problem with ALL(?) and Autopas here but would think that there should be more solutions.
However, if no other solution is there, for me using the singleton seems like the way to go. Reading other parts of the xml that are not part of the <decomposition> tags in my opinion as duplicates I/O logic that is error prone and hence a bad thing IMHO.

[amartyads]

I agree that all workarounds are ugly. I personally wanted to avoid accessing the singleton since I'd like to be able to phase out its use in the future. I'll take a look at the initialization procedure for the ALL object and see if I can fix it in a more logical way, however that will take some time.

[FG-TUM]

Note also that ls1 could be run using a time limit instead a fixed number of steps.

@cniethammer Does that feature (still) exist? It is not mentioned in all-options.xml. How does it work?

[cniethammer]

Note also that ls1 could be run using a time limit instead a fixed number of steps.

@cniethammer Does that feature (still) exist? It is not mentioned in all-options.xml. How does it work?

From a quick look into the source I see that, e.g., the --timed-checkpoint is still present that was used for PBS/Slum jobs with limited runtime in the past.

[amartyads]

@FG-TUM I've added some more details to the issue #244 , since I discovered the root cause and it made more sense to put it there

[FG-TUM]

These changes do not fix the actual bug -> closing