[pull] develop from lammps:develop

cmake/Modules/Packages/MBX.cmake

@@ -6,8 +6,8 @@ if(POLICY CMP0135)
   cmake_policy(SET CMP0135 OLD)
 endif()
 
-if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
-  message(FATAL_ERROR "Compiling the MBX package for Windows is currently not supported")
+if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (NOT CMAKE_CROSSCOMPILING))
+  message(FATAL_ERROR "Compiling the MBX package natively for Windows is currently not supported")
 endif()
 
 # for supporting multiple concurrent mbx installations for debugging and testing
@@ -34,8 +34,8 @@ if(CONFIGURE_REQUEST_PIC)
   list(APPEND MBX_CONFIG_FLAGS ${CONFIGURE_REQUEST_PIC})
 endif()
 
-set(MBXLIB_URL "https://github.com/paesanilab/MBX/releases/download/v1.3.5/mbx-1.3.5.tar.gz" CACHE STRING "URL for MBX tarball")
-set(MBXLIB_SHA256 "f66de645b28d73e52be69e6c857b7bd58b6dd0ee398030daecc5bf976bf28111" CACHE STRING "SHA256 checksum of MBX tarball")
+set(MBXLIB_URL "https://github.com/paesanilab/MBX/releases/download/v1.3.12/mbx-1.3.12.tar.gz" CACHE STRING "URL for MBX tarball")
+set(MBXLIB_SHA256 "0f3600d0841e1736abec3fe6a38c8ff673523fe4494169db2839ddaa9bb618bf" CACHE STRING "SHA256 checksum of MBX tarball")
 
 mark_as_advanced(MBXLIB_URL)
 mark_as_advanced(MBXLIB_SHA256)
@@ -65,17 +65,38 @@ if(DOWNLOAD_MBX)
   message(STATUS "MBX_CONFIG_FLAGS: ${MBX_CONFIG_FLAGS}")
 
   include(ExternalProject)
-  ExternalProject_Add(mbx_build
-    URL     ${MBXLIB_URL}
-    URL_HASH SHA256=${MBXLIB_SHA256}
-    CONFIGURE_COMMAND <SOURCE_DIR>/configure
-                      --prefix=<INSTALL_DIR>
-                      ${MBX_CONFIG_FLAGS}
-                      CXX=${MBX_CONFIG_CXX}
-                      CC=${MBX_CONFIG_CC}
-                      CPPFLAGS=-I${FFTW3_INCLUDE_DIRS}
-    BUILD_BYPRODUCTS ${MBX_BUILD_BYPRODUCTS}
-  )
+
+  # hacks to make Linux-to-Windows cross-compilation work
+  if((CMAKE_SYSTEM_NAME STREQUAL "Windows") AND (CMAKE_CROSSCOMPILING))
+    ExternalProject_Add(mbx_build
+      URL     ${MBXLIB_URL}
+      URL_HASH SHA256=${MBXLIB_SHA256}
+      BUILD_IN_SOURCE TRUE
+      CONFIGURE_COMMAND mingw64-configure
+                        --prefix=<INSTALL_DIR>
+                        --disable-i-pi-plugin
+                        ${MBX_CONFIG_FLAGS}
+      INSTALL_COMMAND make install prefix=-build includedir=/include bindir=/bin
+                                 datadir=/share exec_prefix=/ infodir=/share/info
+                                 libdir=/lib libexecdir=/libexec localstatedir=/var
+                                 mandir=/share/man sbindir=/sbin sharedstatedir=/com
+                                 sysconfdir=/etc DESTDIR=<INSTALL_DIR>
+      BUILD_BYPRODUCTS ${MBX_BUILD_BYPRODUCTS}
+    )
+  else()
+    ExternalProject_Add(mbx_build
+      URL     ${MBXLIB_URL}
+      URL_HASH SHA256=${MBXLIB_SHA256}
+      CONFIGURE_COMMAND <SOURCE_DIR>/configure
+                        --prefix=<INSTALL_DIR>
+                        --disable-i-pi-plugin
+                        ${MBX_CONFIG_FLAGS}
+                        CXX=${MBX_CONFIG_CXX}
+                        CC=${MBX_CONFIG_CC}
+                        CPPFLAGS=-I${FFTW3_INCLUDE_DIRS}
+      BUILD_BYPRODUCTS ${MBX_BUILD_BYPRODUCTS}
+    )
+  endif()
   ExternalProject_get_property(mbx_build INSTALL_DIR)
   add_library(LAMMPS::MBX UNKNOWN IMPORTED)
   add_dependencies(LAMMPS::MBX mbx_build)

doc/src/Howto_body.rst

@@ -499,12 +499,21 @@ spheres, one for each sub-particle.  The size of each sphere is
 determined by the *bflag1* parameter for the *body* keyword.  The
 *bflag2* argument is ignored.
 
-For the *rounded/polygon* body style, each body is drawn as a polygon
-and for *rounded/polyhedron* as a polyhedron.  The *bflag2* argument
+For the *rounded/polygon* body style, each body is drawn as a polygon.
+The *bflag2* argument selects how the bodies are represented: for a
+value of 1, only the faces are drawn; for a value of 2 instead only a
+wireframe outline is drawn; and for a value of 3 both the faces and the
+wireframe outline are drawn.  The diameter of the wireframe cylinders is
+determined by the *bflag1* parameter for the *body* keyword.
+
+For the *rounded/polyhedron* body style, each body is drawn as a
+polyhedron consisting of triangles and squares.  The *bflag2* argument
 selects how the bodies are represented: for a value of 1, only the faces
-are drawn; for a value of 2, only a wireframe mesh is drawn, and for a
-value of 3 both.  The diameter of each wireframe line is determined by
-the *bflag1* parameter for the *body* keyword.
+are drawn with some shading added; for a value of 2 instead only a
+wireframe mesh is drawn; for a value of 3 both the faces and the
+wireframe mesh are drawn; and for a value of 4 only the faces are drawn,
+but without shading.  The diameter of the wireframe cylinders is
+determined by the *bflag1* parameter for the *body* keyword.
 
 Note that for both the *rounded/polygon* and *rounded/polyhedron*
 styles, line segments are drawn between the pairs of vertices.

doc/src/Howto_viz.rst

@@ -608,32 +608,38 @@ faces (*bflag1* value 1), or both (*bflag1* value 3).
 Visualizing ellipsoid particles
 -------------------------------
 
+.. versionadded:: 11Feb2026
+
 Ellipsoidal particles are a generalization of spheres that may have
 three different radii to define the shape.  They can be modeled using
-pair styles :doc:`gayberne <pair_gayberne>` or :doc:`resquared
+pair styles like :doc:`gayberne <pair_gayberne>` or :doc:`resquared
 <pair_resquared>`.  The regular :doc:`dump custom <dump>` command can
 output the center of those bodies, the shape parameters and the
 orientation as quaternions.  If one follows the required conventions and
 follows the documented steps, those trajectory dump files can be
 `imported and visualized in OVITO
 <https://www.ovito.org/manual/advanced_topics/aspherical_particles.html>`_
 
+.. versionchanged:: TBD
+
+   Now uses curved triangles instead of flat ones; "both" option is removed
+
 As an alternative, the ellipsoid particles can be visualized directly
 with :doc:`dump image <dump_image>` using the *ellipsoid* keyword.  The
-color and transparency settings can be changed by settings those
+color and transparency settings can be changed by setting those
 properties for the corresponding atom types.  It is also possible to
 represent the ellipsoids via generating a triangle mesh and visualizing
-it as either wireframes (*eflag* value 2), planar faces (*eflag* value
-1), or both (*eflag* value 3), same as demonstrated for body particles
-above.  The use of a triangle mesh is currently required since the
+it as either wireframes (*eflag* value 2) or rounded faces (*eflag*
+value 1).  The use of a triangle mesh is currently required since the
 rasterizer built into LAMMPS does not offer a suitable graphics
 primitive for ellipsoids.  The mesh is constructed by iteratively
-refining a triangle mesh representing an octahedron where each triangle
-is replaced by four triangles.  For a smooth representation a refinement
-level of 5 or 6 is required, which will cause a significant slowdown of
-the rendering of the image.  Also, some artifacts can happen due to
-rounding which can be somewhat minimized using FSAA (which causes
-further slowdown of the rendering).
+refining a triangle mesh representing an icosahedron where each triangle
+is replaced by four triangles in each iteration.  For a sufficiently
+smooth representation a refinement level of 4 to 6 is required (see
+example images below).  A high refinement level can cause a significant
+slowdown of the rendering of the image due to the large number of
+triangles that need to be drawn.  This will be more pronounced when
+enabling FSAA or SSAO or both.
 
 .. |ellipsoid1| image:: img/ellipsoid-level2.png
    :width: 33%

