[gmx-users] Out of disk space

[Mark Abraham]

On Tue, Jun 3, 2014 at 10:35 PM, Carlos Familia <carlosfamilia at gmail.com>
wrote:

> Hello,
>
> I was running the final equilibration step (NTP) and i received an error
> saying that i was running out of disk space, the trajectory file writen has
> 2GB, and every retry will generate a file with the same size. I have looked
> for file size limit, but there is no limitation that i can find on my
> system. I am runing arch linux on a 32bits computer (i686),


That is likely a limitation that is manifest in whatever library stack is
supporting the file writing that GROMACS is using. If (say) the C library
uses a 32-bit integer for the size, bang you're dead.


> the file system
> is ext4, have 2GB of ram, and 64GB of disk available.
>
> The command issued was:
>
>     mdrun -v -deffnm npt
>
> The gromacs message was:
>
>     Program mdrun, VERSION 4.6.5
>     Source code file:
> .../aur-gromacs-mpi/src/gromacs-4.6.5/src/gmxlib/trnio.c, line: 311
>
>     File input/output error:
>     Cannot write trajectory frame; maybe you are out of disk space?
>     For more information and tips for troubleshooting, please check the
> GROMACS
>
> I have also runned the comman ulimit -a, that showed:
>
>     core file size          (blocks, -c) 0
>     data seg size           (kbytes, -d) unlimited
>     scheduling priority             (-e) 30
>     file size               (blocks, -f) unlimited
>     pending signals                 (-i) 16117
>     max locked memory       (kbytes, -l) unlimited
>     max memory size         (kbytes, -m) unlimited
>     open files                      (-n) 1024
>     pipe size            (512 bytes, -p) 8
>     POSIX message queues     (bytes, -q) 819200
>     real-time priority              (-r) 99
>     stack size              (kbytes, -s) 8192
>     cpu time               (seconds, -t) unlimited
>     max user processes              (-u) 16117
>     virtual memory          (kbytes, -v) unlimited
>     file locks                      (-x) unlimited
>
> Additionally i run a program to write 2.5 GB to disk in c++, that generated
> the 2.5GB file without any problem:
>
>     #include <iostream>
>     #include <fstream>
>     #include <vector>
>
>     int main()
>     {
>         std::vector<char> empty(1024, 0);
>         std::ofstream ofs("ouput.img", std::ios::binary | std::ios::out);
>
>         for(int i = 0; i < 1024*2560; i++)
>         {
>             if (!ofs.write(&empty[0], empty.size()))
>             {
>                 std::cerr << "problem writing to file" << std::endl;
>                 return 255;
>             }
>         }
>     }
>
> Any ideas on how to solve this?
>

Use a 64-bit operating system ;-) This is a problem users of your operating
system have likely encountered before, so if there is (say) a C library
that is compiled in some kind of 64-bit work-around mode, you may be able
to use that. The C++ library seems like it may have such a back end.

I know that i can change the parameters in the mdp file in order to
> generate smaller files, but i was looking for a different solution that
> wouldn't require this.
> Is there any option to mdrun that could split the trajectory file for a
> specified size?
>

No.

Mark


>
> Thanks,
>
> Carlos Família
> --
> Carlos Familia, MSc , PharmD
> ISCSEM Pharmacology Assistant Lecturer
> ISCSEM Laboratory of Molecular Pathology Researcher
> Tel. +351 212946700 (Main) / +351 212946769 (Lab)
> e-mail: carlosfamilia at gmail.com / carlosfamilia at egasmoniz.edu.pt
> --
> 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.
>