Re: snapshot file problem

From: Weiguang Cui <cuiweiguang_at_gmail.com>
Date: Fri, 22 Oct 2021 14:35:09 +0100

Hi Volker,

Terribly sorry for the late confirmation of my stupid mistake which indeed
is caused by my messed-up output list file.
Thank you for taking time to look into this.

Best,
Weiguang

-------------------------------------------
https://weiguangcui.github.io/


On Wed, Oct 13, 2021 at 7:50 PM Volker Springel <
vspringel_at_mpa-garching.mpg.de> wrote:

>
> 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__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
>
>
>
>
> -----------------------------------------------------------
>
> 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-22 15:35:56

This archive was generated by hypermail 2.3.0 : 2023-01-10 10:01:33 CET