[gmx-users] single-precision *.tpr data after a double-precision run
Inon Sharony
InonShar at post.TAU.ac.IL
Thu Aug 7 14:48:52 CEST 2008
Amazing! It didn't say anything about double-precision, and I got:
Maximum force: 4.32762e-04
(this is from the Hessian calculation, after minimization that got
Stepsize too small, or no change in energy.
Converged to machine precision,
but not to the requested precision Fmax < 1e-06
writing lowest energy coordinates.
Back Off! I just backed up b4nm_s_1.gro to ./#b4nm_s_1.gro.1#
Polak-Ribiere Conjugate Gradients converged to machine precision in 994 steps,
but did not reach the requested Fmax < 1e-06.
Potential Energy = 3.83658151247483e+00
Maximum force = 5.38105464411935e-05 on atom 1
Norm of force = 2.07631890036319e-05
so it's an improvement of more than 6 orders of magnitude! Could it be
that the *.trr file have the coordinates in double-precision?
Not to be petty, but still, I had a max. force of 5.38105464411935e-05
using the minimization procedure, and the Hessian calculation only got
4.32762e-04. That's still an order of magnitude that does not transfer
from the energy minimization step to the Hessian calculation step. Why?
THANKS Ran !!!!!
for reference:
===============
//energy minimization:
//--------------------
grompp_d -f em.mdp -c b4nm_s.gro -n index.ndx
mdrun_d -c b4nm_s_1.gro -v yes
//Hessian calculation:
//--------------------
grompp_d -f nm.mdp -c b4nm_s_1.gro -n index.ndx -t traj.trr -e ener.edr
mdrun_d -c nm.gro -mtx nm.mtx -v yes -e ener_nm.edr -o traj_nm.trr
Quoting "Ran Friedman" <r.friedman at bioc.uzh.ch>:
> Hi,
>
> I'm not sure if this is the problem but did you try to include the
> energy and trajectory files when running grompp (flags -e and -t)?
>
> Ran.
>
> Inon Sharony wrote:
>>
>> Hello GROMACS users!
>>
>> I've posted a few questions in the last few days about
>> double-precision energy minimization for normal mode analysis, and
>> everything seems OK except I've been having a re-occurring
problem:
>>
>> The energy minimization procedure ends in
>> =========================================
>> // grompp_d -f em.mdp -c b4nm_s_7.gro -n index.ndx
>> // mdrun_d -c b4nm_s_8.gro -v yes
>>
>>
>> Stepsize too small, or no change in energy.
>> Converged to machine precision,
>> but not to the requested precision Fmax < 1e-06
>>
>> writing lowest energy coordinates.
>>
>> Polak-Ribiere Conjugate Gradients converged to machine precision
in
>> 994 steps,
>> but did not reach the requested Fmax < 1e-06.
>> Potential Energy = 3.83658151247483e+00
>> Maximum force = 5.38105464411977e-05 on atom 1
>> Norm of force = 2.07631890036341e-05
>>
>>
>>
>> The Hessian matrix write ends in:
>> =================================
>> // grompp_d -f nm.mdp -c b4nm_s_8.gro -n index.ndx
>> // mdrun_d -c nm.gro -mtx nm.mtx -v yes
>>
>>
>>
>>
>> Reading file topol.tpr, VERSION 3.3.3 (double precision)
>> Loaded with Money
>>
>> Small system size (N=7), using full Hessian format.
>> Allocating Hessian memory...
>>
>> starting normal mode calculation 'Single Molecule of Pentane'
>> 7 steps.
>>
>> Maximum force: 3.51028e+02
>> Maximum force probably not small enough to ensure that you are in
a
>> energy well. Be aware that negative eigenvalues may occur when the
>> resulting matrix is diagonalized.
>> Finished step 7 out of 7
>>
>> Writing Hessian...
>>
>>
>>
>>
>> Clearly, the maximal force is minimized to about 1E-05 kJ / mole
nm,
>> but when the same *.gro file is read for the Hessian calculation,
it
>> reads about 1E+02!
>> I think the reason is found in the *.tpr file of the energy
>> minimization run:
>>
>> x (7x3):
>> x[ 0]={ 3.17800e+00, 3.49300e+00, 3.38500e+00}
>> x[ 1]={ 3.31300e+00, 3.51800e+00, 3.31600e+00}
>> x[ 2]={ 3.42500e+00, 3.43000e+00, 3.37400e+00}
>> x[ 3]={ 3.41400e+00, 3.28500e+00, 3.32700e+00}
>> x[ 4]={ 3.52700e+00, 3.20300e+00, 3.38900e+00}
>> x[ 5]={ 3.02600e+00, 3.50200e+00, 3.36900e+00}
>> x[ 6]={ 3.60400e+00, 3.07000e+00, 3.38200e+00}
>>
>> This means that although the minimization was run in double
precision,
>> the atomic configuration is saved in single precision (the last
two
>> decimal places are not used). Does this mean that each time the
>> optimized *.gro file is re-read, it needs to optimize these last
two
>> decimal places anew, and this makes the difference in SEVEN orders
of
>> magnitude in the maximal force?
>>
>> Can anyone offer a solution?
>>
>> Thanks in advance...
>>
>>
>>
>> Inon.
>>
>>
>> Some background information:
>> ----------------------------
>>
>> I'm running GROMACS 3.3.3 on the following system (with bash):
>>
>> /* composed by Inon Sharony August 6th, 2008 */
>> /* ----------------------------------------- */
>> /* */
>> /* this file contains the hardware information for Sodium */
>> /* the first part details the video card */
>> /* the second part details the CPUs */
>> /* the third part details the BIOS and motherboard */
>> /* */
>>
>> lspci -v /* list PCI -verbose */
>> =================================
>>
>> .
>> .
>> .
>>
>>
>> 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8500
GT
>> (rev a1) (
>> prog-if 00 [VGA controller])
>> Subsystem: LeadTek Research Inc. Unknown device 2a94
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>> Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
>> Memory at d0000000 (64-bit, prefetchable) [size=256M]
>> Memory at e0000000 (64-bit, non-prefetchable) [size=32M]
>> I/O ports at 2000 [size=128]
>> Capabilities: [60] Power Management version 2
>> Capabilities: [68] Message Signalled Interrupts: Mask-
64bit+
>> Queue=0/0
>> Enable-
>> Capabilities: [78] Express Endpoint, MSI 00
>> Capabilities: [100] Virtual Channel <?>
>> Capabilities: [128] Power Budgeting <?>
>> Capabilities: [600] Vendor Specific Information <?>
>> Kernel driver in use: nvidia
>> Kernel modules: nvidia, nvidiafb
>>
>>
>> .
>> .
>> .
>>
>>
-------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> cat /proc/cpuinfo /* CPUs information */
>> ========================================
>>
>> processor : 0
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 15
>> model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
>> stepping : 11
>> cpu MHz : 1596.000
>> cache size : 4096 KB
>> physical id : 0
>> siblings : 4
>> core id : 0
>> cpu cores : 4
>> fpu : yes
>> fpu_exception : yes
>> cpuid level : 10
>> wp : yes
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni
monitor
>> ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
>> bogomips : 4802.25
>> clflush size : 64
>> cache_alignment : 64
>> address sizes : 36 bits physical, 48 bits virtual
>> power management:
>>
>>
>> .
>> .
>> .
>>
>>
-------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> /usr/sbin/dmidecode
>> ===================
>>
>> # dmidecode 2.7
>> SMBIOS 2.4 present.
>> 39 structures occupying 1779 bytes.
>> Table at 0x000E3300.
>>
>> Handle 0x0000, DMI type 4, 35 bytes.
>> Processor Information
>> Socket Designation: J1PR
>> Type: Central Processor
>> Family: <OUT OF SPEC>
>> Manufacturer: Intel(R) Corporation
>> ID: FB 06 00 00 FF FB EB BF
>> Version: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
>> Voltage: 1.6 V
>> External Clock: 266 MHz
>> Max Speed: 4000 MHz
>> Current Speed: 2400 MHz
>> Status: Populated, Enabled
>> Upgrade: <OUT OF SPEC>
>> L1 Cache Handle: 0x0003
>> L2 Cache Handle: 0x0001
>> L3 Cache Handle: Not Provided
>> Serial Number: Not Specified
>> Asset Tag: Not Specified
>> Part Number: Not Specified
>>
>>
>> .
>> .
>> .
>>
>> /* BIOS information */
>>
>> Handle 0x0004, DMI type 0, 24 bytes.
>> BIOS Information
>> Vendor: Intel Corp.
>> Version: DPP3510J.86A.0326.2007.1206.2256
>> Release Date: 12/06/2007
>> Address: 0xF0000
>> Runtime Size: 64 kB
>> ROM Size: 1024 kB
>> Characteristics:
>> PCI is supported
>> BIOS is upgradeable
>> BIOS shadowing is allowed
>> Boot from CD is supported
>> Selectable boot is supported
>> EDD is supported
>> 8042 keyboard services are supported (int 9h)
>> Serial services are supported (int 14h)
>> Printer services are supported (int 17h)
>> CGA/mono video services are supported (int 10h)
>> ACPI is supported
>> USB legacy is supported
>> ATAPI Zip drive boot is supported
>> BIOS boot specification is supported
>> Function key-initiated network boot is supported
>> Targeted content distribution is supported
>> BIOS Revision: 0.0
>> Firmware Revision: 0.0
>>
>>
>> .
>> .
>> .
>>
>> /* Motherboard information */
>>
>> Handle 0x0006, DMI type 2, 20 bytes.
>> Base Board Information
>> Manufacturer: Intel Corporation
>> Product Name: DP35DP
>> Version: AAD81073-207
>> Serial Number: USDP747001WP
>> Asset Tag: Base Board Asset Tag
>> Features:
>> Board is a hosting board
>> Board is replaceable
>> Location In Chassis: Base Board Chassis Location
>> Chassis Handle: 0x0007
>> Type: Unknown
>> Contained Object Handles: 0
>>
>>
>>
>> --Inon Sharony
>> ×™× ×•×Ÿ שרו×
י
>> +972(3)6407634
>> atto.TAU.ac.IL/~inonshar
>> Please consider your environmental responsibility before printing
>> this e-mail.
>>
>> _______________________________________________
>> gmx-users mailing list gmx-users at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-users
>> Please search the archive at http://www.gromacs.org/search before
>> posting!
>> Please don't post (un)subscribe requests to the list. Use thewww
>> interface or send it to gmx-users-request at gromacs.org.
>> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>>
>
>
> --
> ------------------------------------------------------
> Ran Friedman
> Postdoctoral Fellow
> Computational Structural Biology Group (A. Caflisch)
> Department of Biochemistry
> University of Zurich
> Winterthurerstrasse 190
> CH-8057 Zurich, Switzerland
> Tel. +41-44-6355593
> Email: r.friedman at bioc.unizh.ch
> Skype: ran.friedman
> ------------------------------------------------------
>
> _______________________________________________
> gmx-users mailing list gmx-users at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-users
> Please search the archive at http://www.gromacs.org/search before
posting!
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
>
--
Inon Sharony
×™× ×•×Ÿ ×©×¨×•× ×™
+972(3)6407634
atto.TAU.ac.IL/~inonshar
Please consider your environmental responsibility before printing
this e-mail.
More information about the gromacs.org_gmx-users
mailing list