Details of the branchy workflow

Hi,

I have pushed some changes that restore the old avogadro library layout, as
previously discussed. I also took the opportunity to do some spring cleaning
of our CMake files. I will try to do a little more over the coming weeks, but
it is possible that there are some errors in the platform specific code (it is
not evaluated if that path is not followed).

So please let me know if you experience issues. I thought that while we got
warmed up we would stick with one integration branch (master). I am also
happy to make a proposed 2.0 branch, that could integrate proposed changes for
the 2.0 release. The question is whether a next (integrating/testing proposed
updates that should be tested and merged into master within weeks), and a pu
(proposed updates - more experimental changes that may not be ready), are
really required.

I am going to assume they are not, I think this will also avoid additional
confusion. The way that the branchy workflow works is that you can create a new
topic branch from master (the integration branch). You then work on that
branch developing a feature, bug fix, whatever. Generally you do not publish
these, but you can. You should not merge into the feature branch, leaving the
merge until it hits master.

Assuming you have an up to date repository, and a checkout of cryos/master,
you can create a new topic branch using,

git checkout -b topic_branch origin/master

Work on that, man gitworkflows will give you lots of details on how to handle
it. Once it is ready, you can publish the topic branch to GitHub where it can
be reviewed. Optionally, it would be merged into next for further testing. If
we add more dashboards this could be worth doing to assure it at least
compiles. Then it is merged into master once it has been tested a little. If
it is bad then the merge commit is reverted.

Once the branch is merged, you can simply delete it. Start a new topic branch,
work on that. This gives history an easy to follow shape, it allows for the
integration of a series of patches implementing a feature or bug fix. You can
cherry pick commits that are not organized like this onto a feature branch.
All integration branches consist purely of merges from topic branches.

This approach really does improve code review. If a topic branch is not up to
scratch, you can continue working on it, and it is merged once it is ready.
You really should avoid merging into it, but if you have to, checkout your
branch and then rebase it onto master.

I am working with several other groups using this workflow, and it is proving
to be useful once people get the hang of it. It helps to only land mature
topic branches, that have been worked on and tested before being integrated.
This improves overall stability in master, while allowing people to work on
experimental features. You can also rebase topic branches onto the past, i.e.
the 1.0 branch etc, to then merge it into maintenance releases when
appropriate. Ideally, a topic branch targeted at 1.0 is branched from there,
and can be merged into both 1.0 and master (assuming no large changes in code
organization, etc).

Hopefully it will become clear to you.

Thanks,

Marcus

27.05.10, 09:36, “Marcus D. Hanwell” marcus@cryos.org:

Hi,

I have pushed some changes that restore the old avogadro library layout, as
previously discussed. I also took the opportunity to do some spring cleaning
of our CMake files. I will try to do a little more over the coming weeks, but
it is possible that there are some errors in the platform specific code (it is
not evaluated if that path is not followed).

So please let me know if you experience issues. I thought that while we got
warmed up we would stick with one integration branch (master). I am also
happy to make a proposed 2.0 branch, that could integrate proposed changes for
the 2.0 release. The question is whether a next (integrating/testing proposed
updates that should be tested and merged into master within weeks), and a pu
(proposed updates - more experimental changes that may not be ready), are
really required.

I thought “next” will be a branch targeted to 2.x. In this terms, it will be called pu (but this name a bit more vague:) Surely, we don’t need both next and pu, but I’d like to see a branch for 2.x, where good but 1.x-incompatible changes will be merged

I am going to assume they are not, I think this will also avoid additional
confusion. The way that the branchy workflow works is that you can create a new
topic branch from master (the integration branch). You then work on that
branch developing a feature, bug fix, whatever. Generally you do not publish
these, but you can. You should not merge into the feature branch, leaving the
merge until it hits master.

Assuming you have an up to date repository, and a checkout of cryos/master,
you can create a new topic branch using,

git checkout -b topic_branch origin/master

Work on that, man gitworkflows will give you lots of details on how to handle
it. Once it is ready, you can publish the topic branch to GitHub where it can
be reviewed. Optionally, it would be merged into next for further testing. If
we add more dashboards this could be worth doing to assure it at least
compiles. Then it is merged into master once it has been tested a little. If
it is bad then the merge commit is reverted.