doc/src/dump_image.rst

@@ -52,7 +52,7 @@ Syntax
          width = numeric value for triangle edge width (distance units)
        *ellipsoid* = color eflag level width
          color = *type* or *index* or *atom*
-         eflag = 1 for triangles, 2 for wireframe, 3 for both
+         eflag = 1 for triangles, 2 for wireframe
          level = mesh refinement level, value between 1 (low resolution) and 6 (ultra high resolution)
          width = diameter of wireframe edges (distance units) (ignored for triangles)
        *body* = color bflag1 bflag2
@@ -566,13 +566,18 @@ colors than atom types are desired, the *number of atom types* must be
 
 .. versionadded:: 11Feb2026
 
+.. versionchanged:: TBD
+
+   Now uses rounded triangles
+
 The *ellipsoid* keyword can be used when :doc:`atom_style ellipsoid
 <atom_style>` is used to define particles as ellipsoids, and will draw
-them as a mesh of triangles or edges or both, depending on the setting
-for *eflag*\ .  If edges are drawn, the *width* setting determines the
-diameters of the line segments.  If this keyword is not used, ellipsoid
-particles will be drawn as spheres, the same as if they were regular
-atoms.
+them as a mesh of rounded triangles or edges, depending on the setting
+for *eflag*\ (1 for rounded triangles, 2 for edges, other values are
+accepted for backward compatibility but select rounded triangles).
+If edges are drawn, the *width* setting determines the diameters of the
+line segments.  If this keyword is not used, ellipsoid particles will be
+drawn as spheres, the same as if they were regular atoms.
 
 .. versionchanged:: TBD
 
@@ -600,26 +605,27 @@ colors than atom types are desired, the *number of atom types* must be
 *increased* correspondingly when using either the :doc:`create_box
 <create_box>` or the :doc:`read_data <read_data>` command.
 
+.. versionchanged:: TBD
+
+   changed initial geometry to icosahedron and use rounded triangles
+
 The *level* setting determines the number of triangles in the mesh of
 triangles and thus the resolution of the representation of the
-ellipsoid.  At level 1 the ellipsoid is represented by an octahedron
+ellipsoid.  At level 1 the ellipsoid is represented by an icosahedron
 that is stretched according to the ellipsoid's shape parameters.  For
-each higher level, any of the triangles is replaced by four triangles
-and their edges are shifted to be on the surface of the ellipsoid.  The
-maximum allowed level is 6 (corresponding to 8192 triangles).
+each higher level, a refinement iteration is performed where any of the
+triangles are replaced by four triangles and their edges are shifted to
+be on the surface of the ellipsoid.  The maximum allowed refinement
+level is 6 (corresponding to 12288 triangles per ellipsoid).
 
 .. admonition:: Image quality versus rendering speed
    :class: Hint
 
    Since the rendered ellipsoids are constructed from iteratively
-   refined triangle meshes, the image quality increases with each
-   refinement level, but so does the computational effort to render the
-   image.  Rendering only triangles is much faster than rendering the
-   wireframe edges.  However, at mesh refinement levels of 4 and up,
-   artifacts from the image rendering library are more common where
-   triangles meet.  These artifacts can be somewhat hidden by using the
-   *fsaa yes* setting, but are also less visible when rendering both
-   edges and triangles.
+   refined triangle meshes as explained above, the image quality
+   increases with each refinement level, but so does the computational
+   effort to render the image.  This becomes more pronounced when FSAA
+   or SSAO or both are enabled.
 
 ----------
 

doc/src/fix_colvars.rst

@@ -168,6 +168,16 @@ Aside from the state information in a ".colvars.state" file, other
 are produced by Colvars depending on the type of simulation.  For this
 reason, the "output" keyword is required for fix colvars.
 
+.. versionadded:: TBD
+
+This fix provides access to a global array of the current values of each
+collective variable computed in the Colvars module.  The number of rows
+of the global array is equal to the number of collective variables and
+the columns are:
+
+* `f_ID[I][1]` for a scalar-valued collective variable
+* `f_ID[I][1], ..., f_ID[I][N]` for a vector-valued collective variable
+
 
 Controlling Colvars via `fix_modify`
 """"""""""""""""""""""""""""""""""""

doc/src/fix_graphics_isosurface.rst

