{"id":19740086,"url":"https://github.com/efliks/mead","last_synced_at":"2026-05-15T04:04:12.080Z","repository":{"id":135104086,"uuid":"208634300","full_name":"efliks/MEAD","owner":"efliks","description":"Macroscopic Electrostatics with Atomic Detail","archived":false,"fork":false,"pushed_at":"2019-10-09T21:37:10.000Z","size":816,"stargazers_count":0,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-28T06:08:21.454Z","etag":null,"topics":["computational-chemistry","electrostatic-interactions","electrostatics","proteins","structural-biology"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/efliks.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2019-09-15T17:57:46.000Z","updated_at":"2021-06-16T21:58:43.000Z","dependencies_parsed_at":"2023-09-17T07:40:16.344Z","dependency_job_id":null,"html_url":"https://github.com/efliks/MEAD","commit_stats":null,"previous_names":["feliksm1/mead","skilefm/mead","efliks/mead","mikolajfeliks/mead"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/efliks/MEAD","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efliks%2FMEAD","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efliks%2FMEAD/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efliks%2FMEAD/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efliks%2FMEAD/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/efliks","download_url":"https://codeload.github.com/efliks/MEAD/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/efliks%2FMEAD/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33053146,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-13T13:14:54.681Z","status":"online","status_checked_at":"2026-05-15T02:00:06.351Z","response_time":103,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["computational-chemistry","electrostatic-interactions","electrostatics","proteins","structural-biology"],"created_at":"2024-11-12T01:19:26.479Z","updated_at":"2026-05-15T04:04:12.062Z","avatar_url":"https://github.com/efliks.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"This is version 2.2 of MEAD, Macroscopic Electrostatics\nwith Atomic Detail.  Copyright (c) 1990-1998 Donald Bashford, The Scripps\nResearch Institute.  This README file is written by Donald Bashford.\n\nPlease send me an email message at don.bashford@stjude.org if you intend\nto use MEAD.  This helps to get support for MEAD, and also provides a\nway for you to be notified of new versions of MEAD.  If you use MEAD\nin research for publication, you can cite the following papers:\n\nD. Bashford \u0026 K.  Gerwert (1992) \"Electrostatic Calculations of the\n  pKa Values of Ionizable Groups in Bacteriorhodopsin\"\n  J. Mol. Biol. vol. 224 pp.  473-486\nDonald Bashford.  \"An Object-Oriented Programming Suite for\n  Electrostatic Effects in Biological Molecules\" In Yutaka Ishikawa,\n  Rodney R. Oldehoeft, John V. W. Reynders, and Marydell Tholburn,\n  editors, \"Scientific Computing in Object-Oriented Parallel\n  Environments\", volume 1343 of Lecture Notes in Computer Science, pages\n  233--240, Berlin, 1997. ISCOPE97, Springer.\n\n\nBug reports are welcome.  Send them to don.bashford@stjude.org\n\nThe main documentation for MEAD is this README file, whose main\npurpose is to explain what's in the distribution and how to run the\nprograms.  For a breif outline of the design of MEAD, see the ISCOPE97\npaper cited above.  (It's on the FTP site too as iscope-paper.ps)\n\nPlease look at the file INSTALLATION even if you have installed a\nprevious version of MEAD before.  We have switched to the use of a\nconfigure script, rather the the multiple-makefile scheme used before.\nAlso, the organization of both the source files and the installed\nfiles has changed.\n\nINTRODUCTION\n\nMEAD is a set of software objects for the purpose of modeling the\nelectrostatics of molecules using a semi-macroscopic picture in\nwhich the solvent and the molecular interior have different dielectric\nconstants, the boundary between the different dielectric regions is\ndependent on the detailed atomic structure of the molecule, and\nthe electrostatic potential is determined by the Poisson-Boltzmann\nequation.  This version of MEAD includes modeling of a membrane\nas a low dielectric slab, possibly with a water-filled channel\nthrough a protein in the membrane.\n\nMEAD is written in C++, which is a significant departure from\nmost molecular software, which is more commonly written in Fortran\nor (recently) C.  My purpose in choosing C++ was to explore\nthe object-oriented programming style that C++ facilitates\nand to make a software system that other people could borrow\npieces from and make extensions to in a convenient way.\n\nMEAD is free software.  You can redistribute it and/or modify it under\nthe terms of the GNU General Public License as published by the Free\nSoftware Foundation; either version 1, or (at your option) any later\nversion.  For information about your rights to obtain, copy, modify\nand redistribute MEAD, see the files, COPYING.DB and COPYING.GNU which\nshould be included along with this.\n\n    This program is distributed in the hope that it will be useful,\n    but WITHOUT ANY WARRANTY; without even the implied warranty of\n    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the\n    GNU General Public License for more details.\n\nSee the INSTALLATION file for a list of machines MEAD is known\nto run on and instructions on compiling MEAD.  Also see the PROBLEMS\nfile for some discussion of known problems on certain machines.\n\nREPRODUCTION OF PUBLISHED RESULTS\n\nThis distribution of MEAD has the programs, data files and parameter\nfiles needed to reproduce the results reported in several\npublications.  Files for the pK calculations on the triclinic\nstructure of lysozyme reported in D. Bashford \u0026 M. Karplus (1990)\nBiochemistry vol.  29, pp. 10219-25 are in the subdirectory, \nexamples/lysozyme.\nFiles for some of the results reported in D. Bashford \u0026 K.  Gerwert\n(1992) \"Electrostatic Calculations of the pKa Values of Ionizable\nGroups in Bacteriorhodopsin\" J. Mol. Biol. vol. 224 pp.  473-486, are\nin the subdirectory, examples/br.  Data files to reproduce some of the results\nfrom Donald Bashford, David A. Case, Claudio Dalvit, Linda Tennant and\nPeter E. Wright (1993) \"Electrostatic Calculations of Side-chain pKa\nValues in Myoglobin and Comparison with NMR Data for Histidines\",\nBiochemistry vol. 23, pp. 8045--8056, are in the directory examples/myoglobin.\nSome of the test results for the method of calculated solvent\naccessibility lattices reported in You and Bashford (1995b),\nJ. Comp. Chem. vol. 16, pp. 743-757 can be reproduced using the data\nfiles in the subdirectory examples/solvacc.\n\nThe input data to reproduce the results for a conformationally\nflexible site in lysozyme reported in You and Bashford (1995a),\nBiophys. J. vol 69, pp. 1721-1733, are in a separate distribution\nfile, lysoflex.tar.Z, on the Scripps FTP server.  Similarly the data\nfiles for the results reported in Dillet, Dyson and Bashford (1998)\n\"Calculations of Electrostatic Interactions and pKa's in the Active\nSite of Escherichia coli Thioredoxin\" Biochemsitry vol 37,\npp. 10298-10306. are in thioredoxin.tar.gz on the FTP server.  Both\nthese data sets are quite large since they contain a number of protein\ncoordinate files.\n\nThe computer programs needed to reproduce the results mentioned above\nare mostly under apps, although in some cases, problem-specific\nshell scripts or perl scripts are in the data-file directories.  For\nsome of these studies, a version of Paul Beroza's mcti program was\nused in a final step.  Mcti is not distributed by the Bashford lab,\nalthough the Scripps FTP currently server has a version of it\nunder pub/case/beroza/pep/xmcti-1.1.1.tar.Z.  There may be slight\ndifferences between the version of mcti used in house and the one\ncurrently on the FTP server.\n\nORGANIZATION OF MEAD SOURCES: MEAD AS A LIBRARY:\n\nA long-standing goal of MEAD has been to serve not only as a\ncollection of useful applications (documented below) but also as an\nobject-oriented library to allow other researchers to create their own\napplications.  Starting with version 2.2.0, this is achieved by\nreorginizing the source code directories, and by having an install\nprocedure that installs MEAD as a library.\n\nBuilding MEAD causes a static library file libmead.a to be created and\ninstallation puts it in a place like /usr/local/lib.  Also the various\nheader (*.h) files that are needed to compile a program using the MEAD\nlibrary are put in a place like /usr/local/include/MEAD by the\ninstallation procedure.  Applcation programmers then need not put\ntheir programs into the distributed source directory.  Rather, they\ncan put them in their own directory and put lines like\n   #include \u003cMEAD/ElstatPot.h\u003e\nand so on, in their source code, and compile using whatever flags are\nneeded to tell the compiler where to find include files (usually \"-I\"\non Unix compilers); and link using the appropiate flags to find\nlibmead (on Unix something like \"-L/usr/local/lib -lmead\").\n\nIn the distributed source directory, the files needed to make\nlibmead.a are in the directory libmead (which might be renamed or\nsymlinked to MEAD in some situations).  Applications programs are in\nindividual subdirectories under apps.  The swig subdirectory pertains\nto the new Python interface (see below).  This business of putting\neach libarary and application into its own subdirectory seems to be\nnecessary for many implementations of C++ if either the libraries or\nthe applications make much use of templates.  It also seems to help\nwith portability to Windows.\n\nUnfortunately, there is not yet documentation for MEAD as a library.\nYour best bet is to look at the source code of some of the simpler\napplications like potental or solvate or (getting a bit more complex)\nsolinprot.  Don't start with multiflex, it's too hairy.\n\n\nPYTHON INTERFACE:\n\nRecently, we have begun the process of \"wrapping\" MEAD to make it\navailable from the Python scripting language.  We have tried to make\nthe Python interface as closely analogous as possilbe to the C++\ninterface.  Only a portion of the higher-level parts of the MEAD\nlibrary are wrapped at present, and documentation is lacking.  For\nmore information about the Python wrapping, see the directory, swig,\nand the README file therein.  The python wrapping is currently\noptional in the building process, see INSTALLATION for more.\n\nWe don't yet have documentation for the Python interface, but you can\nget an idea by looking at some simple examples in that directory,\nsol.py genpot.py and bug.py.  To see a full list of the classes and\nfunctions available (but with no documentation strings), see MEAD.py.\n\nTo run the simply python examples, type \"python genpot.py\", and so on.\nThis will only work if \"make install\" has installed the python\ninterface to MEAD (see INSTALLATION).  If you're just sitting in the\nswig directory, but haven't done the install, you'll need to edit the\napplication files by and change the lines \"from PyMead import MEAD\" to\n\"import MEAD\"\n\nNOTE: bug.py will cause a Python run-time error to be signalled.\nThat's what it's supposed to do!  This means that errors dedected\nwithin the MEAD C++ code are get translated into python exceptions\nwhich scripts can catch and handle, rather than bringing down the\nwhole python system.\n\nThe README file in the swig subdirectory has a description of the\nmethods used to wrap MEAD for Python.  The Python interface is\nlargely the work of Thi Thien Nguyen.\n\n\nThis distribution includes five programs implemented using the MEAD\nobject library: potential solvate, solinprot, multiflex and\nsav-driver.  It also includes the program redti, which does not use\nthe MEAD objects.  The next five sections are fairly brief\ndescriptions of the purposes and particular features of the five\nMEAD programs.  Detailed discussion of most command line options and file\nformats is deferred to the sections, \"THE COMMAND LINE\" and \"FILE\nFORMATS\", because many of the programs share many of the same options\nand formats.  Finally the program, REDTI is described.\n\nPOTENTIAL\n\nCalculates the potential due to the molecule, MolName (a name\nspecified on the command line), whose coordinates radii, and charges\nare specified in a file MolName.pqr, and writes to standard output its\nvalues at points specified by the MolName.fpt file.  The units of the\noutput potentials are input charge units divided by input length\nunits.  For typical PDB-derived input files, this would be\nproton-charge/Angstrom.  In that case, to get kcal/mol/proton-charge,\nmultiply by 331.842.\n\nThe -CoarseFieldOut and -CoarsefieldInit options will cause the\ncoarsest potential lattice to be written to, or initialized from, an\nAVS (Advanced Visualization System) \"field\" file.  By default, the\nunits are as above for the the output potentials, but if you give the\noption \"-AvsScaleFactor f\", where f is a floating point number, the\nfield will be scaled by that factor.\n\nPotential requires the files MolName.pqr and MolName.ogm.  MolName.fpt\nis not strictly required, but if neither the .fpt file nor the\n-CoarseFieldOut option are used, the program produces no output of the\ncalculated potentials.  The -epsin flag is mandatory.\n\nSee below for general explanations of files, arguments and flags.\n\n\nSOLVATE\n\nSolvate calculates the Born solvation energy of a molecule -- that is,\nthe difference in the electrostatic work required to bring its atom\ncharges from zero to their full values in solvent versus vacuum.\nMolName (a name specified on the command line) is the molecule(s) for\nwhich the the calculation is to be done and whose coordinates radii\nand charges are specified in a file MolName.pqr Solvate requires a\nMolName.pqr file and a MolName.ogm file (see below) as inputs.  THE\n-epsin FLAG IS MANDATORY.  This is a change from older version.  I\nfound that people got confused when the default epsin (previously 4.0)\nwas contrary to people's expectations; so no more default behavior!\nThe Born solvation energy is written to standard output in kcal/mole.\nPhysical conditions and units for I/O can be set by flags on the\ncommand line (see below).  By default solvate assumes we are going\nfrom vacuum (eps=1) to water (eps=80).  Note that solvate uses the\n-epssol and -epsvac flags rather than the -epsext flag to control\nsolvent conditions.  You can try it out on a sphere to check agreement\nwith the Born formula.  See the born subdirectory.\n\nA NEW FEATURE of solvate is turned on with the -ReactionField flag.\nIn this case, a MolName.fpt file is expected to contain points at\nwhich you want the value of the reaction field.  It will be written\nout to the file, MolName.rf.\n\n\nSOLINPROT\n\nUSAGE: solinprot [flags] solute protein\n\nCalculates the \"solvation\" of the molecule named by solute (for which\nthere must be solute.pqr and solute.ogm files) inside the molecule\nnamed by protein (for which the must be a protein.pqr file) which is,\nin turn, in some solvent (water, by default).  The interior of the\nsolute is presumed to have the dielectric constant, epsin1 (given by\nthe -epsin1 flag) and regions interior to the protein but exterior to\nthe solute are presumed to have the dielectric constant, epsin2 (given\nby the -epsin2 flag) and regions exterior to both protein and solute\nare presumed to have dielectric constant, epsext (80.0 by default).\nThe protein may contain charges and their interaction with the solute\nwill contribute to \"solvation energy.\"  The solvated energy is\ncalculated relative to a vacuum calculation in which the dielectric\nconstant has a value of epsin1 inside the solute and epsvac (1.0 by\ndefault) outside.\n\nThe calculation works like this: First the potential due to the solute\ncharges (call them rho_solute) in the above described dielectric\nenvironment is calculated.  Call this potential phi_sol.  Next the\npotential due to rho_solute is calculated in the vacuum dielectric\nenvironment described above.  Call this potential phi_vac.  The\nreaction field component of the solvation energy is then,\n(rho_solute*phi_sol - rho_solute*phi_vac)/2, where \"*\" indicates a\nsuitable sum or integral of charge times potential.  So far, this is\nthe same as the solvate program except for the three-dielectric\nenvironment on the solvated side.  We also need the contribution due\nto protein charges, rho_protein, interacting with the solute:\nrho_protein*phi_sol.\n\nThe flags are similar to those for the solvate program except that the\n-epsin1 and -epsin2 flags (see below) are mandatory and the -epsin\nflag is forbidden.  The -epsext flag is used instead of -epssol for\nspecifying the solvent dielectric.  (Is this a bug?).  The\n-ProteinField flag, described below, is also available.\n\nMULTIFLEX\n\nMultiflex does the electrostatic part of a titration calculation for a\nmulti-site titrating molecule.  It can do single-conformer calculations\nbased on the methods described in Karplus and Bashford (1990) and\nBashford and Gerwert (1992) which assumes a rigid molecule, or\nit can included limited conformational flexibility by the method\nof You and Bashford (1995a).  In the latter case, the user must\nsupply the coordinates for the conformational variants and the\ncorresponding non-electrostatic energies.  This can be done with\na program like CHARMM.\n\nFor single-conformer calculation, multiflex works like the old\nmultimead program.  It takes MolName.pqr, MolName.ogm, MolName.mgm,\nMolName.sites and MolName.st files as inputs (see below) and as its\nmain outputs, produces a MolName.pkint file, which contains the\ncalculated intrinsic pK's; a MolName.g file, which contains site-site\ninteractions in units of charge squared per length; and a MolName.summ\nfile which summarizes the self and background contributions to the\nintrinsic pK of each site.  The MolName.pkint file and the Molname.g\nfile can be used directly as input to redti, the program for\ncalculating titration curves.  Multiflex also produces a file,\nMolName.sitename.summ for each titrating site which contains some\nsummary information that is mainly interesting for multi-conformer\n(flexible) calculations; and it produces a large number of *.potat\nfiles, which are binary files that are useful if a job is interrupted\nand restarted (see below).  The -epsin flag is mandatory.  Other flags\ncan be used to change units and/or physical conditions or include a\nmembrane.\n\nFor the \"flexible\" calculations which involve multiple conformers,\nmultiflex needs the input files described above but it also needs\nadditional files: For each flexible site there must be a file,\nMolName.sitename.confs, in which \"sitename\" is constructed from the\nMolName.sites file by the procedure,\n\n  \"7  GLU\"  --\u003e \"GLU-7\"\n\nThese .confs files tell about the possible conformers of that site.\nThey contain lines of the form:\n\n  confname  mac_non_elstat_energy  mod_non_elstat_energy\n\nwhere \"confname\" is the name of the conformer and the next two entries\nare non-electrostatic energies of the conformer in the macromolecule\nand in the model compound corresponding to this site.  The energies\nmust be given in kcals/mole unless the -econv flag (see below)\nhas been given to change the energy units.\n\nFor each conformer named in a .confs file, there must be a .pqr file\nhaving the coordinates, charges and radii for the whole protein in\nthat conformer.  It must have the file name:\n\n   MolName.sitename.confname.pqr\n\nYou might need a lot of of .pqr files, for example, the You and\nBashford calculations on lysozyme had 36 conformers for each of 12\nsites and one MolName.pqr file is always needed so 433 .pqr files were\nneeded for each titration calculation.\n\nFlexible and single-conformer sites can co-exist in the same molecule.\nThe way multiflex tells the difference is that flexible sites have\nconfs files and single-conformer files don't.\n\n\nSAV-DRIVER\n\nThis program gives a demonstration of the SolvAccVol facility of MEAD\nwhich was described in our paper, You and Bashford (1995b),\nJ. Comp. Chem. vol. 16, pp. 743-757.  It is described in more detail\nin the file, README.SAV\n\nTHE COMMAND LINE:\n\nThe programs generally have the command line syntax:\n\nprogram_name [flag value]... [flag]... MolName\n\nwhere MolName is the base name for various I/O files.  For example,\n\"multiflex [flags] foo\" will expect to find files named foo.pqr,\nfoo.ogm, foo.mgm, and foo.sites, and will create foo.pkint, foo.g and\nfoo.summ, as well as writing to standard output.  The flags are used\nto set values pertaining to the physical conditions being modeled and\nthe units used in the input files and the other flags.  The default\nassumptions regarding units are that all inputs with dimension of\nlength (coordinates, grid spacing) are in Angstroms, all inputs with\ndimensions of charge are in protons, concentrations are in moles/liter\nand temperature is in Kelvins.\n\nThe flags and their default values are:\n\n     -epsin f\t \tDielectric constant of molecular interior\n                        In old versions of MEAD this had a default value,\n                        but this caused confusion, so now you must\n                        specify epsin explicitly.\n\n     -epsext f\t 80.0\tExterior dielectric constant (potential only).\n\n\n     -epssol f   80.0   The dielectric constant of one of the\n                        external media in the solvate program,\n                        presumably the solvent.  (multiflex and solvate)\n\n     -epsvac f    1.0   The dielectric constant of the other\n                        external media in the solvate program,\n                        presumably the vacuum.  (solvate only)\n\n     -solrad f    1.4\tSolvent probe radius used in rolling ball\n\t\t\tprocedure to determine contact surface\n\t\t\twhich is taken as the boundary between\n\t\t\tepsin and epsext.  (Angstroms, by default)\n\n     -sterln f\t   2.0\tIon exclusion layer thickness which is added\n\t\t\tto atomic radii to determine region inaccessible\n\t\t\tto salt so that kappa term in PB equation\n\t\t\tis zero.  (Angstroms, by default)\n\n     -ionicstr f  0.0\tIonic strength (moles/liter, by default).\n\n     -T f\t 300.0\tTemperature (Kelvins by default)\n\n     -ReactionField     (solvate only) Flag to write values of the\n                        solvent reaction field potential at space\n                        points specified by the user.  The point should\n                        be in an input file named MolName.fpt in which\n                        points are listed in the format, \"(x, y, z)\"\n                        Corresponding reaction field potential values\n                        will be written to a file MolName.rf.\n\n     -epsave_oldway     Revert to the old style of \"epsilon averaging\"\n                        This refers to the problem of deciding what\n                        value of the dielectric to use for the region\n                        between two potential lattice points in the\n                        finite-difference method.  The new way involves\n                        inverse averaging and is similar to a proposal\n                        by McCammon.  The old way is a simple mean.\n                        The new way is significantly more accurate;\n                        the option to do it the old way is only provided\n                        for the sake of reproducing old experimental\n                        results.  It is not recommended otherwise.\n\n     -converge_oldway   Revert to the old way of testing for convergence\n                        of the SOR method of solving the finite-difference\n                        representation of the Poisson--Boltzmann equation.\n                        The new method gives improved long-range accuracy\n                        for large lattices, but at a sometimes substantial\n                        computational cost.  See the NEWS file for further\n                        discussion.\n\n     -kBolt f\t 5.984e-6 (protons squared)/(Angstrom * Kelvin)\n\t\t\tThe Boltzmann constant in units of charge unit\n\t\t\tsquared per length unit per temperature unit.\n\t\t\tYou must adjust this if you don't use the\n\t\t\tdefault units of length, charge and temperature\n\n     -econv f    331.842  (kcal/mole)/(protons squared/Angstrom)\n                        Conversion factor for going from energy units\n                        of (charge units squared)/(length unit) to\n                        to whatever energy units you want for your output.\n                        You must adjust this if you don't use the\n\t\t\tdefault units of length and charge, or if you\n\t\t\twant output in different energy units.\n\n     -conconv f\t 6.022214e-4 ((particles/cubic Angstrom)/(moles/liter))\n\t\t\tConversion factor for going from concentration\n\t\t\tunits used for ionic strength to units of\n\t\t\tparticles per cubic length unit.  You must adjust\n\t\t\tthis if you don't use the default units of length\n\t\t\tand concentration.\n\n     -site N            Do a titration calculation only for the N-th\n                        site that is named in the .sites file.\n                        (multiflex only).\n\n     -CoarseFieldOut  nm  For the first (coarsest) lattice specified\n                        in the .ogm file, write the lattice potential\n                        values to a file, nm.fld, which is an AVS\n                        \"field\" format.  (potential only)\n\n     -CoarseFieldInit  nm  For the first (coarsest) lattice specified\n                        in the .ogm file, read the lattice potential\n                        values from the AVS file, nm.fld, and use them\n                        to initialize the coarse lattice. (potential only)\n\n     -nopotats          Prevent multiflex from creating any .potat\n                        files.  However, multiflex will still make\n                        use of .potat files found in the current\n                        directory (see discussion of .potat files below)\n\n     -membz f1 f2       Set up a membrane parallel to the x-y plane\n                        extending from z=f1 to z=f2.  (multiflex only).\n                        The \"membrane\" is a low-dielectric slab: all points\n                        within the specified z range are assigned the\n                        dielectric constant, epsin. (multiflex only)\n\n     -membhole f1 [f2 f3]   Make a cylindrical \"hole\" through the\n                        membrane with radius f1 and central axis in\n                        the z direction x=f2 and y=f3 (or x=y=0 if\n                        f2 and f3 are not given).  The meaning of the\n                        hole is that points that are inside the hole but\n                        outside the protein interior are assigned\n                        a dielectric constant of epssol.  This is useful\n                        for calculations on membrane proteins that make\n                        channels or have water-filled cavities, such as\n                        bacteriorhodopsin.  (multiflex only)\n\n     -blab1\n     -blab2\n     -blab3             Controls how verbose the program will be.  -blab3\n\t\t\tis most verbose, and no blab flag at all is least\n\t\t\tverbose.  In the latter case only essential info\n\t\t\ton the run parameters and results are printed\n\t\t\tto standard output.  Writing to things like .pkint\n\t\t\tfiles are not effected.\n\n\nFILE FORMATS\n\nMolName.pqr :\n\n\tAtomic coordinate file similar to a PDB (Protein Data Bank)\n\tfile but with atomic charge and radii in the occupancy and\n\tB-factor columns, respectively.  More specifically, lines\n\tbeginning with either \"ATOM\" or \"HETATM\" (no leading spaces)\n\tare interpreted as a set of tokens separated by one or more\n\tspaces or TAB characters.  The tokens (including the leading\n\tATOM or HETATM are interpreted as follows:\n\n          ignored ignored atname resname resnum x y z charge radius chainid\n\n        The chainid token is optional, and any tokens beyond that are\n        ignored. Tokens can be of arbitrary length, but must not\n        contain spaces or tabs. Lines that do not begin with \"ATOM\" or\n        \"HETATM\" are ignored. The programs make no distinction\n        between ATOMs and HETATMs (note above that token 1 is\n        ignored).  No atname-resnum-chainid combination can occur more than\n        once. (Atom data is stored internally in associative arrays\n        and syntax of things like .st files depend on ability of\n        atname-resnum-chainid combination to uniquely specify an atom.) \n\n\tNote that the .pqr format does not support some PDB-isms such\n\tas a altLoc fields, and a one-character chainID between\n\tresName and resSeq.  Doing so would break the whitespace\n\tseparated tokens convention that allows for easy processing\n\twith perl scripts, etc.  Instead we put \"chainID\" in a\n\tposition more or less analogous with the PDB segID.  (Maybe we\n\tshould have called it segID.)\n\n\nMolName.ogm, MolName.mgm :\n\n\tSpecification for the grid method.  Each line specifies a\n\tlevel of a focussed set of grid calculations, starting with\n\tthe coarsest and going to the finest.  Lines have the format,\n\n        centering  grid_dimension  grid_spacing\n\n        where grid_dimension is an odd integer greater than 1\n\tspecifying the number of points along the edge of the grid;\n\tgrid_spacing is a positive floating point number specifying\n\tthe spacing between grid points; and centering is\n\tON_ORIGIN, ON_GEOM_CENT or ON_CENT_OF_INTR, according to\n\twhether the grid is to be centered on the origin of the\n\tcoordinate system, the geometric center or the \"center of\n\tinterest\" which, for multiflex is on one of the titrating\n\tcharges in the site being calculated (see .st files, below)\n\tand for other programs is on the origin (so ON_CENT_OF_INTR\n\tnot much use with selfenergy).  Multimead needs the .ogm file\n\tto specify the grid method for the macromolecule and the .mgm\n\tfile to specify the grid method for the model compound.  Other\n\tprograms need only the .ogm file.  For proper cancelation of\n\tgrid effects, the finest levels for the model compound and the\n\tmacromolecule must use the same grid spacing and centering\n\tstyle.  The grid center can also be specified explicitly by\n\tgiving a point in the format, \"(x, y, z)\" as the\n\tcentering.\n\nMolName.fpt:\n\n        Specifies that \"field points\" for which the potential program\n        should sample and write out the potential.  The x, y, z\n        coordinates should be specified as three numbers written in\n        the usual floating-point way, and separated by any amount of\n        white space.  Optionally, the three numbers can by surrounded\n        by parenthesis and separated by commas.  Points are separated\n        from each other by white space.  Line breaks are considered\n        the same as any other white space.\n\nMolName.sites (multiflex only):\n\n\tThis file specifies which sites in a macromolecule are titrating\n\tand what kind they are.  For each site it contains a line of the\n\tform,\n\n\tresnum  site_type chainid\n\n\twhere resnum is the residue number of the site and will be\n        matched to the residue number field of the atoms in the\n        MolName.pqr file, chainid is to be matched to the chainid\n        given in MolName.pqr, and site_type refers to site_type.st\n        files.  Usually, site_type will be similar to a residue type\n        name.  The chainid field is optional, but you must be\n        consistent in either including or omitting it in MolName.sites\n        and MolName.pqr.\n\nsite_type.st: (multimead and multiflex only)\n\n\tMultiflex expects a file of the name site_type.st to specify\n\tdetails concerning each site_type that appears in the\n\tMolName.sites file.  The first line contains one floating\n\tpoint number which is the model compound pK for that type of\n\tsite.  All remaining lines are of the form,\n\n\tresname atomname prot_charge deprot_charge\n\n\twhere resname and atomname, along with the resnums given in\n\tthe .sites file match an atom in the .pqr file that is part of\n\ta titrating site, prot_charge is that charge of this atom in\n\tthe protonated state and deprot_charge is its charge in the\n\tdeprotonated state.  It is expected that the sum of all\n\tprot_charge subtracted from the sum of all deprot_charge\n\twill equal one.\n\n\tI plan to extend this file's syntax to allow a regular\n\texpression to be given that will specify how a model compound\n\tis to be made from the protein atom coordinates.\n\nSomething.potat : (output)\n\n\tThis is a binary output file produced by some programs.  It\n\tcontains the potential at each atom of MolName (or a model\n\tcompound) generated by some set of charges.  Variations of\n\t\"something\" may denote charge states, sites, conformers,\n\tsolvated or vacuum or uniform dielectric environments,\n\tdepending on the application.  Atomic coordinates and radii\n\tand the generating charges are also included for the sake of\n\tconsistency checking.  These files allow multiflex, etc. to\n\tavoid recalculating a lot of things when all you want to do is\n\tadd or alter some site, but you must be careful about site\n\tnames, which .potat files you leave sitting around, and so on.\n        Specify the -blab2 flag for a blow-by-blow account of attempts\n\tto read and write .potat files in multiflex.\n\nMolName.pkint, MolName.g MolName.sitename.summ: (multiflex)\n\n\tDescribed in the multiflex summary above.\n\n\nREDTI:\n\nRedti solves the multiple site titration curve problem given a set of\nintrinsic pK's (MolName.pkint) and a site-site interaction matrix\n(MolName.g) using the Reduced Site method described by Bashford \u0026\nKarplus (1991) J. Phys. Chem. vol. 95, pp. 9556-61.  Its command line\nsyntax is:\n\nredti [-cutoff val] [-pHrange val val] [-dry] MolName\n\nwhere the \"val\" are numbers giving the protonation fraction cutoff for\nthe reduced site method, the bottom of the pH range to be covered and\nthe top of the range, respectively.  The defaults are 0.05, -20.0 and\n30.1, respectively.  (Yes, that's an extreme pH range).  The -dry flag\ncauses redti to do a \"dry run\" in which it prints the number of sites\nto be included in the reduced site calculation at each pH point.  This\nis useful for checking whether a calculation will require a prohibitive\namount of CPU time since CPU time will go exponentially in the reduced\nsite number.\n\nRedti is written in C rather than C++.\n\n\nAUTHOR:\n       Donald Bashford\n       don.bashford@stjude.org\n\n       Hartwell Center\n       Saint Jude Children's Research Hospital\n       Memphis, TN\n\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fefliks%2Fmead","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fefliks%2Fmead","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fefliks%2Fmead/lists"}