Once the branch is merged, you can simply delete it. Start a new topic branch,
work on that. This gives history an easy to follow shape, it allows for the
integration of a series of patches implementing a feature or bug fix. You can
cherry pick commits that are not organized like this onto a feature branch.
All integration branches consist purely of merges from topic branches.

This approach really does improve code review. If a topic branch is not up to
scratch, you can continue working on it, and it is merged once it is ready.
You really should avoid merging into it, but if you have to, checkout your
branch and then rebase it onto master.

I am working with several other groups using this workflow, and it is proving
to be useful once people get the hang of it. It helps to only land mature
topic branches, that have been worked on and tested before being integrated.
This improves overall stability in master, while allowing people to work on
experimental features. You can also rebase topic branches onto the past, i.e.
the 1.0 branch etc, to then merge it into maintenance releases when
appropriate. Ideally, a topic branch targeted at 1.0 is branched from there,
and can be merged into both 1.0 and master (assuming no large changes in code
organization, etc).

Hopefully it will become clear to you.

Thanks,

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

My questions:

  1. AFAIK, when merging topic branch, all of its commits go into history of integration branch. How to simplify history as you propose?
  2. What if I do some changes that modify thing I’ve done before if it was already merged? Is it better to be “master-fix” or new branch is recommended? Is it worth to create a branch if I’m not sure there will be more than 1 commit in it?
  3. Is it OK to create a branch for 2.0 from what I have in trunk now?


Regards,
Konstantin

Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :

Hi,

I have pushed some changes that restore the old avogadro library layout, as
previously discussed. I also took the opportunity to do some spring cleaning
of our CMake files. I will try to do a little more over the coming weeks, but
it is possible that there are some errors in the platform specific code (it is
not evaluated if that path is not followed).

Hi Marcus.

I have just checked your modifications and I get the following error when
installing Avo, bot in MacOSX and in a CentOS virtual machine:

“-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to “/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib"
CMake Error at libavogadro/src/cmake_install.cmake:117 (FILE):
file INSTALL cannot find
”/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm”.
Call Stack (most recent call first):
libavogadro/cmake_install.cmake:37 (INCLUDE)
cmake_install.cmake:79 (INCLUDE)"

The qm files seem to ha moved to “avogadro/src”.

Regards,

Louis

Do I understand right:
I don’t commit anything except fixes into my master, and send a pull
request for each topic branch separately. Than, once they are merged, I
merge them into my master. Right?


Regards,
Konstantin

On Thursday 27 May 2010 05:08:45 Louis Ricard wrote:

Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :

Hi,

I have pushed some changes that restore the old avogadro library layout,
as previously discussed. I also took the opportunity to do some spring
cleaning of our CMake files. I will try to do a little more over the
coming weeks, but it is possible that there are some errors in the
platform specific code (it is not evaluated if that path is not
followed).

Hi Marcus.

I have just checked your modifications and I get the following error when
installing Avo, bot in MacOSX and in a CentOS virtual machine:

“-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to
”/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error at
libavogadro/src/cmake_install.cmake:117 (FILE):
file INSTALL cannot find
"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".
Call Stack (most recent call first):
libavogadro/cmake_install.cmake:37 (INCLUDE)
cmake_install.cmake:79 (INCLUDE)"

The qm files seem to ha moved to “avogadro/src”.

Thanks Louis - I will look into this and push a fix soon. No other problems
thus far?

Thanks,

Marcus

On Thursday 27 May 2010 05:08:45 Louis Ricard wrote:

Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :

Hi,

I have pushed some changes that restore the old avogadro library layout,
as previously discussed. I also took the opportunity to do some spring
cleaning of our CMake files. I will try to do a little more over the
coming weeks, but it is possible that there are some errors in the
platform specific code (it is not evaluated if that path is not
followed).

Hi Marcus.

I have just checked your modifications and I get the following error when
installing Avo, bot in MacOSX and in a CentOS virtual machine:

“-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to
”/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error at
libavogadro/src/cmake_install.cmake:117 (FILE):
file INSTALL cannot find
"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".
Call Stack (most recent call first):
libavogadro/cmake_install.cmake:37 (INCLUDE)
cmake_install.cmake:79 (INCLUDE)"

The qm files seem to ha moved to “avogadro/src”.

Hi Louis,

I tracked it down, and pushed a fix. Should be all better - checked here and I
no longer see the error. After all of the moving around, the QM files were not
being used by libavoagdro, therefore were not built. Please let me know if you
spot anything else.

Marcus

On Thursday 27 May 2010 06:20:25 Konstantin Tokarev wrote:

Do I understand right:
I don’t commit anything except fixes into my master, and send a pull
request for each topic branch separately. Than, once they are merged, I
merge them into my master. Right?

With a branchy workflow, your master is irrelevant. It is all about topic
branches, where the actual work is done, and merges into integration branches.
I wrote a wiki article for a project that I am working on, that should
hopefully illustrate this in more detail,

http://www.kitware.com/InfovisWiki/index.php/Git/Workflow/Topic

You start a new topic branch, it branches from the stable integration branch,
i.e. cryos/master, you work, you commit, you fix, may be you even rewrite
history because you realize your original commits made no sense. Then you
publish your topic branch, request a merge.

If you do more work that is dependent on previous topic branch, you either
continue working on that branch, or make a new branch from master. Just having
a running topic branch called ‘my-stream-of-random-fixes’ would defeat the
purpose of using topic branches. We have already been using some elements of
this workflow (merging of multiple masters), this is just more structured.

That might then be merged into next, tested, found to be OK, and then merged
into master. At that point you delete that topic branch, forget about it and
move on. That is the core of a branchy workflow. You seem to misunderstand
master/next - they do not get that far out of sync.

Making a longer lived branch, called proposed2, or something like that, is
probably reasonable to house a merge commits for a possible 2.0. The more that
topic branches are used, the more possibility that the actual 2.0 merges the
good bits, and may be leaves the bad bits.

Master will only have merge commits. Follow the links in the wiki article I
linked to for more background on why. Even a one commit branch would be on a
branch, you may need to learn more about Git to appreciate why integration
branches are so useful - there is plenty of information out there.

Please note, topic branches also depend on descriptive commit messages. See
this article for quidelines on creating good commits and commit messages,

http://progit.org/book/ch5-2.html

This helps enormously when reviewing topic branches, but also in any project
when trying to figure out why a certain change was made.

Thanks,

Marcus

Hi Marcus.

Your latest push works in my two favorite systems.

There is a minor problem when drawing molecules.
In recent trunk, default atom and bond radius seem
too small. When drawing a molecule, atoms look like
"wire frame", assuming one has selected “ball and stick”.
This makes it impossible (in my hands) to build any
molecule. Zooming or, better, increasing the atom
and bond radiuses in “ball and stick” parameters
restores expected behavior.

Regards,

Louis

Le 28 mai 2010 à 06:12, Marcus D. Hanwell a écrit :

On Thursday 27 May 2010 05:08:45 Louis Ricard wrote:

Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :

Hi,

I have pushed some changes that restore the old avogadro library layout,
as previously discussed. I also took the opportunity to do some spring
cleaning of our CMake files. I will try to do a little more over the
coming weeks, but it is possible that there are some errors in the
platform specific code (it is not evaluated if that path is not
followed).

Hi Marcus.

I have just checked your modifications and I get the following error when
installing Avo, bot in MacOSX and in a CentOS virtual machine:

“-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to
”/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error at
libavogadro/src/cmake_install.cmake:117 (FILE):
file INSTALL cannot find
"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".
Call Stack (most recent call first):
libavogadro/cmake_install.cmake:37 (INCLUDE)
cmake_install.cmake:79 (INCLUDE)"

The qm files seem to ha moved to “avogadro/src”.

Hi Louis,

I tracked it down, and pushed a fix. Should be all better - checked here and I
no longer see the error. After all of the moving around, the QM files were not
being used by libavoagdro, therefore were not built. Please let me know if you
spot anything else.

Marcus



Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Marcus: it’s needed to merge c2350659a35ea69dd631 from my git

28.05.10, 23:08, “Louis Ricard” louis.ricard@polytechnique.edu:

