[gmx-users] g_sans_mpi problem: bus error (core dumped)

CHEN Pan evan.pan.chen at gmail.com
Tue Mar 24 14:28:58 CET 2015


Hello Mark,

Now I tried to run from the first 50 ns (-b 0 -e 50000), still, it crashed
at 1600 ps, even less than if I started from -b 50000 to -e 60000. I guess
there is a reading problem. On the other hand, by run g_sans on another
trajectory in which contains around 65000 atoms, the error occurred with
100 ps or even crashed immediately, but with just trying to calculate SANS
on several fragments in the system (about 500 atoms), the tool works very
well. So I guess this tool can't handle "a big system", and may due to
memory problem as you said.

I also tried to analyze data on my own computer by g_sans instead of the
g_sans_mpi in cluster. The error behaviours are the same. Do you have some
other parallel softwares to recommend for SANS calculation?

Thank you.

Pan

2015-03-24 13:06 GMT+01:00 Mark Abraham <mark.j.abraham at gmail.com>:

> On Tue, Mar 24, 2015 at 12:40 PM, CHEN Pan <evan.pan.chen at gmail.com>
> wrote:
>
> > Hi Mark,
> >
> > What's the difference between the frames read and the frames analyzed?
> > Since g_sans read a frame, it's going to analyze it. Right or no?
> >
>
> Depends how badly it's been implemented ;-) I've never looked at that one.
> But since the most likely explanation is running out of memory, you can
> test for that by observing that something like -b 50000 -e 70000 works but
> -e 80000 does not. If -b 0 -e 50000 works, then we know there is a problem
> with using memory for frames read but not analyzed. XTC is designed to be
> seekable, but there are so many archaic trajectory-reading APIs and
> fossilized analysis tools in GROMACS...
>
> Also, running analysis from an MPI build gives you extra ways to have
> problems and no advantage, so I recommend not doing that.
>
> Mark
>
> By using -prframe and -sqframe flags, g_sans is going to analyze on each
> > frame in the trajectory, I would say the error depends on both (the
> frames
> > read and the frames analyzed).
> >
> > 2015-03-24 12:07 GMT+01:00 Mark Abraham <mark.j.abraham at gmail.com>:
> >
> > > Hi,
> > >
> > > Does the erroneous behaviour depend on the number of frames read, or
> the
> > > number of frames analyzed?
> > >
> > > Mark
> > >
> > > On Tue, Mar 24, 2015 at 11:21 AM, CHEN Pan <evan.pan.chen at gmail.com>
> > > wrote:
> > >
> > > > Dear all,
> > > >
> > > > I am using g_sans_mpi (4.6.4 version) to calculate a SANS curve of a
> > > system
> > > > containing about 15000 atoms in total (water, urea, NaOH and
> > oligomers).
> > > > The command used are listed below.
> > > >
> > > > *echo 0 | g_sans_mpi -f ../md.xtc -s ../md.tpr -pr -sq -pbc -mode
> > direct
> > > > -xvg none -b 50000 -e 100000*
> > > >
> > > > The thing is that with calculation for 5 ns of MD trajectory, no
> error
> > > > occurred, whereas for calculation of 50 ns trajectory. An error
> message
> > > > shows " zsh: bus error (core dumped)", or shows "segmentation fault
> 11"
> > > > sometime. With increasing memory or increasing number of threads
> (-nt)
> > > > didn't help.
> > > >
> > > > I have googled for both "g_sans" and "bus error". It seems nobody has
> > > ever
> > > > meet such problem with using g_sans. I understand the manual says
> that
> > > > computational cost is going to increase when using -pr and -sq, as
> well
> > > as
> > > > the increase of number of system particles. Then I tried to calculate
> > > SANS
> > > > curves for each frame with the following command. Still, the same
> error
> > > > occurred after reading over 10 ns of frames.
> > > >
> > > > *echo 0 | g_sans_mpi -f ../md.xtc -s ../md.tpr -prframe -sqframe -pbc
> > > -mode
> > > > direct -xvg none -b 50000 -e 100000*
> > > >
> > > > Welcome for any comments and potential explanations.
> > > >
> > > > Best,
> > > > Pan
> > > > --
> > > > Gromacs Users mailing list
> > > >
> > > > * Please search the archive at
> > > > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > > > posting!
> > > >
> > > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > > >
> > > > * For (un)subscribe requests visit
> > > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users
> or
> > > > send a mail to gmx-users-request at gromacs.org.
> > > >
> > > --
> > > Gromacs Users mailing list
> > >
> > > * Please search the archive at
> > > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > > posting!
> > >
> > > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> > >
> > > * For (un)subscribe requests visit
> > > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> > > send a mail to gmx-users-request at gromacs.org.
> > >
> >
> >
> >
> > --
> > Pan Chen
> > Postdoctoral Associate
> > Tailor-Made Fuels from Biomass
> > AICES Graduate School
> > RWTH Aachen University
> > +49(0)241 8099205
> > --
> > Gromacs Users mailing list
> >
> > * Please search the archive at
> > http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> > posting!
> >
> > * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> >
> > * For (un)subscribe requests visit
> > https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> > send a mail to gmx-users-request at gromacs.org.
> >
> --
> Gromacs Users mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-Users_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-users or
> send a mail to gmx-users-request at gromacs.org.
>



-- 
Pan Chen
Postdoctoral Associate
Tailor-Made Fuels from Biomass
AICES Graduate School
RWTH Aachen University
+49(0)241 8099205


More information about the gromacs.org_gmx-users mailing list