Hi,
I was just made aware of this discussion. While packing "big" systems, Nikolai Skrynnikov et. al, Dan Roe and myself found that the truncated octahedron used by LEaP would result in the solvated object to protrude from the PBC, making clear that the way the truncate octahedron was been calculated until the last release was wrong, but the error is not obvious for small/globular systems. The explanation from Patricio is spot on: the diagonal distance was not being respected, making all systems be closer to the boundary than desired. The bugfix results in the behavior you are seeing, which should actually make the distance be 14 from the solute to the boundary. I am afraid a proper comment in the manual regarding this fix is missing, so I will add something as soon as I can.
Long story short, solvateOct will result in bigger systems in Amber 2026 onwards, and the new sizes are safer than the ones made until 2025, actually respecting the padding distance entered by the user.
Best regards,
Stephan Schott Verdugo
Biochemist
Computational Biophysical Chemistry
Institut für Bio- und Geowissenschaften / Bioinformatik (IBG-4)
Forschungszentrum Jülich GmbH
Wilhelm-Johnen-Straße, 52425 Jülich
Germany
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Dr. Stephanie Bauer (stellvertretende Vorsitzende),
Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers
---------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------
El mié, 17 jun 2026 a la(s) 3:03 p.m., Baker, Joseph via AMBER (amber.ambermd.org<mailto:amber.ambermd.org>) escribió:
Hi Patricio,
Thanks for the detailed response here! Yes this makes sense. Using the
older solvation routine seemed fine for us for this particular system (we
monitor for self-interactions in our trajectories routinely to catch that
type of thing). But it sounds like the fixed approach to solvateoct will be
better at preventing some edge cases going forward and is a safer bet
against self interactions (assuming of course that the protein doesn't
wildly unfold/display dramatic conformational changes during the
simulation)?
Joe
------
Joseph Baker, PhD
Barbara Meyers Pelson Chair in Faculty-Student Engagement (AY 2024-2027)
Professor, Department of Chemistry
The College of New Jersey
Ewing, NJ 08628
Chair-elect (2026), Trenton Local Section of the ACS
Chemistry Division Representative (2024-2027), The Council on Undergraduate
Research
On Tue, Jun 16, 2026, 7:25 PM Patricio Barletta via AMBER <amber.ambermd.org<mailto:amber.ambermd.org>>
wrote:
> Oh, ok, it's the calculation of the bounding box necessary for the atom
> centers (given the buffer length you selected), what changed:
>
> Before:
> ```
>
> Scaling up box by a factor of 1.464352 to meet diagonal cut criterion
>
> Solute vdw bounding box: 137.890 98.975 70.390
>
> Total bounding box for atom centers: 178.892 178.892 178.892
>
> ...
> RESULTING BOX SIZE: 155.7907688 155.7907688 155.7907688 109.4712190
> 109.4712190 109.4712190
> ```
>
> After*:
> ```
>
> Scaling up box by a factor of 1.260286 to meet diagonal cut criterion
>
> Solute vdw bounding box: 137.890 98.975 70.390
>
> Total bounding box for atom centers: 209.069 209.069 209.069
>
> ...
> RESULTING BOX SIZE: 181.9246991 181.9246991 181.9246991 109.4712190
> 109.4712190 109.4712190
> ```
>
> So, you are right: there was a change in how the code calculates the box
> size to guarantee the buffer length in the output, and it was an actual
> bugfix. If you open both structures, you should see that along some
> diagonal (normal to 2 of the octahedron faces), the solute atoms won't have
> much water around them, and that they could be interacting with their
> self-images.
>
> Here's my explanation of the fix, which I didn't do, so I appreciate any
> corrections.
>
> What solvateoct does is first center the solute (your protein), and then
> rotate it to align its principal axis along the XYZ axii. Then it takes the
> solute bounding box (rectangular) and adds 2*buffer length to the longest
> axis to obtain the dimension of the initial cubic solvent box, from which
> the corners are cut to form the truncated octahedron box.
> The issue is that while this method guarantees your buffer length for a
> cubic solvent box, it does not guarantee it for the truncated octahedron
> that will be generated by the subsequent corner cutting. Some atoms will be
> too close to the diagonal faces.
>
> So, solvateoct calls `ToolOctBoxCheck()`, which calculates a scaling
> factor that ensures the initial cubic solvent box is large enough to
> maintain the correct buffer length between the atom that pokes the most and
> its closest octahedral face.
>
> The problem was that `ToolOctBoxCheck()` was scaling the buffer length
> instead of the correct value. You can see it in the numbers you reported:
>
> ```
> Length of largest axis for the initial solute vdw bounding box: 137.89
> Buffer: 14 (on each side, so it's 2Xed)
> Reported scaling factor: 1.464352
> Length of cubic solvent box: 137.89 + 1.464352 * 2 * 14 = 178.892
> ```
> 178.892A was the dimension of your initial cubic solvent box. The length
> of your final box size is 155.7907688A. That's because after all of this,
> solvateoct calls `EwaldRotate()` and rotates all atoms. After that
> rotation, the truncated octahedron gets mapped to a rhombohedron, which is
> the convention pmemd uses.
>
> The problem with this procedure is that it assumes the depth it cuts is
> determined solely by the buffer length (14A in this case), which you can
> imagine would be problematic as the boxes get bigger.
> If it worked like that, given a sufficiently large box, the truncated
> octahedron would be almost the same as the original cubic solvent box.
> BTW, the corner-cutting function is not affected by all of this and will
> work correctly for the given cubic solvent box. The problem is that the
> resulting distance between the atom and the diagonal face will be too close.
>
> Back to the numbers. The point at which corners are cut off depends on the
> total cubic solvent box size. The initial cubic solvent box size is:
> ```
> 28A+137.890 = 165.89A
> ```
> This is the length of the cube edge, and this is the number that should
> get scaled.
> Since the solute bounding box is fixed and dwarfs the buffer (68.945A vs
> 14A), scaling the buffer barely moves the half-box; so the diagonal face
> distance falls short of the needed growth. The bigger the solute, the
> larger the difference between these 2 methods will be.
>
> So, using the reported scaling factor we get that the new edge length is:
> ```
> 165.89A * 1.260286 = 209.069
> ```
>
> Which is the edge length for the "Total bounding box for atom centers" you
> are getting with the latest ambertools. After that, EwaldRotate does its
> thing, and the final box length you get is `181.9246991A`.
>
> So, yes, it changed, but for the better. And while some of your MDs will
> get slower, in this particular case you shouldn't have to pay such a big
> price for the biggers solvent box. You have a very elongated protein. A
> rectangular box might be a better fit.
>
> Best,
>
> *: "Total bounding box for atom centers" is misleading; it should say
> "Total bounding box for atom spheres" or something like that, since the vdw
> radii of the atoms are considered when building the initial cubic solvent
> box.
>
> ________________________________
> From: Baker, Joseph <bakerj.tcnj.edu<mailto:bakerj.tcnj.edu>>
> Sent: Tuesday, June 16, 2026 4:26 PM
> To: Patricio Barletta <pb777.iqb.rutgers.edu<mailto:pb777.iqb.rutgers.edu>>; AMBER Mailing List <
> amber.ambermd.org<mailto:amber.ambermd.org>>
> Subject: Re: [AMBER] solvateoct behavior in Amber26
>
> As for the density question, the initial densities, as you can see from
> the tleap output, are not that far off from one another, so tleap is
> getting the initial densities just fine, it is just adding a lot more water
> in amber26.
>
> ------
> Joseph Baker, PhD
> Barbara Meyers Pelson Chair in Faculty-Student Engagement (AY 2024-2027)
> Professor, Department of Chemistry
> The College of New Jersey
> Ewing, NJ 08628
> Office: C212 Science Complex
> Phone: (609) 771-3173
> Web: www.bakercompchemlab.com<http://www.bakercompchemlab.com><http://www.bakercompchemlab.com/>
> Social Media: Instagram<https://www.instagram.com/bakerlabtcnj/>,
> LinkedIn<https://www.linkedin.com/in/joseph-baker-6b444758/>
> Pronouns: he/him/his
>
> Chair-elect (2026), Trenton Local Section of the ACS
> Chemistry Division Representative (2024-2027), The Council on
> Undergraduate Research
>
>
>
> On Tue, Jun 16, 2026 at 4:07 PM Baker, Joseph <bakerj.tcnj.edu<mailto:bakerj.tcnj.edu><mailto:
> bakerj.tcnj.edu<mailto:bakerj.tcnj.edu>>> wrote:
> Hi Patricio,
>
> Very standard script, pasted at the bottom below. So we haven't been using
> the iso/aniso options. As you can see we are using the ff19SB and OPC water
> combo. As I mentioned, this same script run through multiple versions of
> amber only starts adding a large number of extra waters when we hit the
> amber26 version. As you can see the AmberTools25 and AmberTools23 versions
> of tleap both give a smaller number of OPC water residues added, and the
> bottom of the rst7 file for each of these agree identically. It is only in
> AmberTools26 where things start to change. Thanks for your help looking
> into this! - Joe
>
> For example when I use AmberTools26 it gives me:
>
>
> Loading PDB file: ../../00-structure/fold_full_sequence_model_0.pdb
>
> total atoms in file: 5271
>
> Leap added 4881 missing atoms according to residue templates:
>
> 4881 H / lone pairs
>
> Scaling up box by a factor of 1.260286 to meet diagonal cut criterion
>
> Solute vdw bounding box: 137.890 98.975 70.390
>
> Total bounding box for atom centers: 209.069 209.069 209.069
>
> (box expansion for 'iso' is 81.5%)
>
> Solvent unit box: 18.865 18.478 19.006
>
> Volume: 4635036.174 A^3 (oct)
>
> Total mass 2620962.702 amu, Density 0.939 g/cc
>
> Added 141329 residues.
>
>
> and then the bottom of the rst7 is: 181.9246991 181.9246991 181.9246991
> 109.4712190 109.4712190 109.4712190
>
> For example when I use AmberTools25 it gives me:
>
>
> Loading PDB file: ../../00-structure/fold_full_sequence_model_0.pdb
>
> total atoms in file: 5271
>
> Leap added 4881 missing atoms according to residue templates:
>
> 4881 H / lone pairs
>
> Scaling up box by a factor of 1.464352 to meet diagonal cut criterion
>
> Solute vdw bounding box: 137.890 98.975 70.390
>
> Total bounding box for atom centers: 178.892 178.892 178.892
>
> (box expansion for 'iso' is 105.2%)
>
> Solvent unit box: 18.865 18.478 19.006
>
> Volume: 2910739.196 A^3 (oct)
>
> Total mass 1628046.894 amu, Density 0.929 g/cc
>
> Added 86216 residues.
>
> and then the bottom of the rst7 is: 155.7907688 155.7907688 155.7907688
> 109.4712190 109.4712190 109.4712190
>
>
> For example when I use AmberTools23 it gives me:
>
>
> Loading PDB file: ../../00-structure/fold_full_sequence_model_0.pdb
>
> total atoms in file: 5271
>
> Leap added 4881 missing atoms according to residue templates:
>
> 4881 H / lone pairs
>
> Scaling up box by a factor of 1.464352 to meet diagonal cut criterion
>
> Solute vdw bounding box: 137.890 98.975 70.390
>
> Total bounding box for atom centers: 178.892 178.892 178.892
>
> (box expansion for 'iso' is 105.2%)
>
> Solvent unit box: 18.865 18.478 19.006
>
> Volume: 2910739.196 A^3 (oct)
>
> Total mass 1628046.894 amu, Density 0.929 g/cc
>
> Added 86216 residues.
>
>
> and then the bottom of the rst7 is: 155.7907688 155.7907688 155.7907688
> 109.4712190 109.4712190 109.4712190
>
> ----SCRIPT----
>
> #Load in the necessary forcefields
>
> source leaprc.protein.ff19SB
>
> source leaprc.water.opc
>
>
> #Load the PDBs
>
> prot = loadpdb ../00-structure/fold_full_sequence_model_0.pdb
>
>
> #solvate system
>
> solvateoct prot OPCBOX 14
>
>
> #Adding Ions
>
> addIonsRand prot Na+ 0
>
> addIonsRand prot Cl- 0
>
>
> #save files
>
> saveAmberParm prot sys.parm7 sys.rst7
>
>
> # Quit
>
> quit
>
> ------
> Joseph Baker, PhD
> Barbara Meyers Pelson Chair in Faculty-Student Engagement (AY 2024-2027)
> Professor, Department of Chemistry
> The College of New Jersey
> Ewing, NJ 08628
> Chair-elect (2026), Trenton Local Section of the ACS
> Chemistry Division Representative (2024-2027), The Council on
> Undergraduate Research
>
>
>
> On Tue, Jun 16, 2026 at 3:46 PM Patricio Barletta via AMBER <
> amber.ambermd.org<mailto:amber.ambermd.org><mailto:amber.ambermd.org<mailto:amber.ambermd.org>>> wrote:
> *
> Can I see the tleap script you are running? I'm curious about the water
> model.
> *
> If you do tail -n1 <OUTPUT RST7 FILE> , do you get the same box size in
> all cases?
> *
> If you run NVT on the output systems, do you get the same starting density?
>
> The coordinates for the pre-equilibrated water molecules are at
> `amber/dat/leap/lib/`, and I don't see any change on files like
> 'tip3pbox.off'.
> The other factor that may affect the final result is the usage of the
> keyword "aniso", that prevents tleap from centering and reorienting the
> solute before adding the box. This increases the box size for a given
> buffer length.
>
> Best,
>
> ________________________________
> From: amber-request.ambermd.org<mailto:amber-request.ambermd.org><mailto:amber-request.ambermd.org<mailto:amber-request.ambermd.org>> <
> amber-request.ambermd.org<mailto:amber-request.ambermd.org><mailto:amber-request.ambermd.org<mailto:amber-request.ambermd.org>>>
> Sent: Tuesday, June 16, 2026 3:00 PM
> To: amber.ambermd.org<mailto:amber.ambermd.org><mailto:amber.ambermd.org<mailto:amber.ambermd.org>> <amber.ambermd.org<mailto:amber.ambermd.org><mailto:
> amber.ambermd.org<mailto:amber.ambermd.org>>>
> Subject: AMBER Digest, Vol 4976, Issue 1
>
> Send AMBER mailing list submissions to
> amber.ambermd.org<mailto:amber.ambermd.org><mailto:amber.ambermd.org<mailto:amber.ambermd.org>>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.ambermd.org%2Fmailman%2Flistinfo%2Famber&data=05%7C02%7Cpb777%40iqb.rutgers.edu%7C8e65331797bc4548af9808decbd97df0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C639172332140833078%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aPBuprBWvr56DTCEiJWDVK6OO0csbOPD5yenZW2A5pY%3D&reserved=0
> <http://lists.ambermd.org/mailman/listinfo/amber><
> http://lists.ambermd.org/mailman/listinfo/amber>
> or, via email, send a message with subject or body 'help' to
> amber-request.ambermd.org<mailto:amber-request.ambermd.org><mailto:amber-request.ambermd.org<mailto:amber-request.ambermd.org>>
>
> You can reach the person managing the list at
> amber-owner.ambermd.org<mailto:amber-owner.ambermd.org><mailto:amber-owner.ambermd.org<mailto:amber-owner.ambermd.org>>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AMBER digest..."
>
>
> AMBER Mailing List Digest
>
> Today's Topics:
>
> 1. solvateoct behavior in Amber26 (Baker, Joseph)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Jun 2026 14:55:03 -0400
> From: "Baker, Joseph" <bakerj.tcnj.edu<mailto:bakerj.tcnj.edu><mailto:bakerj.tcnj.edu<mailto:bakerj.tcnj.edu>>>
> To: AMBER Mailing List <amber.ambermd.org<mailto:amber.ambermd.org><mailto:amber.ambermd.org<mailto:amber.ambermd.org>>>
> Subject: [AMBER] solvateoct behavior in Amber26
> Message-ID:
> <
> CAA5VDpDSCstP8vGa_cQ3Nj9eWtZCx3vpwkNSvTuWcxJsukYpTw.mail.gmail.com<mailto:CAA5VDpDSCstP8vGa_cQ3Nj9eWtZCx3vpwkNSvTuWcxJsukYpTw.mail.gmail.com><mailto:
> CAA5VDpDSCstP8vGa_cQ3Nj9eWtZCx3vpwkNSvTuWcxJsukYpTw.mail.gmail.com<mailto:CAA5VDpDSCstP8vGa_cQ3Nj9eWtZCx3vpwkNSvTuWcxJsukYpTw.mail.gmail.com>>>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
>
> One of my students noticed that their simulations were running much more
> slowly suddenly, and when looking at our tleap output we observed that the
> solvateoct command seems to be adding a significantly larger number of
> water molecules to the system than it has in the past (with the same
> padding value, using the same initial structure). We went back and checked
> the behavior in 25,24,23,22 versions and they were all consistent with the
> number of water molecules being placed by solvateoct. Has there been some
> change in the way solvateoct handles building the water shell?
>
> Thanks!
> Joe
>
> ------
> Joseph Baker, PhD
> Barbara Meyers Pelson Chair in Faculty-Student Engagement (AY 2024-2027)
> Professor, Department of Chemistry
> The College of New Jersey
> Ewing, NJ 08628
> Chair-elect (2026), Trenton Local Section of the ACS
> Chemistry Division Representative (2024-2027), The Council on Undergraduate
> Research
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org><mailto:AMBER.ambermd.org<mailto:AMBER.ambermd.org>>
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.ambermd.org%2Fmailman%2Flistinfo%2Famber&data=05%7C02%7Cpb777%40iqb.rutgers.edu%7C8e65331797bc4548af9808decbd97df0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C639172332140860528%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ANXzqOLpZ8O6AyVTuxf03fi9W1XYEjeXFJia8APZ7Uc%3D&reserved=0
> <http://lists.ambermd.org/mailman/listinfo/amber><
> http://lists.ambermd.org/mailman/listinfo/amber>
>
>
> ------------------------------
>
> End of AMBER Digest, Vol 4976, Issue 1
> **************************************
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org><mailto:AMBER.ambermd.org<mailto:AMBER.ambermd.org>>
> http://lists.ambermd.org/mailman/listinfo/amber
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org<mailto:AMBER.ambermd.org>
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org<mailto:
AMBER.ambermd.org>
http://lists.ambermd.org/mailman/listinfo/amber
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Dr. Stephanie Bauer (stellv. Vorsitzende),
Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Dr. Stephanie Bauer (stellv. Vorsitzende),
Prof. Dr. Ir. Pieter Jansens, Prof. Dr. Laurens Kuipers
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jun 17 2026 - 09:00:02 PDT