@@ -69,7 +69,10 @@ the :doc:`dump image fix <dump_image>` command.  The color is that of
 the atom type's element color instead with the *element* coloring
 scheme, or just a globally set constant color for the whole isosurface
 with the *const* coloring scheme.  That color can be set with the
-*fcolor* keyword of the :doc:`dump modify <dump_image>` command.
+*fcolor* keyword of the :doc:`dump modify <dump_image>` command.  For
+rounded triangles, the color is interpolated across the triangle if
+there are different colors assigned to the different corners of the
+triangle.
 
 The isosurface's transparency setting is fully opaque by default and can
 be changed with the *ftrans* keyword of the :doc:`dump modify
@@ -140,11 +143,11 @@ the fix group and pass the graphics geometry information about it to
 *dump image* so that it is included in the rendered image.
 
 The *fflag1* setting of *dump image fix* determines whether the
-isosurface will be rendered as a set of connected triangles (1) or as a
-mesh of cylinders (2).
+isosurface will be rendered as a set of connected rounded triangles (1)
+or as a mesh of cylinders (2).
 
 If using a mesh of cylinders, the *fflag2* setting determines the
-diameter of the cylinders.
+diameter of the cylinders, otherwise it is ignored.
 
 The *quality* settings of "min" and "low" work best with the cylinder
 mesh setting while the other quality settings are more suitable for a

doc/src/molecule.rst

@@ -13,7 +13,7 @@ Syntax
 * ID = user-assigned name for the molecule template
 * file1,file2,... = names of files containing molecule descriptions
 * zero or more keyword/value pairs may be appended after each file
-* keyword = *offset* or *toff* or *boff* or *aoff* or *doff* or *ioff* or *scale* or *check_labels*
+* keyword = *offset* or *toff* or *boff* or *aoff* or *doff* or *ioff* or *scale* or *check_labels* or *auto*
 
   .. parsed-literal::
 
@@ -37,6 +37,10 @@ Syntax
          sfactor = scale factor to apply to the size, mass, and dipole of the molecule
        *check_labels* value = string
          string = string containing any of the following characters: 'b', 'a', 'd', or 'i'
+       *auto* value = string
+         string = string containing any of the following characters:
+          'a', 'd', or 'i', which will autogenerate angles, dihedrals, and
+          impropers, respectively
 
 Examples
 """"""""
@@ -49,6 +53,7 @@ Examples
    molecule CO2 co2.txt boff 3 aoff 2
    molecule 1 mymol.txt offset 6 9 18 23 14
    molecule objects file.1 scale 1.5 file.1 scale 2.0 file.2 scale 1.3
+   molecule 1 mymol.txt auto ad
 
 Description
 """""""""""
@@ -163,6 +168,36 @@ complex and are described on the doc page for each improper style in the
    <read_restart>`, thus binary restart files need to be converted to
    data files first.
 
+.. versionadded:: TBD
+
+The *auto* keyword allows the molecule command to generate new angles,
+dihedrals, and/or impropers, and assign their angle types, dihedral
+types, and/or improper types.  New interactions are discovered by
+traversing the bond graph defined in the *Bonds* section, and new types
+are inferred using :doc:`type label<Howto_type_labels>`.  Type labels
+for angle, dihedral, and improper types must already be defined (e.g.,
+by the read_data command), to use the *auto* keyword, and each of the
+labels must be defined as a list with its constituent atom type labels
+separated by hyphens, as described for the *check_labels* keyword.  The
+*auto* value is a single string that should contain one or more of the
+characters 'a', 'd', and 'i', which correspond to angles, dihedrals, and
+impropers, respectively.  For example, the keyword/value pair *auto adi*
+will generate angle, dihedral, and improper information, while *auto di*
+will only generate information for dihedrals and impropers but not for
+angles.  Angles are generated from all unique 1-2-3 paths through the
+bond graph.  Dihedrals are generated from all unique 1-2-3-4 paths
+through the bond graph, as long as there are no duplicate atoms in the
+dihedral.  Impropers are generated from all atoms bonded to exactly
+three neighbors.  The type assigned to each generated 2-, 3- and 4-body
+interaction is found by searching the list of type labels for a match,
+e.g., 'c1-c2-c3' or 'c3-c2-c1' in the case of a 3-atom angle.   If a
+matching type cannot be found, LAMMPS will generate an error.
+
+.. note::
+
+  This command requires *Special Bonds* data to exist, which are
+  generated automatically by default.
+
 ----------
 
 Format of a native molecule file