Hi Weiguang,
Thanks for looking this up. This is strange. I don't have an explanation for this, I'm afraid (other than that your file of output times does contain some kind of second column information after all). In case you restart this simulation, you might want to add a print-statement in the function
void global_data_all_processes::read_outputlist(char *fname)
in file src/data/allvars.cc, right after OutputListFlag[] is assigned to see what's assigned to this variable there.
Cheers,
Volker
> On 13. Oct 2021, at 19:11, Weiguang Cui <cuiweiguang_at_gmail.com> wrote:
>
> Hi Volker,
>
> A quick looked through the log files when the code dumped snapshots:
> Here are two patches of the output from the same log file:
>
> SNAPSHOT: writing snapshot file #26 _at_ time 0.459332 ...
> SNAPSHOT: writing snapshot file: './snaps//snapdir_026/snap_m200n2048_026.0' (file 1 of 32)
> SNAPSHOT: writing snapshot block 0 (Coordinates)...
> SNAPSHOT: writing snapshot block 1 (Velocities)...
> SNAPSHOT: writing snapshot block 2 (ParticleIDs)...
> SNAPSHOT: done with writing snapshot. Took 280.296 sec, total size 262144 MB, corresponds to effective I/O rate of 935.24 MB/sec
>
> SNAPSHOT: Setting next time for snapshot file to Time_next= 0.487259 (DumpFlag=1)
> ---------------------
>
> SNAPSHOT: writing snapshot file #27 _at_ time 0.487259 ...
> SNAPSHOT: writing snapshot file: './snaps//snapdir_027/snap_m200n2048_027.0' (file 1 of 32)
> SNAPSHOT: writing snapshot block 0 (Coordinates)...
> SNAPSHOT: writing snapshot block 1 (Velocities)...
> SNAPSHOT: writing snapshot block 2 (ParticleIDs)...
> SNAPSHOT: done with writing snapshot. Took 259.535 sec, total size 262144 MB, corresponds to effective I/O rate of 1010.05 MB/sec
>
> SNAPSHOT: Setting next time for snapshot file to Time_next= 0.516885 (DumpFlag=0)
>
>
> As you can see, for some unknown reason, the DumpFlag is 0 after snapshot 27.
> I also noticed that the DumpFlag is 2 at even higher redshift, is that right?
> Thank you.
>
> Best,
> Weiguang
>
> -------------------------------------------
> https://weiguangcui.github.io/
>
>
> On Wed, Oct 13, 2021 at 5:18 PM Volker Springel <vspringel_at_mpa-garching.mpg.de> wrote:
>
> Hi Weiguang,
>
>
> > On 11. Oct 2021, at 10:35, Weiguang Cui <cuiweiguang_at_gmail.com> wrote:
> >
> > How did you specify your output times? Have you done this with a list of output times? In this case, have you used a second column with a flag variable for each output time (0/1)? If you specify the flag, it needs to be 1 to get a full dump at the corresponding time, but if you specify a 0, you only get the snapshot with the most bound particles.
> >
> > Apologize for this late reply, cosma was down for some time. I didn't have time to take more tests.
> > I am using the output file, which only contains a list of the scale factor. There is no second column in this output list file.
> > First I thought that can be caused by some compiling options, this is because I can dump the snapshots by simply commenting out these two lines in the src/main/run.cc:
> > ```
> > diff --git a/src/main/run.cc b/src/main/run.cc
> > index ce4c231..268d5bf 100644
> > --- a/src/main/run.cc
> > +++ b/src/main/run.cc
> > _at_@ -580,14 +580,15 @@ void sim::create_snapshot_if_desired(void)
> > #endif
> > #endif
> >
> > - if(All.DumpFlag_nextoutput)
> > - {
> > + //if(All.DumpFlag_nextoutput)
> > + // {
> > snap_io Snap(&Sp, Communicator, All.SnapFormat); /* get an I/O object */
> > Snap.write_snapshot(All.SnapshotFileCount, NORMAL_SNAPSHOT); /* write snapshot file */
> > - }
> > + // }
> > ```
> > However, I have tried to exclude different compiling options (currently with -std=c++11 -ggdb -O3 -march=native) which did not work.
> > I think this could be caused by some compiling parameter which forces All.DumpFlag_nextoutput (always<1) to 0 in this if condition. But the weird part is the code compiled before worked fine until snapshot_027, only after that (recompiled the code for certain), it fails to dump the snapshots. I also checked if there are other modifications of the code, but not besides the Makefile.
> > Please let me know your thoughts.
> >
>
> This is then also quite puzzling for me. It clearly means that "DumpFlag_nextoutput" stays zero in your run for some reason (but strangely, this didn't seem to be the case earlier until 027). I can't quite see at the moment how this can happen.
>
> In your stdout log-files, you should find messages such as
>
> "SNAPSHOT: Setting next time for snapshot file to Time_next= XXX (DumpFlag=Y)"
>
> What is printed here for DumpFlag? In principle, you should always see "1" there if you have a single-column file with output times. If there is a "0" already here, then for some reason the OutputListFlag[] array does not get initialized to 1 when the list of output times is read. But this is the default for single-column files with output times... Strange.
>
> So for now, simply outcommenting the "if(All.DumpFlag_nextoutput)" check like you have done, or setting "All.DumpFlag_nextoutput=1;" is at least a work-around...
>
> Best,
> Volker
>
>
>
>
>
> > Best,
> > Weiguang
> >
> >
> > -----------------------------------------------------------
> >
> > If you wish to unsubscribe from this mailing, send mail to
> > minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> > A web-archive of this mailing list is available here:
> > http://www.mpa-garching.mpg.de/gadget/gadget-list
>
>
>
>
> -----------------------------------------------------------
>
> If you wish to unsubscribe from this mailing, send mail to
> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
> http://www.mpa-garching.mpg.de/gadget/gadget-list
>
> -----------------------------------------------------------
>
> If you wish to unsubscribe from this mailing, send mail to
> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
> http://www.mpa-garching.mpg.de/gadget/gadget-list
Received on 2021-10-13 20:49:32