Hi Marcus.Your latest push works in my two favorite systems.There is a minor problem when drawing molecules.In recent trunk, default atom and bond radius seemtoo small. When drawing a molecule, atoms look like"wire frame", assuming one has selected “ball and stick”.This makes it impossible (in my hands) to build anymolecule. Zooming or, better, increasing the atomand bond radiuses in “ball and stick” parametersrestores expected behavior.Regards,Louis Le 28 mai 2010 à 06:12, Marcus D. Hanwell a écrit :On Thursday 27 May 2010 05:08:45 Louis Ricard wrote:Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :Hi,I have pushed some changes that restore the old avogadro library layout,as previously discussed. I also took the opportunity to do some springcleaning of our CMake files. I will try to do a little more over thecoming weeks, but it is possible that there are some errors in theplatform specific code (it is not evaluated if that path is notfollowed).Hi Marcus.I have just checked your modifications and I get the following error wheninstalling Avo, bot in MacOSX and in a CentOS virtual machine:"-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to"/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error atlibavogadro/src/cmake_install.cmake:117 (FILE):file INSTALL cannot find"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".Call Stack (most recent call first):libavogadro/cmake_install.cmake:37 (INCLUDE)cmake_install.cmake:79 (INCLUDE)"The qm files seem to ha moved to “avogadro/src”.Hi Louis,I tracked it down, and pushed a fix. Should be all better - checked here and I no longer see the error. After all of the moving around, the QM files were not being used by libavoagdro, therefore were not built. Please let me know if you spot anything else.Marcus------------------------------------------------------------------------------_______________________________________________Avogadro-devel mailing listAvogadro-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/avogadro-devel------------------------------------------------------------------------------_______________________________________________Avogadro-devel mailing listAvogadro-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/avogadro-devel


Regards,
Konstantin

Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign

Hi Louis,

I was looking at some of the new defaults, and they don’t look good. I was
going to take a look at it, but was checking everything built correctly. I
think what we had before was great, and am not a fan of changing things that
worked well.

It is iterative, and this is part of the branchy workflow - introducing more
review before changes are merged in.

Marcus

On Friday 28 May 2010 15:08:20 Louis Ricard wrote:

Hi Marcus.

Your latest push works in my two favorite systems.

There is a minor problem when drawing molecules.
In recent trunk, default atom and bond radius seem
too small. When drawing a molecule, atoms look like
"wire frame", assuming one has selected “ball and stick”.
This makes it impossible (in my hands) to build any
molecule. Zooming or, better, increasing the atom
and bond radiuses in “ball and stick” parameters
restores expected behavior.

Regards,

Louis

Le 28 mai 2010 à 06:12, Marcus D. Hanwell a écrit :

On Thursday 27 May 2010 05:08:45 Louis Ricard wrote:

Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :

Hi,

I have pushed some changes that restore the old avogadro library
layout, as previously discussed. I also took the opportunity to do
some spring cleaning of our CMake files. I will try to do a little
more over the coming weeks, but it is possible that there are some
errors in the platform specific code (it is not evaluated if that path
is not followed).

Hi Marcus.

I have just checked your modifications and I get the following error
when installing Avo, bot in MacOSX and in a CentOS virtual machine:

“-- Set runtime path of “/usr/local/lib/libavogadro.so.1.1.0” to
”/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error at

libavogadro/src/cmake_install.cmake:117 (FILE):
file INSTALL cannot find
"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".

Call Stack (most recent call first):
libavogadro/cmake_install.cmake:37 (INCLUDE)
cmake_install.cmake:79 (INCLUDE)"

The qm files seem to ha moved to “avogadro/src”.

Hi Louis,

I tracked it down, and pushed a fix. Should be all better - checked here
and I no longer see the error. After all of the moving around, the QM
files were not being used by libavoagdro, therefore were not built.
Please let me know if you spot anything else.

Marcus




Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel




Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Not to be overly prescriptive, but the author is not a name, the commit
message is not very descriptive, and it is not on a topic branch. Not sure
what is going off with some of the defaults, but the originals before they were
changed worked pretty well, now things don’t look as good (to me, and Louis at
least).

On Friday 28 May 2010 15:46:26 Konstantin Tokarev wrote:

Marcus: it’s needed to merge c2350659a35ea69dd631 from my git

28.05.10, 23:08, “Louis Ricard” louis.ricard@polytechnique.edu:

Hi Marcus.Your latest push works in my two favorite systems.There is a
minor problem when drawing molecules.In recent trunk, default atom and
bond radius seemtoo small. When drawing a molecule, atoms look like"wire
frame", assuming one has selected “ball and stick”.This makes it
impossible (in my hands) to build anymolecule. Zooming or, better,
increasing the atomand bond radiuses in “ball and stick"
parametersrestores expected behavior.Regards,Louis Le 28 mai 2010 à
06:12, Marcus D. Hanwell a écrit :On Thursday 27 May 2010 05:08:45 Louis
Ricard wrote:Le 27 mai 2010 à 07:36, Marcus D. Hanwell a écrit :Hi,I
have pushed some changes that restore the old avogadro library layout,as
previously discussed. I also took the opportunity to do some
springcleaning of our CMake files. I will try to do a little more over
thecoming weeks, but it is possible that there are some errors in
theplatform specific code (it is not evaluated if that path is
notfollowed).Hi Marcus.I have just checked your modifications and I get
the following error wheninstalling Avo, bot in MacOSX and in a CentOS
virtual machine:”-- Set runtime path of
"/usr/local/lib/libavogadro.so.1.1.0"
to"/usr/local/lib:/usr/local/lib:/opt/qtsdk-2009.05/qt/lib" CMake Error
atlibavogadro/src/cmake_install.cmake:117 (FILE):file INSTALL cannot
find"/home/ricard/git/avogadro/build/libavogadro/src/libavogadro_he.qm".
Call Stack (most recent call first):libavogadro/cmake_install.cmake:37
(INCLUDE)cmake_install.cmake:79 (INCLUDE)"The qm files seem to ha moved
to “avogadro/src”.Hi Louis,I tracked it down, and pushed a fix. Should
be all better - checked here and I no longer see the error. After all of
the moving around, the QM files were not being used by libavoagdro,
therefore were not built. Please let me know if you spot anything
else.Marcus-------------------------------------------------------------
-----------------______Avogadro-
devel mailing
listAvogadro-devel@lists.sourceforge.nethttps://lists.sourceforge.net/li
sts/listinfo/avogadro-devel----------------------------------------------
--------------------------------

______Avogadro-devel mailing
listAvogadro-devel@lists.sourceforge.nethttps://lists.sourceforge.net/li
sts/listinfo/avogadro-devel

Not sure what is going off with some of the defaults

Nothing. I’ve changed scale of bond radius change because it was hard to get small radii and I’msure nobody needs radii bigger than atomic (as at the end of old slider). Relevant commits are 27528ad16a06f1d1f317 and c2350659a35ea69dd631 (and nothing else). Default radius will be the same as it was, but you’ll probably need to change your previous setting for bond radii (sorry for inconvenience, but I think it’s better if internal unit of radius for bonds will stay an integer number)

About atomic radii: a lot of time ago I’ve added covalent radii as default choice (previously there were VdW only). Geoff said it’s not good and committed change which was intended to make VdW default, but as far as I see default is still “Covalent”. If you prefer situation when C and Br are almost equal in size, please let me know if I need to change default, or simply change setting to VdW


Regards,
Konstantin

Hi!

Something to think about:
Please, support working with coarse-grained models. There the radius of
beads typically will be much larger than atomic radius since they
represent groups of atoms.

Cheers,
Reinis

S , 2010-05-29 12:47 +0400, Konstantin Tokarev rakstīja:

Not sure what is going off with some of the defaults

Nothing. I’ve changed scale of bond radius change because it was hard to get small radii and I’msure nobody needs radii bigger than atomic (as at the end of old slider). Relevant commits are 27528ad16a06f1d1f317 and c2350659a35ea69dd631 (and nothing else). Default radius will be the same as it was, but you’ll probably need to change your previous setting for bond radii (sorry for inconvenience, but I think it’s better if internal unit of radius for bonds will stay an integer number)

About atomic radii: a lot of time ago I’ve added covalent radii as default choice (previously there were VdW only). Geoff said it’s not good and committed change which was intended to make VdW default, but as far as I see default is still “Covalent”. If you prefer situation when C and Br are almost equal in size, please let me know if I need to change default, or simply change setting to VdW

Please, support working with coarse-grained models. There the radius ofbeads typically will be much larger than atomic radius since theyrepresent groups of atoms.

Do you mean you want to visualize several atoms with one ball?
Also, note, that in trunk you can change angstrom radius of atom using right click menu in select mode. I think, in this case changing anstrom radius is more relevant than changing a multiplier (what slider in setting actually does)


Regards,
Konstantin

Yes. Only there might not be normal atoms in the structure file to begin
with.

I’m not sure how it is best handled technically, but it would be great
if Avogadro would recognize that the system is CG and visualizes it
appropriately (and provides easily accessible option for adjusting radii
of all beads).

Cheers,
Reinis

S , 2010-05-29 14:51 +0400, Konstantin Tokarev rakstīja:

Please, support working with coarse-grained models. There the radius ofbeads typically will be much larger than atomic radius since theyrepresent groups of atoms.

Do you mean you want to visualize several atoms with one ball?
Also, note, that in trunk you can change angstrom radius of atom using right click menu in select mode. I think, in this case changing anstrom radius is more relevant than changing a multiplier (what slider in setting actually does)

but it would be great if Avogadro would recognize that the system is CG and visualizes it appropriately (and provides easily accessible option for adjusting radii of all beads).

How input data looks like? Do you load model from some input format, or draw it inside Avogadro?

Finally, has your model all atomic coordinates available, and you need to visualize it alternative way, or you have only “pseudoatoms”?


Regards,
Konstantin

Only there might not be normal atoms in the structure file to begin with.

Sorry, didn’t read carefully. In this case, there’s no possibility to detect it, if it couldn’t be represented using features of input format. E.g., in CML you may use group names instead of element symbols, or some additional XML data (it won’t be correcly read now, but I see how it could be handled). If you work with format not supported by OpenBabel, the best solution would be to add this file format, than it will be directly readable and correctly intepreted

Regards,
Konstantin

Usually these models don’t contain all atomic coordinates, but they can
be used to coarse-grain the system (generate coordinate file with beads)
and there are procedures to generate all atom coordinates from CG
system. Probably drawing them in Avogadro also might be of some utility.

I’m interested in using Gromacs for CG MD simulations. An example file
in attachment (*.gro). It would be nice to be able to visualize MD
trajectories for such simulations.

Cheers,
Reinis

S , 2010-05-29 15:08 +0400, Konstantin Tokarev rakstīja:

but it would be great if Avogadro would recognize that the system is CG and visualizes it appropriately (and provides easily accessible option for adjusting radii of all beads).

How input data looks like? Do you load model from some input format, or draw it inside Avogadro?

Finally, has your model all atomic coordinates available, and you need to visualize it alternative way, or you have only “pseudoatoms”?

Usually these models don’t contain all atomic coordinates, but they can
be used to coarse-grain the system (generate coordinate file with beads)
and there are procedures to generate all atom coordinates from CG
system. Probably drawing them in Avogadro also might be of some utility.

http://en.wikipedia.org/wiki/Molecular_dynamics#Coarse-graining_and_reduced_representations

I’m interested in using Gromacs for CG MD simulations. An example file
in attachment (*.gro). It would be nice to be able to visualize MD
trajectories for such simulations.

I don’t see support for Gromacs outputs on http://openbabel.org/wiki/Category:Formats. Feel free to write feature request for OpenBabel project, and post example file there.

Maybe some additional data structure is needed in OB for correct storage of CG systems, or they may be stored as usual atoms but with different radii and some other properties which are usually taken from element-based tables


Regards,
Konstantin

Yes, *.gro files are not supported by OB, but there is nothing specific
to CG in that format.

But OB do support *.xtc file format (read-only), which is “a compressed
version of the trajectory, containing only coordinate, time, and box
vector information”. But I didn’t find any other documentation about
this in OB other than ‘babel -Hxtc’.

For it to be able to get bead radii, OB should be able to parse Gromacs
topology files (there is already a request for that:
http://sourceforge.net/tracker/?func=detail&aid=1583929&group_id=40728&atid=447448 altough the intent of the request is much wider than just the ability to read) or to read Gromacs run input files *.tpr (binary).

I’m wondering maybe it is possible to deduce that it is a CG system from
the distances to nearest neighbors? Or it might be possible to just
introduce an option to deduce radii from distances (so that is optional
feature).

Cheers,
Reinis

S , 2010-05-29 15:42 +0400, Konstantin Tokarev rakstīja:

Usually these models don’t contain all atomic coordinates, but they can
be used to coarse-grain the system (generate coordinate file with beads)
and there are procedures to generate all atom coordinates from CG
system. Probably drawing them in Avogadro also might be of some utility.

http://en.wikipedia.org/wiki/Molecular_dynamics#Coarse-graining_and_reduced_representations

I’m interested in using Gromacs for CG MD simulations. An example file
in attachment (*.gro). It would be nice to be able to visualize MD
trajectories for such simulations.

I don’t see support for Gromacs outputs on http://openbabel.org/wiki/Category:Formats. Feel free to write feature request for OpenBabel project, and post example file there.

Maybe some additional data structure is needed in OB for correct storage of CG systems, or they may be stored as usual atoms but with different radii and some other properties which are usually taken from element-based tables