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__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
>
Received on 2021-10-13 19:12:35