Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constellation checkpointing #129

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

albertNos
Copy link
Collaborator

@albertNos albertNos commented May 3, 2022

Description

  • checkpointing works with constellations simply by calling tick() but not adding returned particles again
  • simulationTime (a.k.a. iteration) passed to tick instead (before: calculated in Constellation class)
  • Change in logic which constant properties need to be written to HDF5:
    • assumption that later added particle always has higher id not consistent with current id distribution
    • -> different, less efficient handling of constantProperty Output: comparison with set of ids with already added particles
    • -> several changed function signatures necessary

Test

Test simulation with 3 constellations with checkpointing (one added before checkpoint, second is interrupted by simulation end, third is added after checkpoint)

  • consistent simulation size after checkpoint (picked up where old simulation left off)
  • after simulation end: number of particles = constantProperties entries
  • expected amount of particles, no particle added twice
  • looked fine in paraview

@albertNos albertNos requested a review from FG-TUM May 3, 2022 16:05
Comment on lines 38 to +41
* and linearly over time.
* @return std::vector<Particle> : satellites to be added to the simulation.
*/
std::vector<Particle> tick();
std::vector<Particle> tick(size_t simulationTime);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doc for new parameter missing

Comment on lines +73 to +76
// if checkpoint is loaded, throw away already inserted satellites
if (config.defines("io/hdf5/checkpoint/file")) {
tick(config.get<size_t>("io/hdf5/checkpoint/iteration", -1, true));
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add some more explanatory comments here? I don't fully get this. So if a checkpoint is used you call tick() but if no iteration of the checkpoint is defined you pass -1 which is actually 2^64 -1 because it is a size_t. In tick() we will hit the inactive case because we just initialized status. There you then cast this back to a signed long, hence the if in Line 111 may or may not be true.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I needed the startingIteration as it is in the simulation class, but instead of passing it, I copied what was assigned to startingIteration. I see now though that this is false, because the fallback value of -1 used in Simulation would be added +1 and would then be 0 (right?). I mean this snippet:

const auto startingIteration = config.defines("io/hdf5", true) ? config.get<size_t>("io/hdf5/checkpoint/iteration", -1, true) + 1 : 0;

Is there actually a case where the -1 (+1) becomes relevant? Because if a checkpoint is used, but no iteration is given, the highest iteration found in the checkpoint is always loaded right?

Copy link
Collaborator Author

@albertNos albertNos May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I casted simulationTime to long, because startTime can be negative (if insertion started before referenceTime or before the startingIteration when a checkpoint is loaded) and the negative number was then evaluated to be bigger than simulationTime since both numbers were apparently treated as size_t numbers. So the if in Line 111, when loading a checkpoint, is true if the loaded iteration is later than the scheduled start of the constellation (insertion started during simulation that produced the loaded checkpoint)

@@ -77,11 +78,13 @@ class Simulation {
* parameter!
* @param constellationCutoff range parameter for checked insertion: if the insertion would be within a distance
* of constellationCutoff to any other object the insertion is delayed instead
* @param simulationTime the current iteration
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't you rename the parameter to iteration then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to more stress that this is in the time unit of the simulation. But I think you are right iteration also makes it clear and is less confusing :D


// add ids of previous checkpoint to list of existing particle ids in order to avoid adding duplicate
// constantProperties
for (auto &id : alreadyExistingIds) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for (auto &id : alreadyExistingIds) {
for (const auto &id : alreadyExistingIds) {

Comment on lines +110 to +111
if (addedConstantPropertiesIds.find(id) == addedConstantPropertiesIds.end()) {
addedConstantPropertiesIds.insert(id);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this potentially expensive? We do this if for every particle (O(N)) and the find is in O(log(M)) where M==addedConstantPropertiesIds.size() which is >=N.
For now I would be ok with merging this but please add a comment here that this might need improvement.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is :( I can add a comment

@@ -49,10 +52,10 @@ class HDF5Writer final : public ConjuctionWriterInterface {

private:
/**
* Highest partilce ID that was written in any previous iteration.
* For anything below this ID constant particle properties are already written.
* Contains particle IDs in order to add a particles constantProperties only once.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Contains particle IDs in order to add a particles constantProperties only once.
* Set of IDs that are already written to the file.

Is this correct? Maybe rename it to writtenIDs ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is technically not true during the execution of writeParticles(), but it doesn't really matter right? Should I apply this suggestion?

@gomezzz gomezzz added the Constellations Anything related to constellations mechanics label May 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Constellations Anything related to constellations mechanics
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants