Project

General

Profile

Bug #219

Remove generic names from GROMACS binaries

Added by Jussi Lehtola over 11 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

A lot of binaries of GROMACS have very generic names, such as average, highway, luck, wheel and so on, which may clash with other binaries in the system.

Could these be renamed bin -> g_bin?


Related issues

Related to GROMACS - Feature #685: Wrapper binaryClosed01/26/2011

History

#1 Updated by Erik Lindahl over 11 years ago

Hi,

Yes, we should do this, but it will have to wait until post-4.0.

(our first goal is to improve the release schedules by only fixing real bugs in the release branch - that also gives us a bit more incentive to release version 4.1 within 6 months from now :-)

#2 Updated by David van der Spoel over 11 years ago

Besides, you can do this at the configure step upon installing using

configure --program-prefix=gromacs_

#3 Updated by Erik Lindahl over 11 years ago

That is not really a solution since all other programs would be gromacs_g_energy :-)

#4 Updated by Berk Hess over 11 years ago

Wouldn't it be even better to have all binaries (including mdrun)
prefixed by gmx_ ?
(This gets a bit confusing with the source files names in src/tools,
but we can resolve that.)

Berk

#5 Updated by Jussi Lehtola over 11 years ago

(In reply to comment #4)

Wouldn't it be even better to have all binaries (including mdrun)
prefixed by gmx_ ?
(This gets a bit confusing with the source files names in src/tools,
but we can resolve that.)

Yeah, maybe, or just change everything to begin with g_ . Whatever you think is best - gmx_ is more descriptive but g_ is shorter.

Maybe it'd be best to go with gmx_, that way the probability to conflict with names of other software is least..

#6 Updated by Jussi Lehtola over 11 years ago

For the Fedora packages I changed the names of all the binaries (and their man pages) to begin with g_ .

If you later on decide to go with gmx_ it's OK for me, I'll just have to update the RPM SPEC file.

#7 Updated by Berk Hess over 11 years ago

OK.

But please wait with making the final package until version 4.0.1 comes out
which will have fixes for a few small but annoying bugs.
That will probably be on Friday.

Berk

#8 Updated by David van der Spoel over 11 years ago

Actually, are you aware that there already is a spec file? If all is well you can just run make rpm with vanilla gromacs.

We may also release a 3.3.4 version simultaneously.

#9 Updated by Jussi Lehtola over 11 years ago

(In reply to comment #7)

OK.

But please wait with making the final package until version 4.0.1 comes out
which will have fixes for a few small but annoying bugs.
That will probably be on Friday.

Gromacs 4.0 is already on its way to the repositories. Once 4.0.1 is released I will push it to the releases; updates are a lot easier than getting wholly new packages accepted in the distribution.

(In reply to comment #8)

Actually, are you aware that there already is a spec file? If all is well you
can just run make rpm with vanilla gromacs.

Yes, I am. I based some of my new spec file on the specs distributed with Gromacs, but basically had to write it anew since the specs made by Erik don't conform to Fedora's quite strict standards.

You can see my SPEC file at
http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs.spec
and the SRPM at
http://theory.physics.helsinki.fi/~jzlehtol/rpms/gromacs-4.0-3.fc9.src.rpm

We may also release a 3.3.4 version simultaneously.

OK. But since I didn't get any reply for my mail on Oct 8 (see below) I assumed there is no need for a package for gromacs 3 (I did make one, but withdrew it from the review process).

Also the packaging guidelines are quite strict: there should only be one major version of software distributed. Since having two versions means a lot more huss and Gromacs is backwards compatible, Fedora will only include the latest stable version.

With Fedora EPEL the situation is a bit trickier: the policy is to avoid even minor updates. (See http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies )

This may mean that EPEL 4 and EPEL 5 will stick to Gromacs 4.0 and won't see Gromacs 4.1. At least not until the next big OS update.

I'd prefer if there was a latest'n'greatest repository, too, for EPEL, but there isn't. In principle it's best to have the latest version available installed, but you really can't update GROMACS in the middle of doing a simulation set.

On Wed, 2008-10-08 at 18:30 +0300, Jussi Lehtola wrote:
On Wed, 2008-10-08 at 17:27 +0200, David van der Spoel wrote:

Jussi Lehtola wrote:

Hi,

are GROMACS 4.0 files binary compatible with GROMACS 3.(3.)x files?

Explanation: I am working on a package of Gromacs 4 that is going to be
included in Fedora. Is there still a need to have a separate package for
Gromacs 3.3.x or is just Gromacs 4 enough?

Gromacs 4.0 can read all old files from gromacs 3.3.

OK. So in your opinion having the latest version is enough?

#10 Updated by Rossen Apostolov over 9 years ago

Do we need this resolved for 4.5 or leave it for 5.0?

#11 Updated by Jussi Lehtola over 9 years ago

(In reply to comment #10)

Do we need this resolved for 4.5 or leave it for 5.0?

I hope to get this resolved as soon as possible :)

#12 Updated by David van der Spoel over 9 years ago

One way to do this relatively painlessly is by make the gmx prefix default in configure and stripping the g_ for the analysis tools (which can be done easily as well using git mv). No history will be lost because of this.

#13 Updated by Rossen Apostolov over 9 years ago

Also, make sure it works with CMake.

#14 Updated by David van der Spoel over 9 years ago

Previously mdrun used to be part of the RAID tools on linux boxes. genbox is reported to confict with a raytracing tool. Both mdrun and genbox fall under the category of programs that are being used in scripts a lot, and therefore I'm not touching them.

Instead, I have now picked the low hanging fruit and renamed some of the less used tools to g_XXX, and also kicked out some stuff that was obsolete (average, scrollw). I decided not to touch the configure stuff, too messy, at least in Peter Kasson's proposal.

The following programs were renamed:
luck
wheel
protonate
x2top
showcol
highhway
sigeps
anadock

e.g.
g_highway -f $GMXDATA/gromacs/top/highway.dat

#15 Updated by Rossen Apostolov over 8 years ago

  • Description updated (diff)
  • Assignee deleted (Erik Lindahl)
  • Target version deleted (4.0_rc1)

#16 Updated by Rossen Apostolov almost 8 years ago

  • Target version set to 5.0

This will be best left for 5.0 when we'll have major restructuring of the code

#17 Updated by Rossen Apostolov almost 7 years ago

  • Status changed from In Progress to Resolved
  • Affected version set to N/A

We already have a wrapper binary that solves it, see #685

#18 Updated by Rossen Apostolov about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF