On Fri, Nov 07, 2025, yumura.seigo967--- via AMBER wrote:
>
>I'm working on cMD using pmemd.cuda_SPFP.MPI in AMBER24 package.
>Recently, I noticed something unusual in mdout file.
>
>Specifically, some parts of mdout file appear unreadable
>(please see the example result using cat commands and vim commands below).
>
Are you trying to read an mdout file from a job that is still running? And
is what you get reproducible -- i.e. do you get the same result repeatedly?
>(using cat command)
>_________________________________________________________________________________________________
> getting box info from netcdf restart file
> NATOM = 778396 NTYPES = 27 NBONH = 559725 MBONA = 217713
> NTHETH = 189618 MTHETA = 71234 NPHIH = 333534 MPHIA = 229279
>
> NSTEP = 10550000 TIME(PS) = 122180.000 TEMP(K) = 300.38 PRESS = -13.1
> Etot = -1828147.7466 EKtot = 386684.8750 EPtot = -2214832.6216
> BOND = 20453.3155 ANGLE = 70996.3164 DIHED = 41096.1037
> UB = 0.0000 IMP = 0.0000 CMAP = 1176.6024
> 1-4 NB = 19894.1409 1-4 EEL = 26880.6877 VDWAALS = 224924.2485
> EELEC = -2620254.0368 EHBOND = 0.0000 RESTRAINT = 0.0000
> EKCMT = 145459.6522 VIRIAL = 147188.4150 VOLUME = 6102294.0025
Above is quite odd. The line following the NTHETH line should start with
NHPARM. But your next line has data from some 10 million steps later. I
don't recall ever seeing anything like this.
>(using vim command)
>_________________________________________________________________________________________________
> getting box info from netcdf restart file
> NATOM = 778396 NTYPES = 27 NBONH = 559725 MBONA = 217713
> NTHETH = 189618 MTHETA = 71234 NPHIH = 333534 MPHIA = 229279
>^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.^.
I don't know what is going on here. I will note that it is pretty dangerous
to be running a job with nearly 800000 atoms, and asking for more than 10
million steps. Consider breaking your simulations into (much) smaller
chunks (smaller values of nstlim). That way, if something goes wrong (disk
error, power failure, etc.) you will loose much less data.
[Aside, probably unrelated: consider using barostat=2, which will speed up
the simulation by quite a bit, an provide better sampling of the NPT
ensemble as well.]
...good luck...dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Nov 07 2025 - 08:30:02 PST
